1）实验平台：正点原子阿尔法Linux开发板 2）平台购买地址：https://item.taobao.com/item.htm?id=603672744434 2）全套实验源码+手册+视频下载地址：http://www.openedv.com/thread-300792-1-1.html 3）对正点原子Linux感兴趣的同学可以加群讨论：935446741 4）关注正点原子公众号，获取最新资料更新 
第四十三章 Linux设备树
前面章节中我们多次提到“设备树”这个概念，因为时机未到，所以当时并没有详细的讲解什么是“设备树”，本章我们就来详细的谈一谈设备树。掌握设备树是Linux驱动开发人员必备的技能！因为在新版本的Linux中，ARM相关的驱动全部采用了设备树(也有支持老式驱动的，比较少)，最新出的CPU其驱动开发也基本都是基于设备树的，比如ST新出的STM32MP157、NXP的I.MX8系列等。我们所使用的Linux版本为4.1.15，其支持设备树，所以正点原子I.MX6U-ALPHA开发板的所有Linux驱动都是基于设备树的。本章我们就来了解一下设备树的起源、重点学习一下设备树语法。
43.1 什么是设备树？ 设备树(Device Tree)，将这个词分开就是“设备”和“树”，描述设备树的文件叫做DTS(Device Tree Source)，这个DTS文件采用树形结构描述板级设备，也就是开发板上的设备信息，比如CPU数量、 内存基地址、IIC接口上接了哪些设备、SPI接口上接了哪些设备等等，如图43.1.1所示：
图43.1.1 设备树结构示意图 在图43.1.1中，树的主干就是系统总线，IIC控制器、GPIO控制器、SPI控制器等都是接到系统主线上的分支。IIC控制器有分为IIC1和IIC2两种，其中IIC1上接了FT5206和AT24C02这两个IIC设备，IIC2上只接了MPU6050这个设备。DTS文件的主要功能就是按照图43.1.1所示的结构来描述板子上的设备信息，DTS文件描述设备信息是有相应的语法规则要求的，稍后我们会详细的讲解DTS语法规则。 在3.x版本(具体哪个版本笔者也无从考证)以前的Linux内核中ARM架构并没有采用设备树。在没有设备树的时候Linux是如何描述ARM架构中的板级信息呢？在Linux内核源码中大量的arch/arm/mach-xxx和arch/arm/plat-xxx文件夹，这些文件夹里面的文件就是对应平台下的板级信息。比如在arch/arm/mach-smdk2440.c中有如下内容(有缩减)： 示例代码43.1.1 mach-smdk2440.c文件代码段
90 static struct s3c2410fb_display smdk2440_lcd_cfg __initdata = {
91
92 .lcdcon5 = S3C2410_LCDCON5_FRM565 |
93 S3C2410_LCDCON5_INVVLINE |
94 S3C2410_LCDCON5_INVVFRAME |
95 S3C2410_LCDCON5_PWREN |
96 S3C2410_LCDCON5_HWSWP,
......
113 };
114
115 static struct s3c2410fb_mach_info smdk2440_fb_info __initdata = {
116 .displays = &smdk2440_lcd_cfg,
117 .num_displays = 1,
118 .default_display = 0,
......
133 };
134
135 static struct platform_device *smdk2440_devices[] __initdata = {
136 &s3c_device_ohci,
137 &s3c_device_lcd,
138 &s3c_device_wdt,
139 &s3c_device_i2c0,
140 &s3c_device_iis,
141 };
上述代码中的结构体变量smdk2440_fb_info就是描述SMDK2440这个开发板上的LCD信息的，结构体指针数组smdk2440_devices描述的SMDK2440这个开发板上的所有平台相关信息。这个仅仅是使用2440这个芯片的SMDK2440开发板下的LCD信息，SMDK2440开发板还有很多的其他外设硬件和平台硬件信息。使用2440这个芯片的板子有很多，每个板子都有描述相应板级信息的文件，这仅仅只是一个2440。随着智能手机的发展，每年新出的ARM架构芯片少说都在数十、数百款，Linux内核下板级信息文件将会成指数级增长！这些板级信息文件都是.c或.h文件，都会被硬编码进Linux内核中，导致Linux内核“虚胖”。就好比你喜欢吃自助餐，然后花了100多到一家宣传看着很不错的自助餐厅，结果你想吃的牛排、海鲜、烤肉基本没多少，全都是一些凉菜、炒面、西瓜、饮料等小吃，相信你此时肯定会脱口而出一句“F*k!”、“骗子！”。同样的，当Linux之父linus看到ARM社区向Linux内核添加了大量“无用”、冗余的板级信息文件，不禁的发出了一句“This whole ARM thing is a f*cking pain in the ass”。从此以后ARM社区就引入了PowerPC等架构已经采用的设备树(Flattened Device Tree)，将这些描述板级硬件信息的内容都从Linux内中分离开来，用一个专属的文件格式来描述，这个专属的文件就叫做设备树，文件扩展名为.dts。一个SOC可以作出很多不同的板子，这些不同的板子肯定是有共同的信息，将这些共同的信息提取出来作为一个通用的文件，其他的.dts文件直接引用这个通用文件即可，这个通用文件就是.dtsi文件，类似于C语言中的头文件。一般.dts描述板级信息(也就是开发板上有哪些IIC设备、SPI设备等)，.dtsi描述SOC级信息(也就是SOC有几个CPU、主频是多少、各个外设控制器信息等)。
这个就是设备树的由来，简而言之就是，Linux内核中ARM架构下有太多的冗余的垃圾板级信息文件，导致linus震怒，然后ARM社区引入了设备树。
43.2 DTS、DTB和DTC 上一小节说了，设备树源文件扩展名为.dts，但是我们在前面移植Linux的时候却一直在使用.dtb文件，那么DTS和DTB这两个文件是什么关系呢？DTS是设备树源码文件，DTB是将DTS编译以后得到的二进制文件。将.c文件编译为.o需要用到gcc编译器，那么将.dts编译为.dtb需要什么工具呢？需要用到DTC工具！DTC工具源码在Linux内核的scripts/dtc目录下，scripts/dtc/Makefile文件内容如下： 示例代码43.2.1 scripts/dtc/Makefile文件代码段
1 hostprogs-y := dtc
2 always := $(hostprogs-y)
3
4 dtc-objs:= dtc.o flattree.o fstree.o data.o livetree.o treesource.o \
5 srcpos.o checks.o util.o
6 dtc-objs += dtc-lexer.lex.o dtc-parser.tab.o
......
可以看出，DTC工具依赖于dtc.c、flattree.c、fstree.c等文件，最终编译并链接出DTC这个主机文件。如果要编译DTS文件的话只需要进入到Linux源码根目录下，然后执行如下命令：
make all 或者： make dtbs “make all”命令是编译Linux源码中的所有东西，包括zImage，.ko驱动模块以及设备树，如果只是编译设备树的话建议使用“make dtbs”命令。 基于ARM架构的SOC有很多种，一种SOC又可以制作出很多款板子，每个板子都有一个对应的DTS文件，那么如何确定编译哪一个DTS文件呢？我们就以I.MX6ULL这款芯片对应的板子为例来看一下，打开arch/arm/boot/dts/Makefile，有如下内容： 示例代码43.2.2 arch/arm/boot/dts/Makefile文件代码段
381 dtb-$(CONFIG_SOC_IMX6UL) += \
382 imx6ul-14x14-ddr3-arm2.dtb \
383 imx6ul-14x14-ddr3-arm2-emmc.dtb \
......
400 dtb-$(CONFIG_SOC_IMX6ULL) += \
401 imx6ull-14x14-ddr3-arm2.dtb \
402 imx6ull-14x14-ddr3-arm2-adc.dtb \
403 imx6ull-14x14-ddr3-arm2-cs42888.dtb \
404 imx6ull-14x14-ddr3-arm2-ecspi.dtb \
405 imx6ull-14x14-ddr3-arm2-emmc.dtb \
406 imx6ull-14x14-ddr3-arm2-epdc.dtb \
407 imx6ull-14x14-ddr3-arm2-flexcan2.dtb \
408 imx6ull-14x14-ddr3-arm2-gpmi-weim.dtb \
409 imx6ull-14x14-ddr3-arm2-lcdif.dtb \
410 imx6ull-14x14-ddr3-arm2-ldo.dtb \
411 imx6ull-14x14-ddr3-arm2-qspi.dtb \
412 imx6ull-14x14-ddr3-arm2-qspi-all.dtb \
413 imx6ull-14x14-ddr3-arm2-tsc.dtb \
414 imx6ull-14x14-ddr3-arm2-uart2.dtb \
415 imx6ull-14x14-ddr3-arm2-usb.dtb \
416 imx6ull-14x14-ddr3-arm2-wm8958.dtb \
417 imx6ull-14x14-evk.dtb \
418 imx6ull-14x14-evk-btwifi.dtb \
419 imx6ull-14x14-evk-emmc.dtb \
420 imx6ull-14x14-evk-gpmi-weim.dtb \
421 imx6ull-14x14-evk-usb-certi.dtb \
422 imx6ull-alientek-emmc.dtb \
423 imx6ull-alientek-nand.dtb \
424 imx6ull-9x9-evk.dtb \
425 imx6ull-9x9-evk-btwifi.dtb \
426 imx6ull-9x9-evk-ldo.dtb
427 dtb-$(CONFIG_SOC_IMX6SLL) += \
428 imx6sll-lpddr2-arm2.dtb \
429 imx6sll-lpddr3-arm2.dtb \
......
可以看出，当选中I.MX6ULL这个SOC以后(CONFIG_SOC_IMX6ULL=y)，所有使用到I.MX6ULL这个SOC的板子对应的.dts文件都会被编译为.dtb。如果我们使用I.MX6ULL新做了一个板子，只需要新建一个此板子对应的.dts文件，然后将对应的.dtb文件名添加到dtb-$(CONFIG_SOC_IMX6ULL)下，这样在编译设备树的时候就会将对应的.dts编译为二进制的.dtb文件。
示例代码43.2.2中第422和423行就是我们在给正点原子的I.MX6U-ALPHA开发板移植Linux系统的时候添加的设备树。关于.dtb文件怎么使用这里就不多说了，前面讲解Uboot移植、Linux内核移植的时候已经无数次的提到如何使用.dtb文件了(uboot中使用bootz或bootm命令向Linux内核传递二进制设备树文件(.dtb))。
43.3 DTS语法 虽然我们基本上不会从头到尾重写一个.dts文件，大多时候是直接在SOC厂商提供的.dts文件上进行修改。但是DTS文件语法我们还是需要详细的学习一遍，因为我们肯定需要修改.dts文件。大家不要看到要学习新的语法就觉得会很复杂，DTS语法非常的人性化，是一种ASCII文本文件，不管是阅读还是修改都很方便。 本节我们就以imx6ull-alientek-emmc.dts这个文件为例来讲解一下DTS语法。关于设备树详细的语法规则请参考《Devicetree SpecificationV0.2.pdf》和《Power_ePAPR_APPROVED_v1.12.pdf》这两份文档，此两份文档已经放到了开发板光盘中，路径为：4、参考资料->Devicetree SpecificationV0.2.pdf、4、参考资料-> Power_ePAPR_APPROVED_v1.12.pdf 43.3.1 .dtsi头文件 和C语言一样，设备树也支持头文件，设备树的头文件扩展名为.dtsi。在imx6ull-alientek-emmc.dts中有如下所示内容： 示例代码43.3.1.1 imx6ull-alientek-emmc.dts文件代码段 12 #include 13 #include “imx6ull.dtsi” 第12行，使用“#include”来引用“input.h”这个.h头文件。 第13行，使用“#include”来引用“imx6ull.dtsi”这个.dtsi头文件。 看到这里，大家可能会疑惑，不是说设备树的扩展名是.dtsi吗？为什么也可以直接引用C语言中的.h头文件呢？这里并没有错，.dts文件引用C语言中的.h文件，甚至也可以引用.dts文件，打开imx6ull-14x14-evk-gpmi-weim.dts这个文件，此文件中有如下内容： 示例代码43.3.1.2 imx6ull-14x14-evk-gpmi-weim.dts文件代码段 9 #include “imx6ull-14x14-evk.dts” 可以看出，示例代码43.3.1.2中直接引用了.dts文件，因此在.dts设备树文件中，可以通过“#include”来引用.h、.dtsi和.dts文件。只是，我们在编写设备树头文件的时候最好选择.dtsi后缀。 一般.dtsi文件用于描述SOC的内部外设信息，比如CPU架构、主频、外设寄存器地址范围，比如UART、IIC等等。比如imx6ull.dtsi就是描述I.MX6ULL这颗SOC内部外设情况信息的，内容如下： 示例代码43.3.1.3 imx6ull.dtsi文件代码段
10 #include
11 #include
12 #include
13 #include "imx6ull-pinfunc.h"
14 #include "imx6ull-pinfunc-snvs.h"
15 #include "skeleton.dtsi"
16
17 / {
18 aliases {
19 can0 = &flexcan1;
......
48 };
49
50 cpus {
51 #address-cells = ;
52 #size-cells = ;
53
54 cpu0: cpu@0 {
55 compatible = "arm,cortex-a7";
56 device_type = "cpu";
......
89 };
90 };
91
92 intc: interrupt-controller@00a01000 {
93 compatible = "arm,cortex-a7-gic";
94 #interrupt-cells = ;
95 interrupt-controller;
96 reg = ,
97 ;
98 };
99
100 clocks {
101 #address-cells = ;
102 #size-cells = ;
103
104 ckil: clock@0 {
105 compatible = "fixed-clock";
106 reg = ;
107 #clock-cells = ;
108 clock-frequency = ;
109 clock-output-names = "ckil";
110 };
......
135 };
136
137 soc {
138 #address-cells = ;
139 #size-cells = ;
140 compatible = "simple-bus";
141 interrupt-parent = ;
142 ranges;
143
144 busfreq {
145 compatible = "fsl,imx_busfreq";
......
162 };
197
198 gpmi: gpmi-nand@01806000{
199 compatible = "fsl,imx6ull-gpmi-nand", "fsl, imx6ul-gpmi-nand";
200 #address-cells = ;
201 #size-cells = ;
202 reg = , ;
......
216 };
......
1177 };
1178 };
示例代码43.3.1.3中第54~89行就是cpu0这个设备节点信息，这个节点信息描述了I.MX6ULL这颗SOC所使用的CPU信息，比如架构是cortex-A7，频率支持996MHz、792MHz、528MHz、396MHz和198MHz等等。在imx6ull.dtsi文件中不仅仅描述了cpu0这一个节点信息，I.MX6ULL这颗SOC所有的外设都描述的清清楚楚，比如ecspi1~4、uart1~8、usbphy1~2、i2c1~4等等，关于这些设备节点信息的具体内容我们稍后在详细的讲解。
43.3.2 设备节点 设备树是采用树形结构来描述板子上的设备信息的文件，每个设备都是一个节点，叫做设备节点，每个节点都通过一些属性信息来描述节点信息，属性就是键—值对。以下是从imx6ull.dtsi文件中缩减出来的设备树文件内容： 示例代码43.3.2.1 设备树模板
1 / {
2 aliases {
3 can0 = &flexcan1;
4 };
5
6 cpus {
7 #address-cells = ;
8 #size-cells = ;
9
10 cpu0: cpu@0 {
11 compatible = "arm,cortex-a7";
12 device_type = "cpu";
13 reg = ;
14 };
15 };
16
17 intc: interrupt-controller@00a01000 {
18 compatible = "arm,cortex-a7-gic";
19 #interrupt-cells = ;
20 interrupt-controller;
21 reg = ,
22 ;
23 };
24 }
第1行，“/”是根节点，每个设备树文件只有一个根节点。细心的同学应该会发现，imx6ull.dtsi和imx6ull-alientek-emmc.dts这两个文件都有一个“/”根节点，这样不会出错吗？不会的，因为这两个“/”根节点的内容会合并成一个根节点。
第2、6和17行，aliases、cpus和intc是三个子节点，在设备树中节点命名格式如下：
node-name@unit-address 其中“node-name”是节点名字，为ASCII字符串，节点名字应该能够清晰的描述出节点的功能，比如“uart1”就表示这个节点是UART1外设。“unit-address”一般表示设备的地址或寄存器首地址，如果某个节点没有地址或者寄存器的话“unit-address”可以不要，比如“cpu@0”、“interrupt-controller@00a01000”。 但是我们在示例代码43.3.2.1中我们看到的节点命名却如下所示： cpu0:cpu@0 上述命令并不是“node-name@unit-address”这样的格式，而是用“：”隔开成了两部分，“：”前面的是节点标签(label)，“：”后面的才是节点名字，格式如下所示： label: node-name@unit-address 引入label的目的就是为了方便访问节点，可以直接通过&label来访问这个节点，比如通过&cpu0就可以访问“cpu@0”这个节点，而不需要输入完整的节点名字。再比如节点 “intc: interrupt-controller@00a01000”，节点label是intc，而节点名字就很长了，为“interrupt-controller@00a01000”。很明显通过&intc来访问“interrupt-controller@00a01000”这个节点要方便很多！ 第10行，cpu0也是一个节点，只是cpu0是cpus的子节点。 每个节点都有不同属性，不同的属性又有不同的内容，属性都是键值对，值可以为空或任意的字节流。设备树源码中常用的几种数据形式如下所示： ①、字符串 compatible = “arm,cortex-a7”; 上述代码设置compatible属性的值为字符串“arm,cortex-a7”。 ②、32位无符号整数 reg = ; 上述代码设置reg属性的值为0，reg的值也可以设置为一组值，比如： reg = ; ③、字符串列表 属性值也可以为字符串列表，字符串和字符串之间采用“,”隔开，如下所示： compatible = “fsl,imx6ull-gpmi-nand”, “fsl, imx6ul-gpmi-nand”; 上述代码设置属性compatible的值为“fsl,imx6ull-gpmi-nand”和“fsl, imx6ul-gpmi-nand”。 43.3.3 标准属性 节点是由一堆的属性组成，节点都是具体的设备，不同的设备需要的属性不同，用户可以自定义属性。除了用户自定义属性，有很多属性是标准属性，Linux下的很多外设驱动都会使用这些标准属性，本节我们就来学习一下几个常用的标准属性。 1、compatible属性 compatible属性也叫做“兼容性”属性，这是非常重要的一个属性！compatible属性的值是一个字符串列表，compatible属性用于将设备和驱动绑定起来。字符串列表用于选择设备所要使用的驱动程序，compatible属性的值格式如下所示： “manufacturer,model” 其中manufacturer表示厂商，model一般是模块对应的驱动名字。比如imx6ull-alientek-emmc.dts中sound节点是I.MX6U-ALPHA开发板的音频设备节点，I.MX6U-ALPHA开发板上的音频芯片采用的欧胜(WOLFSON)出品的WM8960，sound节点的compatible属性值如下： compatible = “fsl,imx6ul-evk-wm8960”,“fsl,imx-audio-wm8960”; 属性值有两个，分别为“fsl,imx6ul-evk-wm8960”和“fsl,imx-audio-wm8960”，其中“fsl”表示厂商是飞思卡尔，“imx6ul-evk-wm8960”和“imx-audio-wm8960”表示驱动模块名字。sound这个设备首先使用第一个兼容值在Linux内核里面查找，看看能不能找到与之匹配的驱动文件，如果没有找到的话就使用第二个兼容值查。 一般驱动程序文件都会有一个OF匹配表，此OF匹配表保存着一些compatible值，如果设备节点的compatible属性值和OF匹配表中的任何一个值相等，那么就表示设备可以使用这个驱动。比如在文件imx-wm8960.c中有如下内容： 示例代码43.3.3.1 imx-wm8960.c文件代码段
632 static const struct of_device_id imx_wm8960_dt_ids[] = {
633 { .compatible = "fsl,imx-audio-wm8960", },
634 { /* sentinel */ }
635 };
636 MODULE_DEVICE_TABLE(of, imx_wm8960_dt_ids);
637
638 static struct platform_driver imx_wm8960_driver = {
639 .driver = {
640 .name = "imx-wm8960",
641 .pm = &snd_soc_pm_ops,
642 .of_match_table = imx_wm8960_dt_ids,
643 },
644 .probe = imx_wm8960_probe,
645 .remove = imx_wm8960_remove,
646 };
第632~635行的数组imx_wm8960_dt_ids就是imx-wm8960.c这个驱动文件的匹配表，此匹配表只有一个匹配值“fsl,imx-audio-wm8960”。如果在设备树中有哪个节点的compatible属性值与此相等，那么这个节点就会使用此驱动文件。
第642行，wm8960采用了platform_driver驱动模式，关于platform_driver驱动后面会讲解。此行设置.of_match_table为imx_wm8960_dt_ids，也就是设置这个platform_driver所使用的OF匹配表。
2、model属性
model属性值也是一个字符串，一般model属性描述设备模块信息，比如名字什么的，比如：
model = “wm8960-audio”; 3、status属性 status属性看名字就知道是和设备状态有关的，status属性值也是字符串，字符串是设备的状态信息，可选的状态如表43.3.3.1所示： 值 描述 “okay” 表明设备是可操作的。 “disabled” 表明设备当前是不可操作的，但是在未来可以变为可操作的，比如热插拔设备插入以后。至于disabled的具体含义还要看设备的绑定文档。 “fail” 表明设备不可操作，设备检测到了一系列的错误，而且设备也不大可能变得可操作。 “fail-sss” 含义和“fail”相同，后面的sss部分是检测到的错误内容。 表43.3.3.1 status属性值表 4、#address-cells和#size-cells属性 这两个属性的值都是无符号32位整形，#address-cells和#size-cells这两个属性可以用在任何拥有子节点的设备中，用于描述子节点的地址信息。#address-cells属性值决定了子节点reg属性中地址信息所占用的字长(32位)，#size-cells属性值决定了子节点reg属性中长度信息所占的字长(32位)。#address-cells和#size-cells表明了子节点应该如何编写reg属性值，一般reg属性都是和地址有关的内容，和地址相关的信息有两种：起始地址和地址长度，reg属性的格式一为： reg = 每个“address length”组合表示一个地址范围，其中address是起始地址，length是地址长度，#address-cells表明address这个数据所占用的字长，#size-cells表明length这个数据所占用的字长，比如: 示例代码43.3.3.2 #address-cells和#size-cells属性
1 spi4 {
2 compatible = "spi-gpio";
3 #address-cells = ;
4 #size-cells = ;
5
6 gpio_spi: gpio_spi@0 {
7 compatible = "fairchild,74hc595";
8 reg = ;
9 };
10 };
11
12 aips3: aips-bus@02200000 {
13 compatible = "fsl,aips-bus", "simple-bus";
14 #address-cells = ;
15 #size-cells = ;
16
17 dcp: dcp@02280000 {
18 compatible = "fsl,imx6sl-dcp";
19 reg = ;
20 };
21 };
第3，4行，节点spi4的#address-cells = ，#size-cells = ，说明spi4的子节点reg属性中起始地址所占用的字长为1，地址长度所占用的字长为0。
第8行，子节点gpio_spi: gpio_spi@0的reg 属性值为 ，因为父节点设置了#address-cells = ，#size-cells = ，因此addres=0，没有length的值，相当于设置了起始地址，而没有设置地址长度。
第14，15行，设置aips3: aips-bus@02200000节点#address-cells = ，#size-cells = ，说明aips3: aips-bus@02200000节点起始地址长度所占用的字长为1，地址长度所占用的字长也为1。
第19行，子节点dcp: dcp@02280000的reg属性值为，因为父节点设置了#address-cells = ，#size-cells = ，address= 0x02280000，length= 0x4000，相当于设置了起始地址为0x02280000，地址长度为0x40000。
5、reg属性
reg属性前面已经提到过了，reg属性的值一般是(address，length)对。reg属性一般用于描述设备地址空间资源信息，一般都是某个外设的寄存器地址范围信息，比如在imx6ull.dtsi中有如下内容：
示例代码43.3.3.3 uart1节点信息
323 uart1: serial@02020000 {
324 compatible = "fsl,imx6ul-uart",
325 "fsl,imx6q-uart", "fsl,imx21-uart";
326 reg = ;
327 interrupts = ;
328 clocks = ,
329 ;
330 clock-names = "ipg", "per";
331 status = "disabled";
332 };
上述代码是节点uart1，uart1节点描述了I.MX6ULL的UART1相关信息，重点是第326行的reg属性。其中uart1的父节点aips1: aips-bus@02000000设置了#address-cells = 、#size-cells = ，因此reg属性中address=0x02020000，length=0x4000。查阅《I.MX6ULL参考手册》可知，I.MX6ULL的UART1寄存器首地址为0x02020000，但是UART1的地址长度(范围)并没有0x4000这么多，这里我们重点是获取UART1寄存器首地址。
6、ranges属性
ranges属性值可以为空或者按照(child-bus-address,parent-bus-address,length)格式编写的数字矩阵，ranges是一个地址映射/转换表，ranges属性每个项目由子地址、父地址和地址空间长度这三部分组成：
child-bus-address：子总线地址空间的物理地址，由父节点的#address-cells确定此物理地址所占用的字长。
parent-bus-address：父总线地址空间的物理地址，同样由父节点的#address-cells确定此物理地址所占用的字长。
length：子地址空间的长度，由父节点的#size-cells确定此地址长度所占用的字长。
如果ranges属性值为空值，说明子地址空间和父地址空间完全相同，不需要进行地址转换，对于我们所使用的I.MX6ULL来说，子地址空间和父地址空间完全相同，因此会在imx6ull.dtsi中找到大量的值为空的ranges属性，如下所示：
示例代码43.3.3.4 imx6ull.dtsi文件代码段
137 soc {
138 #address-cells = ;
139 #size-cells = ;
140 compatible = "simple-bus";
141 interrupt-parent = ;
142 ranges;
......
1177 }
第142行定义了ranges属性，但是ranges属性值为空。
ranges属性不为空的示例代码如下所示： 示例代码43.3.3.5 ranges属性不为空
1 soc {
2 compatible = "simple-bus";
3 #address-cells = ;
4 #size-cells = ;
5 ranges = ;
6
7 serial {
8 device_type = "serial";
9 compatible = "ns16550";
10 reg = ;
11 clock-frequency = ;
12 interrupts = ;
13 interrupt-parent = ;
14 };
15 };
第5行，节点soc定义的ranges属性，值为，此属性值指定了一个1024KB(0x00100000)的地址范围，子地址空间的物理起始地址为0x0，父地址空间的物理起始地址为0xe0000000。
第10行，serial是串口设备节点，reg属性定义了serial设备寄存器的起始地址为0x4600，寄存器长度为0x100。经过地址转换，serial设备可以从0xe0004600开始进行读写操作，0xe0004600=0x4600+0xe0000000。
7、name属性
name属性值为字符串，name属性用于记录节点名字，name属性已经被弃用，不推荐使用name属性，一些老的设备树文件可能会使用此属性。
8、device_type属性
device_type属性值为字符串，IEEE 1275会用到此属性，用于描述设备的FCode，但是设备树没有FCode，所以此属性也被抛弃了。此属性只能用于cpu节点或者memory节点。imx6ull.dtsi的cpu0节点用到了此属性，内容如下所示：
示例代码43.3.3.6 imx6ull.dtsi文件代码段
54 cpu0: cpu@0 {
55 compatible = "arm,cortex-a7";
56 device_type = "cpu";
57 reg = ;
......
89 };
关于标准属性就讲解这么多，其他的比如中断、IIC、SPI等使用的标准属性等到具体的例程再讲解。
43.3.4 根节点compatible属性 每个节点都有compatible属性，根节点“/”也不例外，imx6ull-alientek-emmc.dts文件中根节点的compatible属性内容如下所示： 示例代码43.3.4.1 imx6ull-alientek-emmc.dts根节点compatible属性
14 / {
15 model = "Freescale i.MX6 ULL 14x14 EVK Board";
16 compatible = "fsl,imx6ull-14x14-evk", "fsl,imx6ull";
......
148 }
可以看出，compatible有两个值：“fsl,imx6ull-14x14-evk”和“fsl,imx6ull”。前面我们说了，设备节点的compatible属性值是为了匹配Linux内核中的驱动程序，那么根节点中的compatible属性是为了做什么工作的？ 通过根节点的compatible属性可以知道我们所使用的设备，一般第一个值描述了所使用的硬件设备名字，比如这里使用的是“imx6ull-14x14-evk”这个设备，第二个值描述了设备所使用的SOC，比如这里使用的是“imx6ull”这颗SOC。Linux内核会通过根节点的compoatible属性查看是否支持此设备，如果支持的话设备就会启动Linux内核。接下来我们就来学习一下Linux内核在使用设备树前后是如何判断是否支持某款设备的。
1、使用设备树之前设备匹配方法
在没有使用设备树以前，uboot会向Linux内核传递一个叫做machine id的值，machine id也就是设备ID，告诉Linux内核自己是个什么设备，看看Linux内核是否支持。Linux内核是支持很多设备的，针对每一个设备(板子)，Linux内核都用MACHINE_START和MACHINE_END来定义一个machine_desc结构体来描述这个设备，比如在文件arch/arm/mach-imx/mach-mx35_3ds.c中有如下定义： 示例代码43.3.4.2 MX35_3DS设备
613 MACHINE_START(MX35_3DS, "Freescale MX35PDK")
614 /* Maintainer: Freescale Semiconductor, Inc */
615 .atag_offset = 0x100,
616 .map_io = mx35_map_io,
617 .init_early = imx35_init_early,
618 .init_irq = mx35_init_irq,
619 .init_time = mx35pdk_timer_init,
620 .init_machine = mx35_3ds_init,
621 .reserve = mx35_3ds_reserve,
622 .restart = mxc_restart,
623 MACHINE_END
上述代码就是定义了“Freescale MX35PDK”这个设备，其中MACHINE_START和MACHINE_END定义在文件arch/arm/include/asm/mach/arch.h中，内容如下：
示例代码43.3.4.3 MACHINE_START和MACHINE_END宏定义
#define MACHINE_START(_type,_name) \
static const struct machine_desc __mach_desc_##_type \
__used \
__attribute__((__section__(".arch.info.init"))) = { \
.nr = MACH_TYPE_##_type, \
.name = _name,
#define MACHINE_END \
};
根据MACHINE_START和MACHINE_END的宏定义，将示例代码43.3.4.2展开后如下所示：
示例代码43.3.4.3 展开以后
1 static const struct machine_desc __mach_desc_MX35_3DS \
2 __used \
3 __attribute__((__section__(".arch.info.init"))) = {
4 .nr = MACH_TYPE_MX35_3DS,
5 .name = "Freescale MX35PDK",
6 /* Maintainer: Freescale Semiconductor, Inc */
7 .atag_offset = 0x100,
8 .map_io = mx35_map_io,
9 .init_early = imx35_init_early,
10 .init_irq = mx35_init_irq,
11 .init_time = mx35pdk_timer_init,
12 .init_machine = mx35_3ds_init,
13 .reserve = mx35_3ds_reserve,
14 .restart = mxc_restart,
15 };
从示例代码43.3.4.3中可以看出，这里定义了一个machine_desc类型的结构体变量__mach_desc_MX35_3DS，这个变量存储在“.arch.info.init”段中。第4行的MACH_TYPE_MX35_3DS就是“Freescale MX35PDK”这个板子的machine id。MACH_TYPE_MX35_3DS定义在文件include/generated/mach-types.h中，此文件定义了大量的machine id，内容如下所示：
示例代码43.3.4.3 mach-types.h文件中的machine id
15 #define MACH_TYPE_EBSA110 0
16 #define MACH_TYPE_RISCPC 1
17 #define MACH_TYPE_EBSA285 4
18 #define MACH_TYPE_NETWINDER 5
19 #define MACH_TYPE_CATS 6
20 #define MACH_TYPE_SHARK 15
21 #define MACH_TYPE_BRUTUS 16
22 #define MACH_TYPE_PERSONAL_SERVER 17
......
287 #define MACH_TYPE_MX35_3DS 1645
......
1000 #define MACH_TYPE_PFLA03 4575
第287行就是MACH_TYPE_MX35_3DS的值，为1645。
前面说了，uboot会给Linux内核传递machine id这个参数，Linux内核会检查这个machine id，其实就是将machine id与示例代码43.3.4.3中的这些MACH_TYPE_XXX宏进行对比，看看有没有相等的，如果相等的话就表示Linux内核支持这个设备，如果不支持的话那么这个设备就没法启动Linux内核。
2、使用设备树以后的设备匹配方法
当Linux内核引入设备树以后就不再使用MACHINE_START了，而是换为了DT_MACHINE_START。DT_MACHINE_START也定义在文件arch/arm/include/asm/mach/arch.h 里面，定义如下：
示例代码43.3.4.4 DT_MACHINE_START宏
#define DT_MACHINE_START(_name, _namestr) \
static const struct machine_desc __mach_desc_##_name \
__used \
__attribute__((__section__(".arch.info.init"))) = { \
.nr = ~0, \
.name = _namestr,
可以看出，DT_MACHINE_START和MACHINE_START基本相同，只是.nr的设置不同，在DT_MACHINE_START里面直接将.nr设置为~0。说明引入设备树以后不会再根据machine id来检查Linux内核是否支持某个设备了。
打开文件arch/arm/mach-imx/mach-imx6ul.c，有如下所示内容：
示例代码43.3.4.5 imx6ull设备
208 static const char *imx6ul_dt_compat[] __initconst = {
209 "fsl,imx6ul",
210 "fsl,imx6ull",
211 NULL,
212 };
213
214 DT_MACHINE_START(IMX6UL, "Freescale i.MX6 Ultralite (Device Tree)")
215 .map_io = imx6ul_map_io,
216 .init_irq = imx6ul_init_irq,
217 .init_machine = imx6ul_init_machine,
218 .init_late = imx6ul_init_late,
219 .dt_compat = imx6ul_dt_compat,
220 MACHINE_END
machine_desc结构体中有个.dt_compat成员变量，此成员变量保存着本设备兼容属性，示例代码43.3.4.5中设置.dt_compat = imx6ul_dt_compat，imx6ul_dt_compat表里面有"fsl,imx6ul"和"fsl,imx6ull"这两个兼容值。只要某个设备(板子)根节点“/”的compatible属性值与imx6ul_dt_compat表中的任何一个值相等，那么就表示Linux内核支持此设备。imx6ull-alientek-emmc.dts中根节点的compatible属性值如下：
compatible = “fsl,imx6ull-14x14-evk”, “fsl,imx6ull”; 其中“fsl,imx6ull”与imx6ul_dt_compat中的“fsl,imx6ull”匹配，因此I.MX6U-ALPHA开发板可以正常启动Linux内核。如果将imx6ull-alientek-emmc.dts根节点的compatible属性改为其他的值，比如： compatible = “fsl,imx6ull-14x14-evk”, “fsl,imx6ullll” 重新编译DTS，并用新的DTS启动Linux内核，结果如图43.3.4.1所示的错误提示： 
图43.3.4.1 系统启动信息 当我们修改了根节点compatible属性内容以后，因为Linux内核找不到对应的设备，因此Linux内核无法启动。在uboot输出Starting kernel…以后就再也没有其他信息输出了。 接下来我们简单看一下Linux内核是如何根据设备树根节点的compatible属性来匹配出对应的machine_desc，Linux内核调用start_kernel函数来启动内核，start_kernel函数会调用setup_arch函数来匹配machine_desc，setup_arch函数定义在文件arch/arm/kernel/setup.c中，函数内容如下(有缩减)： 示例代码43.3.4.6 setup_arch函数内容
913 void __init setup_arch(char **cmdline_p)
914 {
915 const struct machine_desc *mdesc;
916
917 setup_processor();
918 mdesc = setup_machine_fdt(__atags_pointer);
919 if (!mdesc)
920 mdesc = setup_machine_tags(__atags_pointer, __machine_arch_type);
921 machine_desc = mdesc;
922 machine_name = mdesc->name;
......
986 }
第918行，调用setup_machine_fdt函数来获取匹配的machine_desc，参数就是atags的首地址，也就是uboot传递给Linux内核的dtb文件首地址，setup_machine_fdt函数的返回值就是找到的最匹配的machine_desc。
函数setup_machine_fdt定义在文件arch/arm/kernel/devtree.c中，内容如下(有缩减)：
示例代码43.3.4.7 setup_machine_fdt函数内容
204 const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
205 {
206 const struct machine_desc *mdesc, *mdesc_best = NULL;
......
214
215 if (!dt_phys || !early_init_dt_verify(phys_to_virt(dt_phys)))
216 return NULL;
217
218 mdesc = of_flat_dt_match_machine(mdesc_best, arch_get_next_mach);
219
......
247 __machine_arch_type = mdesc->nr;
248
249 return mdesc;
250 }
第218行，调用函数of_flat_dt_match_machine来获取匹配的machine_desc，参数mdesc_best是默认的machine_desc，参数arch_get_next_mach是个函数，此函数定义在定义在arch/arm/kernel/devtree.c文件中。找到匹配的machine_desc的过程就是用设备树根节点的compatible属性值和Linux内核中machine_desc下.dt_compat的值比较，看看那个相等，如果相等的话就表示找到匹配的machine_desc，arch_get_next_mach函数的工作就是获取Linux内核中下一个machine_desc结构体。
最后再来看一下of_flat_dt_match_machine函数，此函数定义在文件drivers/of/fdt.c中，内容如下(有缩减)：
示例代码43.3.4.8 of_flat_dt_match_machine函数内容
705 const void * __init of_flat_dt_match_machine(const void *default_match,
706 const void * (*get_next_compat)(const char * const**))
707 {
708 const void *data = NULL;
709 const void *best_data = default_match;
710 const char *const *compat;
711 unsigned long dt_root;
712 unsigned int best_score = ~1, score = 0;
713
714 dt_root = of_get_flat_dt_root();
715 while ((data = get_next_compat(&compat))) {
716 score = of_flat_dt_match(dt_root, compat);
717 if (score > 0 && score
关注
打赏
![]()
1665308814
查看更多评论
最近更新
- 深拷贝和浅拷贝的区别（重点）
- 【Vue】走进Vue框架世界
- 【云服务器】项目部署—搭建网站—vue电商后台管理系统
- 【React介绍】 一文带你深入React
- 【React】React组件实例的三大属性之state，props，refs（你学废了吗）
- 【脚手架VueCLI】从零开始，创建一个VUE项目
- 【React】深入理解React组件生命周期----图文详解（含代码）
- 【React】DOM的Diffing算法是什么？以及DOM中key的作用----经典面试题
- 【React】1_使用React脚手架创建项目步骤--------详解(含项目结构说明)
- 【React】2_如何使用react脚手架写一个简单的页面？
