系统对 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/

国内论坛对此描述不多（某度也很不给力），本人英文不好。资源获取很曲折，浪费很多时间。 大概整理的就这么多。