1.3 编译、更换设备树
我们一般不会从零写dts文件，而是修改。程序员水平有高有低，改得对不对？需要编译一下。并且内核直接使用dts文件的话，就太低效了，它也需要使用二进制格式的dtb文件。
1.3.1 在内核中直接make
设置ARCH、CROSS_COMPILE、PATH这三个环境变量后，进入ubuntu上板子内核源码的目录，执行如下命令即可编译dtb文件：
make dtbs V=1
这些操作步骤在各个开发板的高级用户使用手册，或是链接中各个板子的页面里，都有说明。
以野火的IMX6UL为例，可以看到如下输出：
mkdir -p arch/arm/boot/dts/ ; arm-linux-gnueabihf-gcc -E -Wp,-MD,arch/arm/boot/dts/.imx6ull-14x14-ebf-mini.dtb.d.pre.tmp -nostdinc -I./arch/arm/boot/dts -I./arch/arm/boot/dts/include -I./drivers/of/testcase-data -undef -D__DTS__ -x assembler-with-cpp -o arch/arm/boot/dts/.imx6ull-14x14-ebf-mini.dtb.dts.tmp arch/arm/boot/dts/imx6ull-14x14-ebf-mini.dts ; ./scripts/dtc/dtc -O dtb -o arch/arm/boot/dts/imx6ull-14x14-ebf-mini.dtb -b 0 -i arch/arm/boot/dts/ -Wno-unit_address_vs_reg -d arch/arm/boot/dts/.imx6ull-14x14-ebf-mini.dtb.d.dtc.tmp arch/arm/boot/dts/.imx6ull-14x14-ebf-mini.dtb.dts.tmp ;
它首先用arm-linux-gnueabihf-gcc预处理dts文件，把其中的.h头文件包含进来，把宏展开。
然后使用scripts/dtc/dtc生成dtb文件。
可见，dts文件之所以支持“#include”语法，是因为arm-linux-gnueabihf-gcc帮忙。
如果只用dtc工具，它是不支持”#include”语法的，只支持“/include”语法。
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为dtb ./scripts/dtc/dtc -I dtb -O dts -o tmp.dts arch/arm/boot/dts/xxx.dtb // 反编译dtb为dts
1.3.3 给开发板更换设备树文件
怎么给各个单板编译出设备树文件，它们的设备树文件是哪一个？
这些操作步骤在各个开发板的高级用户使用手册，或是链接中各个板子的页面里，都有说明。
基本方法都是：设置ARCH、CROSS_COMPILE、PATH这三个环境变量后，在内核源码目录中执行：
make dtbs
1.3.3.4 对于百问网使用QEMU模拟的IMX6ULL板子
设备树文件是：内核源码目录中arch/arm/boot/dts/100ask_imx6ul_qemu.dtb
它是执行qemu时直接在命令行中指定设备树文件的，你可以打开脚本文件qemu-imx6ul-gui.sh找到dtb文件的位置，然后使用新编译出来的dtb去覆盖老文件。
1.3.3.5 对于野火imx6ull-pro
设备树文件是：内核源码目录中arch/arm/boot/dts/imx6ull-14x14-ebf.dtb
对于这款板子，本教程中我们使用SD卡上的系统。
要更换板上的设备树文件，你可以使用SD卡启动开发板后，更换这个文件：/boot/imx6ull-14x14-ebf.dtb
1.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
1.4 内核对设备树的处理
从源代码文件dts文件开始，设备树的处理过程为：
① dts在PC机上被编译为dtb文件；
② u-boot把dtb文件传给内核；
③内核解析dtb文件，把每一个节点都转换为device_node结构体；
④对于某些device_node结构体，会被转换为platform_device结构体。
1.4.1 dtb中每一个节点都被转换为device_node结构体
根节点被保存在全局变量of_root中，从of_root开始可以访问到任意节点。
1.4.2 哪些设备树节点会被转换为platform_device
A. 根节点下含有compatile属性的子节点
B. 含有特定compatile属性的节点的子节点
如果一个节点的compatile属性，它的值是这4者之一："simple-bus","simple-mfd","isa","arm,amba-bus",那么它的子结点(需含compatile属性)也可以转换为platform_device。
C. 总线I2C、SPI节点下的子节点：不转换为platform_device 某个总线下到子节点，应该交给对应的总线驱动程序来处理,它们不应该被转换为platform_device。
比如以下的节点中： /mytest会被转换为platform_device, 因为它兼容"simple-bus";
它的子节点/mytest/mytest@0 也会被转换为platform_device /i2c节点一般表示i2c控制器,
它会被转换为platform_device, 在内核中有对应的platform_driver;
/i2c/at24c02节点不会被转换为platform_device, 它被如何处理完全由父节点的platform_driver决定,一般是被创建为一个i2c_client。 类似的也有/spi节点, 它一般也是用来表示SPI控制器,它会被转换为platform_device, 在内核中有对应的platform_driver;
/spi/flash@0节点不会被转换为platform_device, 它被如何处理完全由父节点的platform_driver决定, 一般是被创建为一个spi_device。
/ { mytest { compatile = "mytest", "simple-bus"; mytest@0 { compatile = "mytest_0"; }; }; i2c { compatile = "samsung,i2c"; at24c02 { compatile = "at24c02"; }; }; spi { compatile = "samsung,spi"; flash@0 { compatible = "winbond,w25q32dw"; spi-max-frequency = <25000000>; reg = <0>; }; }; };
1.4.3 怎么转换为platform_device
内核处理设备树的函数调用过程，这里不去分析；我们只需要得到如下结论：
A. platform_device中含有resource数组,它来自device_node的reg, interrupts属性;
B. platform_device.dev.of_node指向device_node, 可以通过它获得其他属性
1.5 platform_device如何与platform_driver配对
从设备树转换得来的platform_device会被注册进内核里，以后当我们每注册一个platform_driver时，它们就会两两确定能否配对，如果能配对成功就调用platform_driver的probe函数。
套路是一样的。 我们需要将前面讲过的“匹配规则”再完善一下： 先贴源码：
1.5.1 最先比较：是否强制选择某个driver
比较platform_device. driver_override和platform_driver.driver.name
可以设置platform_device的driver_override，强制选择某个platform_driver。
1.5.2 然后比较：设备树信息
比较：platform_device. dev.of_node和platform_driver.driver.of_match_table。
由设备树节点转换得来的platform_device中，含有一个结构体：of_node。 它的类型如下：
如果一个platform_driver支持设备树，它的platform_driver.driver.of_match_table是一个数组，类型如下：
使用设备树信息来判断dev和drv是否配对时，
首先，如果of_match_table中含有compatible值，就跟dev的compatile属性比较，若一致则成功，否则返回失败；
其次，如果of_match_table中含有type值，就跟dev的device_type属性比较，若一致则成功，否则返回失败；
最后，如果of_match_table中含有name值，就跟dev的name属性比较，若一致则成功，否则返回失败。
而设备树中建议不再使用devcie_type和name属性，所以基本上只使用设备节点的compatible属性来寻找匹配的platform_driver。
1.5.3 接下来比较：platform_device_id
比较platform_device. name和platform_driver.id_table[i].name，id_table中可能有多项。
platform_driver.id_table是“platform_device_id”指针，表示该drv支持若干个device，它里面列出了各个device的{.name, .driver_data}，其中的“name”表示该drv支持的设备的名字，driver_data是些提供给该device的私有数据。
1.5.4 最后比较：platform_device.name和platform_driver.driver.name
platform_driver.id_table可能为空， 这时可以根据platform_driver.driver.name来寻找同名的platform_device。
1.5.5 一个图概括所有的配对过程
概括出了这个图：
1.6 没有转换为platform_device的节点，如何使用
任意驱动程序里，都可以直接访问设备树。 你可以使用下面1.7中介绍的函数找到节点，读出里面的值。
1.7 内核里操作设备树的常用函数
内核源码中include/linux/目录下有很多of开头的头文件，of表示“open firmware”即开放固件。
1.7.1 内核中设备树相关的头文件介绍
设备树的处理过程是：dtb -> device_node -> platform_device。
1.7.1.1 处理DTB
of_fdt.h // dtb文件的相关操作函数, 我们一般用不到, // 因为dtb文件在内核中已经被转换为device_node树(它更易于使用) 1 2 1.7.1.2 处理device_node of.h // 提供设备树的一般处理函数, // 比如 of_property_read_u32(读取某个属性的u32值), // of_get_child_count(获取某个device_node的子节点数) of_address.h // 地址相关的函数, // 比如 of_get_address(获得reg属性中的addr, size值) // of_match_device (从matches数组中取出与当前设备最匹配的一项) of_dma.h // 设备树中DMA相关属性的函数 of_gpio.h // GPIO相关的函数 of_graph.h // GPU相关驱动中用到的函数, 从设备树中获得GPU信息 of_iommu.h // 很少用到 of_irq.h // 中断相关的函数 of_mdio.h // MDIO (Ethernet PHY) API of_net.h // OF helpers for network devices. of_pci.h // PCI相关函数 of_pdt.h // 很少用到 of_reserved_mem.h // reserved_mem的相关函数
1.7.1.3 处理 platform_device
of_platform.h // 把device_node转换为platform_device时用到的函数, // 比如of_device_alloc(根据device_node分配设置platform_device), // of_find_device_by_node (根据device_node查找到platform_device), // of_platform_bus_probe (处理device_node及它的子节点) of_device.h // 设备相关的函数, 比如 of_match_device
1.7.2 platform_device相关的函数
of_platform.h中声明了很多函数，但是作为驱动开发者，我们只使用其中的1、2个。其他的都是给内核自己使用的，内核使用它们来处理设备树，转换得到platform_device。
1.7.2.1 of_find_device_by_node
函数原型为：
extern struct platform_device *of_find_device_by_node(struct device_node *np);
设备树中的每一个节点，在内核里都有一个device_node；你可以使用device_node去找到对应的platform_device。
1.7.2.2 platform_get_resource
这个函数跟设备树没什么关系，但是设备树中的节点被转换为platform_device后，设备树中的reg属性、interrupts属性也会被转换为“resource”。
这时，你可以使用这个函数取出这些资源。
函数原型为：
/** * platform_get_resource - get a resource for a device * @dev: platform device * @type: resource type // 取哪类资源？IORESOURCE_MEM、IORESOURCE_REG * // IORESOURCE_IRQ等 * @num: resource index // 这类资源中的哪一个？ */ struct resource *platform_get_resource(struct platform_device *dev, unsigned int type, unsigned int num);
对于设备树节点中的reg属性，它对应IORESOURCE_MEM类型的资源；
对于设备树节点中的interrupts属性，它对应IORESOURCE_IRQ类型的资源。
