DTBO（DTB Overlay，设备树块覆盖）用于在 DTB的基础上添加或修改节点信息。它可以配置 ODM和OEM特有的设备节点，使这些配置与 SoC 隔离，从而让配置与更新更加方便灵活。

首先本质上dtbo其实也是一个dtb文件，都是通过dtc工具编译出来的，它们甚至使用的dtc编译命令都是一样的。

可见在编译dtb和dtbo时的“input format”均是dts，“output format”均是dtb。

dtbo和dtb的主要差异是在其dts的写法上，dtbo的dts需要添加/plugin/；以表示该文件在编译时允许对不存在的解决做未定义引用。

例如：

DTB overlay是以node为单位的，并且需要被overlay的node需要在其node name前添加:，例如本例中的my_node。在dtbo中则是通过&\来引用要被overlay的节点，再去覆盖、新增property或者新增子节点。

其原理是：当调用dtc编译dtb时，如果额外地传入了"-@"参数，dtc会在最终的dtb中生成__symbols__节点，该节点中会收集所有带label的节点的在设备树中位置信息，格式= "";，形如：

开机log提示：

那么我们如何确保我们的新增或者想要覆盖的节点新增成功呢？

我们可以查看/proc/devices-tree下对应节点的子节点是否有新增。例如：再csi中新增csi_sr3_lane_pn_swap节点，在dtbo完成overlay之后就可以在csi节点下找到该子节点。

那么我们如何确保我们的新增或者想要覆盖的节点覆盖成功呢？

我们可能需要查看当前外设对应的设备树里面配置的信息，比如分辨率、时钟等. status、bus-width、name、max-frequency等 上面的属性，有些是string类型，有些是int类型。对于string类型，我们只需要找到对应的文件，直接cat，就能获取对应的信息。对于int类型，我们只需要找到对应的文件，通过hexdump来获取，以vif_sr0_mipi_mode为例， hexdump出来的信息如下：

hexdump出来的信息如上：

第一列0000000、0000004表示偏移量(可以自己去dump一个几十K的文件就明白了) 其他：0000 0600是数据。

可以参考覆盖前和覆盖后的数据差异知道是否有覆盖成功。

SigmaStar平台的DTB overlay都是在U-boot中完成的，所起开关以及相关的配置都是在U-boot的Kconfig中配置。

Uboot下：

每个Kconfig的作用参考其help信息，其中CONFIG_SSTAR_BUILTIN_KERNEL_DTB这一项的作用是将对builtin DTB的支持关闭。

例如：

其中CONFIG_SSTAR_UBOOT_DTB_OVERLAY用于使能U-boot DTB overlay功能， 

CONFIG_SSTAR_KERNEL_DTB_OVERLAY用于使能Kernel DTB overlay功能。

Kernel下：

Kernel设计的Kconfig并不多，最主要的是将builtin DTB的功能关闭，使Kernel接受并使用由U-boot传递过来的设备树。

例如：

目前在SigmaStar的Kernel中已经将dtbo、dtbo.img的制作整合成了一个kernel的build targe：dtbo_image,其定义位于kernel根目录的makefile。

所以基于kernel的环境，在kernel的根目录下执行：make dtbo_image,即会在当前目录生成dtbo.image.

手动release dtbo.image到imge包中，将名字修改为dtbo，替换原本image中的dtbo文件，在uboot下利用网络升级，使用命令estar scripts/[[dtbo.es即可完成dtbo的烧录替换。

为什么在利用dtbo功能修改padmux属性时，会出现其他bsp功能mode出错的情况？

dtbo功能只能完成对节点的追加覆盖， 在dtbo文件中对padmux操作其下的schematic子节点（数组属性的子节点，保存有一些IO的mode choose信息）时，只能对schmatic完成覆盖功能，即dtb_overlay文件中的schematic属性将会完全替代主设备树中的schematic属性。

所以我们在修改dtbo文件中修改padmux时，需要一并copy所有主设备树中padmux下的schmatic中所有其他我们不需要修改的配置，这样才会在改到我们自己想要修改的内容的同时，不影响到其他bsp功能。

END.

如果您对相关问题感兴趣，欢迎进入Comake社区开发论坛互动交流，或咨询官方客服。

推荐阅读：《社区资源汇总》