1）实验平台：正点原子STM32MP157开发板 2）购买链接:https://item.taobao.com/item.htm?&id=629270721801 3）全套实验源码+手册+视频下载地址：http://www.openedv.com/thread-318813-1-1.html 4）正点原子官方B站：https://space.bilibili.com/394620890 5）正点原子STM32MP157技术交流群：691905614 
在前面章节中我们多次提到“设备树”这个概念和创建自己的设备树。但是并没有在TF-A和uboot里说设备树的原理，主要是一开始就讲解设备树不利于嵌入式Linux入门，对于大多数嵌入式开发人员来说设备树是个全新的概念。 本章我们就来详细的谈一谈设备树。掌握设备树是Linux驱动开发人员必备的技能！因为在新版本的Linux中，ARM相关的驱动全部采用了设备树(也有支持老式驱动的，比较少)，最新出CPU在系统启动的时候就支持设备树，比如我们的MP1系列、NXP的I.MX8系列等。我们所使用的Linux版本为5.4.31，其支持设备树，所以正点原子MP1开发板的所有Linux驱动都是基于设备树的。本章我们就来了解一下设备树的起源、重点学习一下设备树语法。
23.1 什么是设备树？ 设备树(Device Tree)，将这个词分开就是“设备”和“树”，描述设备树的文件叫做DTS(Device Tree Source)，这个DTS文件采用树形结构描述板级设备，也就是开发板上的设备信息，比如CPU数量、 内存基地址、IIC接口上接了哪些设备、SPI接口上接了哪些设备等等，如图23.1.1所示： 
图23.1.1 设备树结构示意图 在图23.1.1中，树的主干就是系统总线，IIC控制器、GPIO控制器、SPI控制器等都是接到系统主线上的分支。IIC控制器有分为IIC1和IIC2两种，其中IIC1上接了FT5206和AT24C02这两个IIC设备，IIC2上只接了MPU6050这个设备。DTS文件的主要功能就是按照图23.1.1所示的结构来描述板子上的设备信息，DTS文件描述设备信息是有相应的语法规则要求的，稍后我们会详细的讲解DTS语法规则。 在3.x版本(具体哪个版本笔者也无从考证)以前的Linux内核中ARM架构并没有采用设备树。在没有设备树的时候Linux是如何描述ARM架构中的板级信息呢？在Linux内核源码中大量的arch/arm/mach-xxx和arch/arm/plat-xxx文件夹，这些文件夹里面的文件就是对应平台下的板级信息。比如在arch/arm/mach-s3c24xx/mach-smdk2440.c中有如下内容(有缩减)：
示例代码23.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多块钱到一家宣传看着很不错的自助餐厅，结果你想吃的牛排、海鲜、烤肉基本没多少，全都是一些凉菜、炒面、西瓜、饮料等小吃，相信你此时肯定会脱口而出一句“Fk!”、“骗子！”。同样的，当Linux之父linus看到ARM社区向Linux内核添加了大量“无用”、冗余的板级信息文件，不禁的发出了一句“This whole ARM thing is a fcking 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社区引入了设备树。 23.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文件内容如下：
示例代码23.2.1 scripts/dtc/Makefile文件代码段
4 hostprogs-$(CONFIG_DTC) := dtc
5 always := $(hostprogs-y)
6
7 dtc-objs := dtc.o flattree.o fstree.o data.o livetree.o treesource.o
8 srcpos.o checks.o util.o
9 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源码中的所有东西，包括uImage，.ko驱动模块以及设备树，如果只是编译设备树的话建议使用“make dtbs”命令，“make dtbs”会编译选中的所有设备树文件。如果只要编译指定的某个设备树，比如ST官方编写的“stm32mp157d-ed1.dts”，可以输入如下命令： make stm32mp157d-ed1.dtb 结果如图23.2.1所示： 
图23.2.1 编译单独的设备树 基于ARM架构的SOC有很多种，一种SOC又可以制作出很多款板子，每个板子都有一个对应的DTS文件，那么如何确定编译哪一个DTS文件呢？我们就以STM32MP1这款芯片对应的板子为例来看一下，打开arch/arm/boot/dts/Makefile，有如下内容：
示例代码23.2.2 arch/arm/boot/dts/Makefile文件代码段
981 dtb-$(CONFIG_ARCH_STM32) += \
982 stm32f429-disco.dtb \
983 stm32f469-disco.dtb \
984 stm32f746-disco.dtb \
985 stm32f769-disco.dtb \
986 stm32429i-eval.dtb \
987 stm32746g-eval.dtb \
988 stm32h743i-eval.dtb \
989 stm32h743i-disco.dtb \
990 stm32mp157a-avenger96.dtb \
991 stm32mp157a-dk1.dtb \
992 stm32mp157d-dk1.dtb \
993 stm32mp157c-dk2.dtb \
994 stm32mp157f-dk2.dtb \
995 stm32mp157c-dk2-a7-examples.dtb \
996 stm32mp157c-dk2-m4-examples.dtb \
997 stm32mp157f-dk2-a7-examples.dtb \
998 stm32mp157f-dk2-m4-examples.dtb \
999 stm32mp157a-ed1.dtb \
1000 stm32mp157c-ed1.dtb \
1001 stm32mp157d-ed1.dtb \
1002 stm32mp157f-ed1.dtb \
1003 stm32mp157a-ev1.dtb \
1004 stm32mp157c-ev1.dtb \
1005 stm32mp157d-ev1.dtb \
1006 stm32mp157f-ev1.dtb \
1007 stm32mp157d-atk.dtb \
1008 stm32mp157c-ev1-a7-examples.dtb \
1009 stm32mp157c-ev1-m4-examples.dtb \
1010 stm32mp157f-ev1-a7-examples.dtb \
1011 stm32mp157f-ev1-m4-examples.dtb
可以看出，当选中STM32MP1这个SOC以后(CONFIG_ARCH_STM32=y)，所有使用到STM32MP1这个SOC的板子对应的.dts文件都会被编译为.dtb。如果我们使用STM32MP1新做了一个板子，只需要新建一个此板子对应的.dts文件，然后将对应的.dtb文件名添加到dtb-$( CONFIG_ARCH_STM32)下，这样在编译设备树的时候就会将对应的.dts编译为二进制的.dtb文件。 示例代码23.2.2中1007行就是我们在给正点原子的开发板移植Linux系统的时候添加的设备树。关于.dtb文件怎么使用这里就不多说了，前面讲解TF-A移植、Uboot移植、Linux内核移植的时候已经无数次的提到如何使用.dtb文件了(uboot中使用bootz或bootm命令向Linux内核传递二进制设备树文件(.dtb))。 23.3 DTS语法 虽然我们基本上不会从头到尾重写一个.dts文件，大多时候是直接在SOC厂商提供的.dts文件上进行修改。但是DTS文件语法我们还是需要详细的学习一遍，因为后续工作中肯定需要修改.dts文件。大家不要看到要学习新的语法就觉得会很复杂，DTS语法非常的人性化，是一种ASCII文本文件，不管是阅读还是修改都很方便。 本节我们就以stm32mp157d-atk.dts这个文件为例来讲解一下DTS语法。关于设备树详细的语法规则请参考《Devicetree SpecificationV0.2.pdf》和《Power_ePAPR_APPROVED_v1.12.pdf》这两份文档，此两份文档已经放到了开发板光盘中，路径为：4、参考资料->Devicetree SpecificationV0.2.pdf，4、参考资料-> Power_ePAPR_APPROVED_v1.12.pdf 23.3.1 .dtsi头文件 和C语言一样，设备树也支持头文件，设备树的头文件扩展名为.dtsi。在stm32mp157d-atk.dts中有如下所示内容：
示例代码23.3.1.1 stm32mp157d-atk.dts文件代码段
8 #include "stm32mp157.dtsi"
9 #include "stm32mp15xd.dtsi"
10 #include "stm32mp15-pinctrl.dtsi"
11 #include "stm32mp15xxaa-pinctrl.dtsi"
12 #include "stm32mp157-m4-srm.dtsi"
13 #include "stm32mp157-m4-srm-pinctrl.dtsi"
14 #include "stm32mp157d-atk.dtsi"
第8~17行，使用“#include”来引用“stm32mp15*.dtsi”这些.dtsi头文件。
设备树里面除了可以通过“#include”来引用.dtsi文件，也可以引用.h文件头文件，大家打开stm32mp157f-dk2.dts这个文件，找到如下代码：
示例代码23.3.1.2 stm32mp157f-dk2.dts文件代码段 14 #include .dts文件不仅可以应用C语言里面的.h头文件，甚至也可以引用.dts文件，打开stm32mp157c-ev1.dts这个文件，此文件中有如下内容： 示例代码23.3.1.3 stm32mp157c-ev1.dts文件代码段 8 #include “stm32mp157c-ed1.dts” 可以看出，示例代码23.3.1.3中直接引用了.dts文件，因此在.dts设备树文件中，可以通过“#include”来引用.h、.dtsi和.dts文件。只是，我们在编写设备树头文件的时候最好选择.dtsi后缀。 一般.dtsi文件用于描述SOC的内部外设信息，比如CPU架构、主频、外设寄存器地址范围，比如UART、IIC等等。如果一个系列里有多个SOC就会把相同内部外设信息提炼到一个.dtsi文件里，这样为了减少代码的冗余。目前STM32MP1系列里有stm32mp151、stm32mp153和stm32mp157这三款SOC，其中151是外设最少的，153和157的外设是在151的基础上逐渐增加的。因此151就相当于“基类”，153和157是在151基础上得到的“派生类”。因此ST就把最基本的外设资源都写在stm32mp151.dtsi文件里。stm32mp151.dtsi就是描述151、153和157共有的外设信息的，内容如下：
示例代码23.3.1.4 stm32mp151.dtsi文件代码段
6 #include
7 #include
8 #include
9 #include
10 #include
11
12
13 / {
14 #address-cells = ;
15 #size-cells = ;
16
17 cpus {
18 #address-cells = ;
19 #size-cells = ;
20
21 cpu0: cpu@0 {
22 compatible = "arm,cortex-a7";
......
29 nvmem-cell-names = "part_number";
30 #cooling-cells = ;
31 };
32 };
33
34 cpu0_opp_table: cpu0-opp-table {
35 compatible = "operating-points-v2";
36 opp-shared;
37 };
38 };
......
469 spi2: spi@4000b000 {
470 #address-cells = ;
471 #size-cells = ;
472 compatible = "st,stm32h7-spi";
473 reg = ;
474 interrupts = ;
475 clocks = ;
476 resets = ;
477 dmas = ,
478 ;
479 dma-names = "rx", "tx";
480 power-domains = ;
481 status = "disabled";
482 };
示例代码23.3.1.4中第1733行就是CPU0这个设备节点信息，这个节点信息描述了STM32MP151这颗SOC所使用的CPU信息，比如架构是cortex-A7,CPU的时钟等等,stm32mp151.dtsi文件中不仅仅描述了CPU0这个节点信息，STM32MP151这颗SOC所有的外设都描述的清清楚楚，比如SAI14, U(S)ART18，SDIO13等等，关于这些设备节点信息的具体内容我们后面具体章节里面再详细的讲解。 23.3.2 设备节点 设备树是采用树形结构来描述板子上的设备信息的文件，每个设备都是一个节点，叫做设备节点，每个节点都通过一些属性信息来描述节点信息，属性就是键—值对。以下文件是结合ST官方的设备树缩减出来设备树文件内容：
示例代码23.3.2.1 设备树模板
1 / {
2 #address-cells = ;
3 #size-cells = ;
4
5 aliases {
6 serial0 = &uart4;
7 };
8
9 cpus {
10 #address-cells = ;
11 #size-cells = ;
12
13 cpu0: cpu@0 {
14 compatible = "arm,cortex-a7";
15 device_type = "cpu";
16 reg = ;
17 clocks = ;
18 clock-names = "cpu";
19 operating-points-v2 = ;
20 nvmem-cells = ;
21 nvmem-cell-names = "part_number";
22 #cooling-cells = ;
23 };
24 };
25
26 soc {
27 compatible = "simple-bus";
28 #address-cells = ;
29 #size-cells = ;
30 interrupt-parent = ;
31 ranges;
32
33 sram: sram@10000000 {
34 compatible = "mmio-sram";
35 reg = ;
36 #address-cells = ;
37 #size-cells = ;
38 ranges = ;
39 };
40 };
41 };
第1行，“/”是根节点，每个设备树文件只有一个根节点。细心的同学应该会发现，在内核移植设备树的时候，我们新建的stm32mp157d-atk.dts和stm32mp157d-atk.dtsi这两个文件都有一个“/”根节点，这样不会出错吗？不会的，因为这两个“/”根节点的内容会合并成一个根节点。 第5、9和26行，aliases、cpus和soc是三个子节点，33行sram是soc的子节点。在设备树中节点命名格式如下： node-name@unit-address 其中“node-name”是节点名字，为ASCII字符串，节点名字应该能够清晰的描述出节点的功能，比如“uart1”就表示这个节点是UART1外设。“unit-address”一般表示设备的地址或寄存器首地址，如果某个节点没有地址或者寄存器的话“unit-address”可以不要，比如“cpu@0”、“sram@10000000”、“soc”。 但是我们在示例代码23.3.2.1中我们看到的节点命名却如下所示： cpu0:cpu@0 上述命令并不是“node-name@unit-address”这样的格式，而是用“：”隔开成了两部分，“：”前面是节点标签(label)，“：”后面的才是节点名字，格式如下所示： label: node-name@unit-address 引入label的目的就是为了方便访问节点，可以直接通过&label来访问这个节点，比如通过&cpu0就可以访问“cpu@0”这个节点，而不需要输入完整的节点名字。再比如节点 “sram: sram@10000000”，节点label是sram，而节点名字就很长了，为“sram@10000000”。很明显通过&sram来访问“sram@10000000”这个节点要方便很多！ 第13行，cpu0也是一个节点，只是cpu0是cpus的子节点。 每个节点都有不同属性，不同的属性又有不同的内容，属性都是键值对，值可以为空或任意的字节流。设备树源码中常用的几种数据形式如下所示： 1、字符串 compatible = “arm,cortex-a7”; 上述代码设置compatible属性的值为字符串“arm,cortex-a7”。 2、32位无符号整数 reg = ; 上述代码设置reg属性的值为0，reg的值也可以设置为一组值，比如： reg = ; 3、字符串列表 属性值也可以为字符串列表，字符串和字符串之间采用“,”隔开，如下所示： compatible = “st,stm32mp157d-atk”, “st,stm32mp157”; 上述代码设置属性compatible的值为“st,stm32mp157d-atk”和“st,stm32mp157”。 23.3.3 标准属性 节点是由一堆的属性组成，节点都是具体的设备，不同的设备需要的属性不同，用户可以自定义属性。除了用户自定义属性，有很多属性是标准属性，Linux下的很多外设驱动都会使用这些标准属性，本节我们就来学习一下几个常用的标准属性。 1、compatible属性 compatible属性也叫做“兼容性”属性，这是非常重要的一个属性！compatible属性的值是一个字符串列表，compatible属性用于将设备和驱动绑定起来。字符串列表用于选择设备所要使用的驱动程序，compatible属性的值格式如下所示： “manufacturer,model” 其中manufacturer表示厂商，model一般是模块对应的驱动名字。比如stm32mp15xx-dkx.dtsi中有一个音频设备节点，这个节点的音频芯片采用的Cirrus Logic公司出品的cs42l51，compatible属性值如下： compatible = “cirrus,cs42l51”; 属性值为“cirrus,cs42l51”，其中‘cirrus’表示厂商是Cirrus Logic，“cs42l51”表示驱动模块名字。compatible也可以多个属性值。比如： compatible = “cirrus,my_cs42l51”,“cirrus,cs42l51”; 这样我们的设备就有两个属性值，这个设备首先使用第一个兼容值在Linux内核里面查找，看看能不能找到与之匹配的驱动文件，如果没有找到的话就使用第二个兼容值查，以此类推，直到查找完compatible属性中的所有值。 一般驱动程序文件都会有一个OF匹配表，此OF匹配表保存着一些compatible值，如果设备节点的compatible属性值和OF匹配表中的任何一个值相等，那么就表示设备可以使用这个驱动。比如在文件cs42l51.c中有如下内容：
示例代码23.3.3.1 cs42l51.c 文件代码段
799 const struct of_device_id cs42l51_of_match[] = {
800 { .compatible = "cirrus,cs42l51", },
801 { }
802 };
数组cs42l51_of_match就是cs42l51.c这个驱动文件的匹配表，此匹配表只有一个匹配值“cirrus,cs42l51”。如果在设备树中有哪个节点的compatible属性值与此相等，那么这个节点就会使用此驱动文件。
2、model属性 model属性值也是一个字符串，一般model属性描述开发板的名字或者设备模块信息，比如名字什么的，比如： model = “STMicroelectronics STM32MP157C-DK2 Discovery Board”; 3、status属性 status属性看名字就知道是和设备状态有关的，status属性值也是字符串，字符串是设备的状态信息，可选的状态如表23.3.3.1所示： 值 描述 “okay” 表明设备是可操作的。 “disabled” 表明设备当前是不可操作的，但是在未来可以变为可操作的，比如热插拔设备插入以后。至于disabled的具体含义还要看设备的绑定文档。 “fail” 表明设备不可操作，设备检测到了一系列的错误，而且设备也不大可能变得可操作。 “fail-sss” 含义和“fail”相同，后面的sss部分是检测到的错误内容。 表23.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这个数据所占用的字长，比如:
示例代码23.3.3.2 #address-cells和#size-cells属性
1 cpus {
2 #address-cells = ;
3 #size-cells = ;
4
5 cpu0: cpu@0 {
6 compatible = "arm,cortex-a7";
7 device_type = "cpu";
8 reg = ;
9 clocks = ;
10 clock-names = "cpu";
11 operating-points-v2 = ;
12 nvmem-cells = ;
13 nvmem-cell-names = "part_number";
14 #cooling-cells = ;
15 };
16 };
17
18 scmi_sram: sram@2ffff000 {
19 compatible = "mmio-sram";
20 reg = ;
21 #address-cells = ;
22 #size-cells = ;
23 ranges = ;
24
25 scmi0_shm: scmi_shm@0 {
26 reg = ;
27 };
28 };
第2，3行，节点cpus的#address-cells = ，#size-cells = ，说明cpus的子节点reg属性中起始地址所占用的字长为1，地址长度所占用的字长为0。 第8行，子节点cpu0: cpu@0的reg 属性值为 ，因为父节点设置了#address-cells = ，#size-cells = ，因此addres=0，没有length的值，相当于设置了起始地址，而没有设置地址长度。 第21，22行，设置scmi_sram: sram@02ffff000节点#address-cells = ，#size-cells = ，说明scmi_sram: sram@02ffff000节点起始地址长度所占用的字长为1，地址长度所占用的字长也为1。 第26行，子节点scmi0_shm: scmi_shm@0的reg属性值为，因为父节点设置了#address-cells = ，#size-cells = ，address= 0x0，length= 0x80，相当于设置了起始地址为0x0，地址长度为0x80。 5、reg属性 reg属性前面已经提到过了，reg属性的值一般是(address，length)对。reg属性一般用于描述设备地址空间资源信息或者设备地址信息，比如某个外设的寄存器地址范围信息，或者IIC器件的设备地址等，比如在stm32mp151.dtsi中有如下内容：
示例代码23.3.3.3 uart5节点信息
576 uart5: serial@40011000 {
577 compatible = "st,stm32h7-uart";
578 reg = ;
579 interrupts-extended = ;
580 clocks = ;
581 resets = ;
582 wakeup-source;
583 power-domains = ;
584 dmas = ,
585 ;
586 dma-names = "rx", "tx";
587 status = "disabled";
588 };
uart5节点描述了stm32mp1系列芯片的UART5相关信息，重点是第578行的reg属性。由于uart5的父节点“soc”设置了#address-cells = 、#size-cells = ，因此reg属性中address=0x40011000，length=0x400。查阅《STM32MP157参考手册》可知，stm32mp157芯片的UART5寄存器首地址为0x40011000，但是UART5的地址长度(范围)并没有0x400这么多，这里我们重点是获取UART5寄存器首地址。 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属性值为空值，说明子地址空间和父地址空间完全相同，不需要进行地址转换，对于我们所使用的stm32mp157来说，子地址空间和父地址空间完全相同，因此会在stm32mp151.dtsi中找到大量的值为空的ranges属性，如下所示：
示例代码23.3.3.4 stm32mp151.dtsi文件代码段
192 soc {
193 compatible = "simple-bus";
194 #address-cells = ;
195 #size-cells = ;
196 interrupt-parent = ;
197 ranges;
......
1968 };
第197行定义了ranges属性，但是ranges属性值为空。 ranges属性不为空的示例代码如下所示：
示例代码23.3.3.5 ranges属性不为空
1 soc {
2 compatible = "simple-bus";
3 #address-cells = ;
4 #size-cells = ;
5 interrupt-parent = ;
6 ranges = ;
7
8 sram: sram@10000000 {
9 compatible = "mmio-sram";
10 reg = ;
11 #address-cells = ;
12 #size-cells = ;
13 ranges = ;
14 };
15 };
第6行，节点soc定义的ranges属性，值为，此属性值指定了一个1024KB(0x100000)的地址范围，子地址空间的物理起始地址为0，父地址空间的物理起始地址为0x10000000。 第8行，sram是STM32MP1内部RAM节点，reg属性定义了sram设备寄存器的起始地址为0，寄存器长度为0x60000。经过地址转换，sram设备可以从0x10000000开始进行读写操作，0x10000000=0x0 + 0x10000000。 7、name属性 name属性值为字符串，name属性用于记录节点名字，name属性已经被弃用，不推荐使用name属性，一些老的设备树文件可能会使用此属性。 8、device_type属性 device_type属性值为字符串，IEEE 1275会用到此属性，用于描述设备的FCode，但是设备树没有FCode，所以此属性也被抛弃了。此属性只能用于cpu节点或者memory节点。Stm32mp151.dtsi的cpu0节点用到了此属性，内容如下所示：
示例代码23.3.3.6 stm32mp151.dtsi文件代码段
21 cpu0: cpu@0 {
22 compatible = "arm,cortex-a7";
23 device_type = "cpu";
......
32 };
关于标准属性就讲解这么多，其他的比如中断、IIC、SPI等使用的标准属性等到具体的例程再讲解。 23.3.4 根节点compatible属性 每个节点都有compatible属性，根节点“/”也不例外，在我们新建的stm32mp157d-atk.dts文件中根节点的compatible属性内容如下所示：
示例代码23.3.4.1 stm32mp157d-atk.dts根节点compatible属性
16 / {
17 model = "STMicroelectronics STM32MP157C-DK2 Discovery Board";
18 compatible = "st,stm32mp157d-atk", "st,stm32mp157";
......
41 };
可以看出，compatible有两个值：“st,stm32mp157d-atk”和“st,stm32mp157”。前面我们说了，设备节点的compatible属性值是为了匹配Linux内核中的驱动程序，那么根节点中的compatible属性是为了做什么工作的？ 通过根节点的compatible属性可以知道我们所使用的设备，一般第一个值描述了所使用的硬件设备名字，比如这里使用的是“stm32mp157d-atk”这个设备，第二个值描述了设备所使用的SOC，比如这里使用的是“stm32mp157”这颗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中有如下定义：
示例代码23.3.4.2 MX35_3DS设备
506 MACHINE_START(MX35_3DS, "Freescale MX35PDK")
507 /* Maintainer: Freescale Semiconductor, Inc */
508 .atag_offset = 0x100,
509 .map_io = mx35_map_io,
510 .init_early = imx35_init_early,
511 .init_irq = mx35_init_irq,
512 .init_time = mx35pdk_timer_init,
513 .init_machine = mx35_3ds_init,
514 .reserve = mx35_3ds_reserve,
515 .restart = mxc_restart,
516 MACHINE_END
上述代码就是定义了“Freescale MX35PDK”这个设备，其中MACHINE_START和MACHINE_END定义在文件arch/arm/include/asm/mach/arch.h中，内容如下：
示例代码23.3.4.3 MACHINE_START和MACHINE_END宏定义
81 #define MACHINE_START(_type,_name) \
82 static const struct machine_desc __mach_desc_##_type \
83 __used \
84 __attribute__((__section__(".arch.info.init"))) = { \
85 .nr = MACH_TYPE_##_type, \
86 .name = _name,
87
88 #define MACHINE_END \
89
根据MACHINE_START和MACHINE_END的宏定义，将示例代码23.3.4.2展开后如下所示：
示例代码23.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 };
从示例代码23.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，内容如下所示：
示例代码23.3.4.3 mach-types.h文件中的machine id
10 #define MACH_TYPE_EBSA110 0
11 #define MACH_TYPE_RISCPC 1
12 #define MACH_TYPE_NEXUSPCI 3
......
1629 #define MACH_TYPE_MX35_3DS 1645
......
5053 #define MACH_TYPE_OMAP3_MRC3D 5114
第1629行就是MACH_TYPE_MX35_3DS的值，为1645。
前面说了，uboot会给Linux内核传递machine id这个参数，Linux内核会检查这个machine id，其实就是将machine id与示例代码23.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 里面，定义如下：
示例代码23.3.4.4 DT_MACHINE_START宏
91 #define DT_MACHINE_START(_name, _namestr) \
92 static const struct machine_desc __mach_desc_##_name \
93 __used \
94 __attribute__((__section__(".arch.info.init"))) = { \
95 .nr = ~0, \
96 .name = _namestr,
97
98 #endif
可以看出，DT_MACHINE_START和MACHINE_START基本相同，只是.nr的设置不同，在DT_MACHINE_START里面直接将.nr设置为~0。说明引入设备树以后不会再根据machine id来检查Linux内核是否支持某个设备了。 打开文件arch/arm/mach-stm32/board-dt.c，有如下所示内容：
示例代码23.3.4.5 stm32mp157设备
14 static const char *const stm32_compat[] __initconst = {
15 "st,stm32f429",
16 "st,stm32f469",
17 "st,stm32f746",
18 "st,stm32f769",
19 "st,stm32h743",
20 "st,stm32mp151",
21 "st,stm32mp153",
22 "st,stm32mp157",
23 NULL
24 };
25
26 DT_MACHINE_START(STM32DT, "STM32 (Device Tree Support)")
27 .dt_compat = stm32_compat,
28 #ifdef CONFIG_ARM_SINGLE_ARMV7M
29 .restart = armv7m_restart,
30 #endif
31 MACHINE_END
machine_desc结构体中有个.dt_compat成员变量，此成员变量保存着本设备兼容属性，示例代码23.3.4.5中设置.dt_compat为stm32_compat，此表里面含有Linux内核所支持的soc兼容值。只要某个设备(板子)根节点“/”的compatible属性值与stm32_compat表中的任何一个值相等，那么就表示Linux内核支持此设备。stm32mp157d-atk.dts中根节点的compatible属性值如下： compatible = “st,stm32mp157d-atk”, “st,stm32mp157”; 其中“st,stm32mp157”与stm32_compat中的“st,stm32mp157”匹配，因此正点原子STM32MP157开发板可以正常启动Linux内核。 接下来我们简单看一下Linux内核是如何根据设备树根节点的compatible属性来匹配出对应的machine_desc，Linux内核调用start_kernel函数来启动内核，start_kernel函数会调用setup_arch函数来匹配machine_desc，setup_arch函数定义在文件arch/arm/kernel/setup.c中，函数内容如下(有缩减)：
示例代码23.3.4.6 setup_arch函数内容
1076 void __init setup_arch(char **cmdline_p)
1077 {
1078 const struct machine_desc *mdesc;
1079
1080 setup_processor();
1081 mdesc = setup_machine_fdt(__atags_pointer);
1082 if (!mdesc)
1083 mdesc = setup_machine_tags(__atags_pointer,
__machine_arch_type);
......
1094 machine_desc = mdesc;
1095 machine_name = mdesc->name;
......
1174 }
第1081行，调用setup_machine_fdt函数来获取匹配的machine_desc，参数就是atags的首地址，也就是uboot传递给Linux内核的dtb文件首地址，setup_machine_fdt函数的返回值就是找到的最匹配的machine_desc。 函数setup_machine_fdt定义在文件arch/arm/kernel/devtree.c中，内容如下(有缩减)：
示例代码23.3.4.7 setup_machine_fdt函数内容
211 const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
212 {
213 const struct machine_desc *mdesc, *mdesc_best = NULL;
......
224 if (!dt_phys || !early_init_dt_verify(phys_to_virt(dt_phys)))
225 return NULL;
226
227 mdesc = of_flat_dt_match_machine(mdesc_best,
arch_get_next_mach);
......
256 __machine_arch_type = mdesc->nr;
257
258 return mdesc;
259 }
第227行，调用函数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中，内容如下(有缩减)：
示例代码23.3.4.8 of_flat_dt_match_machine函数内容
815 const void * __init of_flat_dt_match_machine(const void *default_match,
816 const void * (*get_next_compat)(const char * const**))
817 {
818 const void *data = NULL;
819 const void *best_data = default_match;
820 const char *const *compat;
821 unsigned long dt_root;
822 unsigned int best_score = ~1, score = 0;
823
824 dt_root = of_get_flat_dt_root();
825 while ((data = get_next_compat(&compat))) {
826 score = of_flat_dt_match(dt_root, compat);
827 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脚手架写一个简单的页面？
