dts，即device tree source，是一种以文本形式存在的文件，用于描述硬件信息。这些信息通常是固定的，不能更改，也不能进行overlay。
设备树的起源可以追溯到linux内核源码中。之前，内核中充斥着大量的平台相关配置，这些配置代码杂乱且重复，给ARM体系结构的代码维护者和内核维护者带来了巨大的工作量。2011年3月17日，Linus Torvalds在ARM Linux邮件列表中表达了对这种情况的不满，称“Gaah. Guys, this whole ARM thing is a f*cking pain in the ass”。这促使ARM社区重新审视平台配置问题，最终采用了设备树（Device Tree，DT）。需要指出的是，设备树最初是由开发固件（Open Firmware）使用的一部分，用于向客户程序（通常是操作系统）传递数据。在运行时，客户程序通过设备树发现设备的拓扑结构，从而避免将硬件信息硬编码到程序中。
设备树的作用是描述硬件的数据结构，可以将其视为一个大结构体，其中包含具体的设备。然而，设备树并不能解决所有的硬件配置问题（如机器识别），它只是一种将硬件配置从Linux内核源码中提取出来的语言。
Linux使用设备树的主要原因包括：
A:平台识别
B:实时配置
C:设备植入
设备树解耦的目标包括：
目标一：将与供应商相关的修改完全独立出来，不允许在SOC原生的dtsi文件中进行修改，只能以dtbo的方式存在。
目标二：同一基线项目的dtbo需要共用二进制文件。
设备树解耦框架设计如下：
设备树识别原理及设备树共用二进制文件的原理是：项目号（Project No）和PCB ID两个变量与dtbo文件中的两个属性“dtsi_No”和“pcb_No”完全匹配，就可以找到对应的dtbo文件。dtbo可以通过Makefile的控制打包到dtbo.img中，从而实现共用二进制文件。
设备树代码架构如下：
设备树overlay的规则如下：
规则1：对于同一个节点的设置，dts文件中的配置会覆盖dtsi文件中的配置。
规则2：对于节点的修改，需要先引用后修改。例如，原生节点定义如下：
如果需要在reserved-memory节点中添加新节点或直接修改其属性，必须先引用reserved_memory节点（注意节点的引用名与节点名可以不一致）。
如上例所示，引用reserved-memory节点后，删除了ranges属性和hyp_mem节点，并添加了kboot_uboot_logmem节点。
规则3：只有在引用申明的节点下，dtsi文件中的“&节点名”才会生效，否则引用点将不生效。例如，firmware节点下fstab节点的定义如下：
firmware:firmware中“：”之前的内容为引用申明，只有申明后才可以在其他地方引用。Firmware下的fstab节点没有引用声明，因此在其他位置不能引用。如果要修改fstab节点中的属性，需要引用firmware节点然后修改其属性，如下例所示：
对于同一个节点的设置，dts文件中的内容会覆盖dtsi文件中的内容。
在调试过程中，如果没有达到预期效果，需要先确定修改是否已编译到对应的dtbo.img中，这时需要反编译dtbo.img。
反编译工具自带于代码中，只需初始化一下环境变量即可使用。初始化指令如下：
反编译dtb.img和dtbo.img。
