一、设备树的引入与作用
以 LED 驱动为例，如果你要更换 LED 所用的 GPIO 引脚，需要修改驱动程序 源码、重新编译驱动、重新加载驱动。
在内核中，使用同一个芯片的板子，它们所用的外设资源不一样，比如 A 板 用 GPIOA，B 板用 GPIOB。而 GPIO 的驱动程序既支持 GPIOA 也支持 GPIOB， 你需要指定使用哪一个引脚，怎么指定？在 c 代码中指定。
随着 ARM 芯片的流行，内核中针对这些 ARM 板保存有大量的、没有技术含量 的文件。
Linus 大发雷霆："this whole ARM thing is a f*cking pain in the ass"。
于是，Linux 内核开始引入设备树。
设备树并不是重新发明出来的，在 Linux 内核中其他平台如 PowerPC，早就使用设备树来描述硬件了。
Linus 发火之后，内核开始全面使用设备树来改造，神人就神人。 有一种错误的观点，说“新驱动都是用设备树来写了”。设备树不可能用来写驱动。
请想想，要操作硬件就需要去操作复杂的寄存器，如果设备树可以操作寄存器，那么它就是“驱动”，它就一样很复杂。
设备树只是用来给内核里的驱动程序，指定硬件的信息。比如 LED 驱动，在内核的驱动程序里去操作寄存器，但是操作哪一个引脚？这由设备树指定。
二、设备树的语法
2.1怎么描述这棵树？
我们需要编写设备树文件(dts: device tree source)，它需要编译为 dtb(device tree blob)文件，内核使用的是 dtb 文件。
dts 文件是根本，它的语法很简单。
下面是一个设备树示例：
它对应的 dts 文件如下：
dts-v1/l; / { model="fsl,mpc8572ds" compatible="fsl,mpc8572ds" #address-cells=<1> #size-cells=<l> cpus { #address-cells=<1> #size-cells=<0> cpu@0 { device_type="cpu" reg=<0> timebase-frequency=<825000000> clock-frequency=<825000000> }; cpu@1 { device_type="cpu" reg=<1> timebase-frequency=<825000000> clock-frequency=<825000000> }; }; memory@0 { device _type="memory" reg=<0 0x20000000> }; uart@fe001000 { compatible="ns16550" reg=<0xfe001000 0x100> }; chosen { bootargs="root=/ dev / sda2"; }; aliases { serial0="/uart@fe001000" }; };
2.2Devicetree 格式
2.2.1 DTS 文件的格式
DTS 文件布局(layout):
/dts-v1/; // 表示版本 [memory reservations] // 格式为: /memreserve/ <address> <length>; / { [property definitions] [child nodes] };
2.2.2 node 的格式
设备树中的基本单元，被称为“node”，其格式为：
[label:] node-name[@unit-address] { [properties definitions] [child nodes] };
label 是标号，可以省略。label 的作用是为了方便地引用 node，比如：
/dts-v1/; / { uart0: uart@fe001000 { compatible="ns16550"; reg=<0xfe001000 0x100>; }; };
可以使用下面 2 种方法来修改 uart@fe001000 这个 node：
// 在根节点之外使用 label 引用 node： &uart0 { status = “disabled”; }; // 或在根节点之外使用全路径： &{/uart@fe001000} { status = “disabled”; };
2.3 常用的节点(node)
2.3.1 根节点
dts 文件中必须有一个根节点：
/dts-v1/; / { model = "SMDK24440"; compatible = "samsung,smdk2440"; #address-cells = <1>; #size-cells = <1>; };
根节点中必须有这些属性：
#address-cells // 在它的子节点的 reg 属性中, 使用多少个 u32 整数来描述地址(address) #size-cells // 在它的子节点的 reg 属性中, 使用多少个 u32 整数来描述大小(size) compatible // 定义一系列的字符串, 用来指定内核中哪个 machine_desc 可以支持本设备 // 即这个板子兼容哪些平台 // uImage : smdk2410 smdk2440 mini2440 ==> machine_desc model // 咱这个板子是什么 // 比如有 2 款板子配置基本一致, 它们的 compatible 是一样的 // 那么就通过 model 来分辨这 2 款板子
2.3.2 CPU 节点
一般不需要我们设置，在 dtsi 文件中都定义好了：
cpus { #address-cells = <1>; #size-cells = <0>; cpu0: cpu@0 { ....... } };
2.3.3 memory 节点
芯片厂家不可能事先确定你的板子使用多大的内存，所以 memory节点需要板厂设置，比如：
memory { reg = <0x80000000 0x20000000>; };
2.3.4 chosen 节点
我们可以通过设备树文件给内核传入一些参数，这要在 chosen 节点中设置
bootargs 属性：
chosen { bootargs = "noinitrd root=/dev/mtdblock4 rw init=/linuxrc console=ttySAC0,115200"; };
2.4 常用的属性
2.4.1 #address-cells、#size-cells
⚫ cell 指一个 32 位的数值，
⚫ address-cells：address 要用多少个 32 位数来表示；
⚫ size-cells：size 要用多少个 32 位数来表示。
比如一段内存，怎么描述它的起始地址和大小？
下例中，address-cells 为 1，所以 reg 中用 1 个数来表示地址，即用 0x80000000来表示地址；size-cells 为 1，所以 reg 中用 1 个数来表示大小， 即用 0x20000000 表示大小：
/ { #address-cells = <1>; #size-cells = <1>; memory { reg = <0x80000000 0x20000000>; }; }
2.4.2 compatible
“compatible”表示“兼容”，对于某个 LED，内核中可能有 A、B、C 三个驱动都支持它，那可以这样写：
led { compatible = “A”, “B”, “C”; };
内核启动时，就会为这个 LED 按这样的优先顺序为它找到驱动程序：A、B、C。
根节点下也有 compatible 属性，用来选择哪一个“machine desc”：一个 内核可以支持 machine A，也支持 machine B，内核启动后会根据根节点的 compatible 属性找到对应的 machine desc 结构体，执行其中的初始化函数。
compatible 的值，建议取这样的形式："manufacturer,model"，即“厂 家名，模块名”。
注意：machine desc 的意思就是“机器描述”，学到内核启动流程时才涉及。
2.4.3 model
model 属性与 compatible 属性有些类似，但是有差别。
compatible 属性是一个字符串列表，表示可以你的硬件兼容 A、B、C 等驱动；
model 用来准确地定义这个硬件是什么。 比如根节点中可以这样写：
{ compatible = "samsung,smdk2440", "samsung,mini2440"; model = "jz2440_v3"; };
它表示这个单板，可以兼容内核中的“smdk2440”，也兼容“mini2440”。
从 compatible 属性中可以知道它兼容哪些板，但是它到底是什么板？用 model 属性来明确。
2.4.4 status
dtsi 文件中定义了很多设备，但是在你的板子上某些设备是没有的。这时你可以给这个设备节点添加一个 status 属性，设置为“disabled”：
&uart1 { status = "disabled"; };
2.4.5 reg
reg 的本意是 register，用来表示寄存器地址。
但是在设备树里，它可以用来描述一段空间。反正对于ARM 系统，寄存器和内存是统一编址的，即访问寄存器时用某块地址，访问内存时用某块地址，在访问方法上没有区别。
reg 属性的值，是一系列的“address size”，用多少个 32 位的数来表示 address 和 size，由其父节点的#address-cells、#size-cells 决定。
示例：
/dts-v1/; / { #address-cells = <1>; #size-cells = <1>; memory { reg = <0x80000000 0x20000000>; }; };
/dts-v1/; #include <dt-bindings/input/input.h> #include "imx6ull.dtsi" / { …… };
2.5 dts 文件包含 dtsi 文件
设备树文件不需要我们从零写出来，内核支持了某款芯片比如 imx6ull，在内核的 arch/arm/boot/dts 目录下就有了能用的设备树模板，一般命名为 xxxx.dtsi。“i”表示“include”，被别的文件引用的。
我们使用某款芯片制作出了自己的单板，所用资源跟 xxxx.dtsi 是大部分相同，小部分不同，所以需要引脚 xxxx.dtsi 并修改。
dtsi 文件跟 dts 文件的语法是完全一样的。
dts 中可以包含.h 头文件，也可以包含 dtsi 文件，在.h 头文件中可以定义一些宏。
示例：
/dts-v1/; #include <dt-bindings/input/input.h> #include "imx6ull.dtsi" / { …… };
三、 编译、更换设备树
我们一般不会从零写 dts 文件，而是修改。程序员水平有高有低，改得对不对？需要编译一下。并且内核直接使用 dts 文件的话，就太低效了，它也需要使用二进制格式的 dtb 文件。
3.1在内核中直接 make
设置 ARCH、CROSS_COMPILE、PATH 这三个环境变量后，进入 ubuntu 上板子内核源码的目录，执行如下命令即可编译 dtb 文件：
make dtbs V=1
3.2 手工编译
除非你对设备树比较了解，否则不建议手工使用 dtc 工具直接编译。
内核目录下 scripts/dtc/dtc 是设备树的编译工具，直接使用它的话，包含其他文件时不能使用“#include”，而必须使用“/incldue”。
编译、反编译的示例命令如下，“-I”指定输入格式，“-O”指定输出格式，“- o”指定输出文件：
./scripts/dtc/dtc -I dts -O dtb -o tmp.dtb arch/arm/boot/dts/xxx.dts // 编译 dts 为 dt b ./scripts/dtc/dtc -I dtb -O dts -o tmp.dts arch/arm/boot/dts/xxx.dtb // 反编译 dtb 为 dts
3.3 给开发板更换设备树文件
怎么给各个单板编译出设备树文件，它们的设备树文件是哪一个？
基本方法都是：设置 ARCH、CROSS_COMPILE、PATH 这三个环境变量后，在 内核源码目录中执行：
make dtbs
3.4 板子启动后查看设备树
板子启动后执行下面的命令：
# ls /sys/firmware/ devicetree fdt
/sys/firmware/devicetree 目录下是以目录结构程现的 dtb 文件, 根节点对应 base 目录, 每一个节点对应一个目录, 每一个属性对应一个文件。
这些属性的值如果是字符串，可以使用 cat 命令把它打印出来；对于数值， 可以用 hexdump 把它打印出来。
还可以看到/sys/firmware/fdt 文件，它就是 dtb 格式的设备树文件，可以把它复制出来放到 ubuntu 上，执行下面的命令反编译出来(-I dtb：输入格 式是 dtb，-O dts：输出格式是 dts)：
cd 板子所用的内核源码目录 ./scripts/dtc/dtc -I dtb -O dts /从板子上/复制出来的/fdt -o tmp.dts
