Dts：DTS即Device Tree Source，是一个文本形式的文件，用于描述硬件信息。一般都是固定信息，无法变更，无法overlay。
设备树由来
linux内核源码中，之前充斥着大量的平台相关（platform Device）配置，而这些代码大多是杂乱且重复的，这使得ARM体系结构的代码维护者和内核维护者在发布一个新的版本的时候有大量的工作要做，以至于LinusTorvalds 在2011年3月17日的ARM Linux邮件列表中宣称“Gaah.Guys,this whole ARM thing is a f*cking pain in the ass”这使得整个ARM社区不得不重新慎重考虑平台配置，于是设备树（Device Tree，DT）被ARM社区采用。需要说明的是，设备树最初是由开发固件（Open Firmware）使用的用来向客户程序（通常是一个操作系统）传递数据的通信方法中的一部分内容。在运行时，客户程序通过设备树发现设备的拓扑结构，这样就不需要把硬件信息硬编码到程序中。
设备树的作用
设备树是一个描述硬件的数据结构，甚至你可以将其看成一个大结构体（这个结构体就是平台，成员就是具体的设备），需要注意的是设备树并不能解决所有的硬件配置问题（例如：机器识别），它只是提供一种语言，将硬件的配置从linux内核的源码中提取出来。
Linux使用设备树的主要原因如下
A:平台识别
B:实时配置
C:设备植入
设备树解耦目标
目标一 vendor相关修改，完全独立出来，禁止在soc原生的dtsi中修改，只允许以dtbo的方式存在；
目标二 同基线项目dtbo要共二进制
设备树解耦框架设计
设备树识别原理及设备树共二进制原理
项目号（Project No）与 PCB ID两个变量同时与dtbo中的两个属性“dtsi_No”“pcb_No”完全匹配，就可以找到对应的dtbo文件。而dtbo可以通过Makefile的控制打包到dtbo.img中，这样就实现了共二进制。
设备树代码架构
设备树overlay规则
该节内容为overlay机制原生规则，罗列出来帮助驱动工程师解决各种异常问题。
规则1：对于同一个节点的设置情况，dts中的配置会覆盖dtsi中的配置；
规则2：对于节点的修改，先引用后修改；例如原生节点定义如下：
需要在reserved-memory节点中添加一个新的节点或者直接修改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
dtc-I dtb -O dts dtb.img -o dtsi.txt
反编译dtbo.img
mkdtimgdump dtbo.img -b dtbo dtc -I dtb -O dts dtbo.00 -o dtsi.txt
