系統對 Device Tree Overlays 的支持方式

問題來源：

野火 iMX 6ULL 開發板資料。
https://tutorial.linux.doc.embedfire.com/zh_CN/latest/linux_basis/fire-config_brief.html

5.3. fire-config機制

通常而言，fire-config旨在提供一些常見的系統功能配置服務，在進行配置過程當中， 這可能會致使/boot/uEnv.txt或者是其餘各類標準的linux配置文件被自動更改了， 某些選項須要重啓才能生效，若是您修改了其中一個，fire-config 會在<Finish> 按鈕被選擇時，詢問您是否要當即重啓，若是您但願配置立刻生效，肯定重啓系統便可。

5.4. Device Tree Overlays

fire-config工具集成了Device Tree Overlays機制，用來管理一些硬件資源的分配和模塊的加載， 從而緩解多個驅動程序爭用系統資源的問題。

在傳統開發模式中，這個機制一般是由設備樹來完成的：在開發以前根據項目需求， 提早肯定系統中全部用到的硬件設備。在設備樹中把全部的外圍設備信息以設備樹特定的語法進行描述， 在設備樹被編譯爲dtb文件後，被linux內核加載使用。

能夠看到，在傳統開發過程，一旦硬件資源發生變化，就要從新修改、編譯、下載設備樹。比較極端的狀況是: 當項目中要支持多種的硬件模塊，而不一樣模塊間每每會共用某些系統資源(如IO引腳)。 一旦系統要兼容模塊任意組合使用，那麼隨着模塊數量增長，須要編譯的設備樹數量將爆炸增加。

所以，使用傳統設備樹是不利於項目的維護和擴展的。內核爲了解決這個提出了一套新的解決方案， 那就是Device Tree Overlays，中文上可理解爲」設備樹插件」。 它的核心原理是，經過擴展傳統的設備樹語法，使得各個硬件模塊的信息能夠獨立地用新的設備樹語法來描述。 這樣一來，傳統的主設備樹中只須要保留最基礎的硬件信息(主要是cpu和內存)，其餘模塊單獨編譯成」設備樹插件」。 在系統實際使用時，根據實際應用情景，須要用到哪些硬件模塊就把對應的設備樹插件加入到主設備樹便可。

「設備樹插件」無疑提升了系統的可維護性和減小了大量的重複工做，目前， 咱們已經把常見的硬件模塊都編譯成了」設備樹插件」,好比LCD、HDMI、WiFi等等。 用戶能夠經過fire-config工具輕鬆地實現對硬件模塊的便捷管理。

本來問題：

5.3 節 最後一句： 若是您但願配置立刻生效，肯定重啓系統便可。

既然是「插件」，爲何要重啓？ 不是熱拔插的麼？

究竟在哪裏加載 overlay 文件進內核的？

1. 內核加載的？
2. 操做系統加載的？

Device Tree Overlays 是怎麼運行的？

有朋友問我 Device Tree Overlays 是什麼，怎麼沒據說過。確實百度不多找到資料。 
我給出的中文名叫 設備樹堆疊功能。不必定準確。
內核描述在 Documentation/devicetree/overlay-notes.txt

Device Tree Overlays 核心定義：

在 kernel 啓動之後系統加載時候修改或者增長部分dts，最終把整個系統須要的設備驅動所有加載進去。

用處：

動態修改設備樹。
在用戶空間配置內核對象 Device Tree。

本質：

configfs - Userspace-driven kernel object configuration. 直接翻譯過來就是用戶空間配置內核對象，在configfs.txt中能夠看到其中的描述：configfs是一個基於ram的文件系統，經過對該文件系統的操做實現對內核對象的配置。

uboot 啓動內核

從 <Device Tree Overlays 核心定義> 來看，不是uboot的操做。
bootm <uImage_addr> <initrd_addr> <dtb_addr>

內核對 dtb 文件的解析位置

start_kernel -->setup_arch(&command_line) -->setup_machine_fdt(__fdt_pointer) -->unflatten_device_tree()

overlays 的調用位置

1. drivers/of/overlay.c 核心代碼。
   // Create and apply an overlay
   int of_overlay_create(struct device_node *tree);
   // Removes an overlay
   int of_overlay_destroy(int id);
   // Removes all overlays from the system
   int of_overlay_destroy_all(void);

2. 查找到 of_overlay_create 被 drivers/of/configfs.c 使用。
   configfs.c 最後一行 late_initcall(of_cfs_init) 標記 of_cfs_init 加入到 內核 .init 段。

3. .init 段被調用位置
   start_kernel -->rest_init() -->kernel_init() --> kernel_init_freeable() -->do_basic_setup() -->do_initcalls()
   注意： kernel_init_freeable() 是 kernel_init() 第一行。
   kernel_init 在完成一系列初始化以後啓動第一個用戶進程。內核啓動過程就結束了。

4. 調用 of_cfs_init 會在 /sys/kernel/config/ 目錄下建立 /sys/kernel/config/device-tree/overlay 文件(內存文件系統)。

configfs.c 的具體分析見參考文章
https://blog.csdn.net/liujiliei/article/details/105276551

內核啓動流程。

void __init start_kernel(void)
{
....
setup_arch(&command_line);
....
rest_init();
}

結論

/boot/overlay 目錄下的 *.dtbo 文件並非內核啓動過程當中加載和處理的。

那麼就要看是否是 UBOOT 和 操做系統init進程作的了。 稍後進行。

友善Nanopi neo core2

在該產品/boot 目錄下發現 overlay 相關內容。
分析 npi-config 使用的是 fdtput fdtget fdtdump 直接操做 /boot/.dtb 文件。
並無使用到 /boot/overlay/ 目錄下的 *.dtbo （overlay文件）文件。

參考文章：

https://blog.csdn.net/u014135607/article/details/79949571
https://blog.csdn.net/liujiliei/article/details/105276551

http://tinylab.org/lwn-616859/

國內論壇對此描述不多（某度也很不給力），本人英文不好。資源獲取很曲折，浪費很多時間。 大概整理的就這麼多。