本帖最后由 正点原子 于 2020-10-24 16:16 编辑
1）实验平台：正点原子阿尔法Linux开发板
2）平台购买地址：https://item.taobao.com/item.htm?id=603672744434
3）全套实验源码+手册+视频下载地址：http://www.openedv.com/thread-300792-1-1.html
4）对正点原子Linux感兴趣的同学可以加群讨论：876919289
5）关注正点原子公众号，获取最新资料
第四十三章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文件代码段
- 90staticstruct 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
- 115staticstruct s3c2410fb_mach_info smdk2440_fb_info __initdata ={
- 116.displays =&smdk2440_lcd_cfg,
- 117.num_displays =1,
- 118.default_display =0,
- ......
- 133};
- 134
- 135staticstruct 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源码根目录下，然后执行如下命令：
makeall
或者：
makedtbs
“makeall”命令是编译Linux源码中的所有东西，包括zImage，.ko驱动模块以及设备树，如果只是编译设备树的话建议使用“makedtbs”命令。
基于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 <dt-bindings/input/input.h>
- 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 <dt-bindings/clock/imx6ul-clock.h>
- 11 #include <dt-bindings/gpio/gpio.h>
- 12 #include <dt-bindings/interrupt-controller/arm-gic.h>
- 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 =<1>;
- 52 #size-cells =<0>;
- 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 =<3>;
- 95 interrupt-controller;
- 96 reg =<0x00a010000x1000>,
- 97<0x00a020000x100>;
- 98};
- 99
- 100 clocks {
- 101 #address-cells =<1>;
- 102 #size-cells =<0>;
- 103
- 104 ckil: clock@0 {
- 105 compatible ="fixed-clock";
- 106 reg =<0>;
- 107 #clock-cells =<0>;
- 108 clock-frequency =<32768>;
- 109 clock-output-names ="ckil";
- 110};
- ......
- 135};
- 136
- 137 soc {
- 138 #address-cells =<1>;
- 139 #size-cells =<1>;
- 140 compatible ="simple-bus";
- 141 interrupt-parent =<&gpc>;
- 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 =<1>;
- 201 #size-cells =<1>;
- 202 reg =<0x018060000x2000>,<0x018080000x4000>;
- ......
- 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 =<1>;
- 8 #size-cells =<0>;
- 9
- 10 cpu0: cpu@0 {
- 11 compatible ="arm,cortex-a7";
- 12 device_type ="cpu";
- 13 reg =<0>;
- 14 };
- 15 };
- 16
- 17 intc: interrupt-controller@00a01000 {
- 18 compatible ="arm,cortex-a7-gic";
- 19 #interrupt-cells =<3>;
- 20 interrupt-controller;
- 21 reg =<0x00a010000x1000>,
- 22 <0x00a020000x100>;
- 23 };
- 24}
第1行，“/”是根节点，每个设备树文件只有一个根节点。细心的同学应该会发现，imx6ull.dtsi和imx6ull-alientek-emmc.dts这两个文件都有一个“/”根节点，这样不会出错吗？不会的，因为这两个“/”根节点的内容会合并成一个根节点。
第2、6和17行，aliases、cpus和intc是三个子节点，在设备树中节点命名格式如下：
其中“node-name”是节点名字，为ASCII字符串，节点名字应该能够清晰的描述出节点的功能，比如“uart1”就表示这个节点是UART1外设。“unit-address”一般表示设备的地址或寄存器首地址，如果某个节点没有地址或者寄存器的话“unit-address”可以不要，比如“cpu@0”、“interrupt-controller@00a01000”。
但是我们在示例代码43.3.2.1中我们看到的节点命名却如下所示：
上述命令并不是“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”。
上述代码设置reg属性的值为0，reg的值也可以设置为一组值，比如：
- reg = <0 0x123456 100>;
- ③、字符串列表
属性值也可以为字符串列表，字符串和字符串之间采用“,”隔开，如下所示：
- 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一般是模块对应的驱动名字。比如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内核里面查找，看看能不能找到与之匹配的驱动文件，如果没有找到的话就使用第二个兼容值查找，直到找到或者查找完整个Linux内核也没有找到对应的驱动。
一般驱动程序文件都会有一个OF匹配表，此OF匹配表保存着一些compatible值，如果设备节点的compatible属性值和OF匹配表中的任何一个值相等，那么就表示设备可以使用这个驱动。比如在文件imx-wm8960.c中有如下内容：
示例代码43.3.3.1 imx-wm8960.c文件代码段
- 632staticconststruct 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
- 638staticstruct 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属性描述设备模块信息，比如名字什么的，比如：
3、status属性
status属性看名字就知道是和设备状态有关的，status属性值也是字符串，字符串是设备的状态信息，可选的状态如表43.3.3.1所示：
表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 = <address1 length1 address2 length2 address3 length3……>
每个“addresslength”组合表示一个地址范围，其中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 =<1>;
- 4 #size-cells =<0>;
- 5
- 6 gpio_spi: gpio_spi@0 {
- 7 compatible ="fairchild,74hc595";
- 8 reg =<0>;
- 9 };
- 10};
- 11
- 12 aips3: aips-bus@02200000 {
- 13 compatible ="fsl,aips-bus","simple-bus";
- 14 #address-cells =<1>;
- 15 #size-cells =<1>;
- 16
- 17 dcp: dcp@02280000 {
- 18 compatible ="fsl,imx6sl-dcp";
- 19 reg =<0x022800000x4000>;
- 20 };
- 21};
第2，3行，节点spi4的#address-cells = <1>，#size-cells = <0>，说明spi4的子节点reg属性中起始地址所占用的字长为1，地址长度所占用的字长为0。
第8行，子节点gpio_spi: gpio_spi@0的reg 属性值为<0>，因为父节点设置了#address-cells = <1>，#size-cells = <0>，因此addres=0，没有length的值，相当于设置了起始地址，而没有设置地址长度。
第14，15行，设置aips3: aips-bus@02200000节点#address-cells = <1>，#size-cells = <1>，说明aips3: aips-bus@02200000节点起始地址长度所占用的字长为1，地址长度所占用的字长也为1。
第19行，子节点dcp: dcp@02280000的reg属性值为<0x02280000 0x4000>，因为父节点设置了#address-cells = <1>，#size-cells = <1>，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 =<0x020200000x4000>;
- 327 interrupts =<GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
- 328 clocks =<&clks IMX6UL_CLK_UART1_IPG>,
- 329<&clks IMX6UL_CLK_UART1_SERIAL>;
- 330 clock-names ="ipg","per";
- 331 status ="disabled";
- 332};
上述代码是节点uart1，uart1节点描述了I.MX6ULL的UART1相关信息，重点是第326行的reg属性。其中uart1的父节点aips1: aips-bus@02000000设置了#address-cells = <1>、#size-cells = <1>，因此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 =<1>;
- 139 #size-cells =<1>;
- 140 compatible ="simple-bus";
- 141 interrupt-parent =<&gpc>;
- 142 ranges;
- ......
- 1177}
第142行定义了ranges属性，但是ranges属性值为空。
ranges属性不为空的示例代码如下所示：
示例代码43.3.3.5 ranges属性不为空
- 1 soc {
- 2 compatible ="simple-bus";
- 3 #address-cells =<1>;
- 4 #size-cells =<1>;
- 5 ranges =<0x00xe00000000x00100000>;
- 6
- 7 serial {
- 8 device_type ="serial";
- 9 compatible ="ns16550";
- 10 reg =<0x46000x100>;
- 11 clock-frequency =<0>;
- 12 interrupts =<0xA0x8>;
- 13 interrupt-parent =<&ipic>;
- 14 };
- 15};
第5行，节点soc定义的ranges属性，值为<0x0 0xe0000000 0x00100000>，此属性值指定了一个1024KB(0x00100000)的地址范围，子地址空间的物理起始地址为0x0，父地址空间的物理起始地址为0xe0000000。
第6行，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 =<0>;
- ......
- 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 展开以后
- 1staticconststruct 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”这个板子的machineid。MACH_TYPE_MX35_3DS定义在文件include/generated/mach-types.h中，此文件定义了大量的machineid，内容如下所示：
示例代码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内核传递machineid这个参数，Linux内核会检查这个machineid，其实就是将machineid与示例代码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。说明引入设备树以后不会再根据machineid来检查Linux内核是否支持某个设备了。
打开文件arch/arm/mach-imx/mach-imx6ul.c，有如下所示内容：
示例代码43.3.4.5 imx6ull设备
- 208staticconstchar*imx6ul_dt_compat[] __initconst ={
- 209"fsl,imx6ul",
- 210"fsl,imx6ull",
- 211NULL,
- 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输出Startingkernel…以后就再也没有其他信息输出了。
接下来我们简单看一下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函数内容
- 913void __init setup_arch(char**cmdline_p)
- 914{
- 915conststruct machine_desc *mdesc;
- 916
- 917 setup_processor();
- 918 mdesc = setup_machine_fdt(__atags_pointer);
- 919if(!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函数内容
- 204conststruct machine_desc * __init setup_machine_fdt(unsignedint dt_phys)
- 205{
- 206conststruct machine_desc *mdesc,*mdesc_best =NULL;
- ......
- 214
- 215if(!dt_phys ||!early_init_dt_verify(phys_to_virt(dt_phys)))
- 216returnNULL;
- 217
- 218 mdesc = of_flat_dt_match_machine(mdesc_best, arch_get_next_mach);
- 219
- ......
- 247 __machine_arch_type = mdesc->nr;
- 248
- 249return 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函数内容
- 705constvoid* __init of_flat_dt_match_machine(constvoid*default_match,
- 706constvoid*(*get_next_compat)(constchar*const**))
- 707{
- 708constvoid*data =NULL;
- 709constvoid*best_data = default_match;
- 710constchar*const*compat;
- 711unsignedlong dt_root;
- 712unsignedint best_score =~1, score =0;
- 713
- 714 dt_root = of_get_flat_dt_root();
- 715while((data = get_next_compat(&compat))){
- 716 score = of_flat_dt_match(dt_root, compat);
- 717if(score >0&& score < best_score){
- 718 best_data = data;
- 719 best_score = score;
- 720}
- 721}
- ......
- 739
- 740 pr_info("Machine model: %s\n", of_flat_dt_get_machine_name());
- 741
- 742return best_data;
- 743}
第714行，通过函数of_get_flat_dt_root获取设备树根节点。
第715~720行，此循环就是查找匹配的machine_desc过程，第716行的of_flat_dt_match函数会将根节点compatible属性的值和每个machine_desc结构体中. dt_compat的值进行比较，直至找到匹配的那个machine_desc。
总结一下，Linux内核通过根节点compatible属性找到对应的设备的函数调用过程，如图43.3.4.2所示：
图43.3.4.2 查找匹配设备的过程
43.3.5 向节点追加或修改内容
产品开发过程中可能面临着频繁的需求更改，比如第一版硬件上有一个IIC接口的六轴芯片MPU6050，第二版硬件又要把这个MPU6050更换为MPU9250等。一旦硬件修改了，我们就要同步的修改设备树文件，毕竟设备树是描述板子硬件信息的文件。假设现在有个六轴芯片fxls8471，fxls8471要接到I.MX6U-ALPHA开发板的I2C1接口上，那么相当于需要在i2c1这个节点上添加一个fxls8471子节点。先看一下I2C1接口对应的节点，打开文件imx6ull.dtsi文件，找到如下所示内容：
示例代码43.3.5.1 i2c1节点
- 937 i2c1: i2c@021a0000 {
- 938 #address-cells =<1>;
- 939 #size-cells =<0>;
- 940 compatible ="fsl,imx6ul-i2c","fsl,imx21-i2c";
- 941 reg =<0x021a00000x4000>;
- 942 interrupts =<GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
- 943 clocks =<&clks IMX6UL_CLK_I2C1>;
- 944 status ="disabled";
- 945};
示例代码43.3.5.1就是I.MX6ULL的I2C1节点，现在要在i2c1节点下创建一个子节点，这个子节点就是fxls8471，最简单的方法就是在i2c1下直接添加一个名为fxls8471的子节点，如下所示：
示例代码43.3.5.2 添加fxls8471子节点
- 937 i2c1: i2c@021a0000 {
- 938 #address-cells =<1>;
- 939 #size-cells =<0>;
- 940 compatible ="fsl,imx6ul-i2c","fsl,imx21-i2c";
- 941 reg =<0x021a00000x4000>;
- 942 interrupts =<GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
- 943 clocks =<&clks IMX6UL_CLK_I2C1>;
- 944 status ="disabled";
- 945
- 946 //fxls8471子节点
- 947 fxls8471@1e {
- 948 compatible ="fsl,fxls8471";
- 949 reg =<0x1e>;
- 950 };
- 951};
第947~950行就是添加的fxls8471这个芯片对应的子节点。但是这样会有个问题！i2c1节点是定义在imx6ull.dtsi文件中的，而imx6ull.dtsi是设备树头文件，其他所有使用到I.MX6ULL这颗SOC的板子都会引用imx6ull.dtsi这个文件。直接在i2c1节点中添加fxls8471就相当于在其他的所有板子上都添加了fxls8471这个设备，但是其他的板子并没有这个设备啊！因此，按照示例代码43.3.5.2这样写肯定是不行的。
这里就要引入另外一个内容，那就是如何向节点追加数据，我们现在要解决的就是如何向i2c1节点追加一个名为fxls8471的子节点，而且不能影响到其他使用到I.MX6ULL的板子。I.MX6U-ALPHA开发板使用的设备树文件为imx6ull-alientek-emmc.dts，因此我们需要在imx6ull-alientek-emmc.dts文件中完成数据追加的内容，方式如下：
示例代码43.3.5.3 节点追加数据方法
- 1&i2c1 {
- 2 /* 要追加或修改的内容 */
- 3};
- 第1行，&i2c1表示要访问i2c1这个label所对应的节点，也就是imx6ull.dtsi中的“i2c1: i2c@021a0000”。
- 第2行，花括号内就是要向i2c1这个节点添加的内容，包括修改某些属性的值。
- 打开imx6ull-alientek-emmc.dts，找到如下所示内容：
- 示例代码43.3.5.4 向i2c1节点追加数据
- 224&i2c1 {
- 225 clock-frequency =<100000>;
- 226 pinctrl-names ="default";
- 227 pinctrl-0=<&pinctrl_i2c1>;
- 228 status ="okay";
- 229
- 230 mag3110@0e {
- 231 compatible ="fsl,mag3110";
- 232 reg =<0x0e>;
- 233 position =<2>;
- 234};
- 235
- 236 fxls8471@1e {
- 237 compatible ="fsl,fxls8471";
- 238 reg =<0x1e>;
- 239 position =<0>;
- 240 interrupt-parent =<&gpio5>;
- 241 interrupts =<08>;
- 242};
- 243};
示例代码43.3.5.4就是向i2c1节点添加/修改数据，比如第225行的属性“clock-frequency”就表示i2c1时钟为100KHz。“clock-frequency”就是新添加的属性。
第228行，将status属性的值由原来的disabled改为okay。
第230~234行，i2c1子节点mag3110，因为NXP官方开发板在I2C1上接了一个磁力计芯片mag3110，正点原子的I.MX6U-ALPHA开发板并没有使用mag3110。
第236~242行，i2c1子节点fxls8471，同样是因为NXP官方开发板在I2C1上接了fxls8471这颗六轴芯片。
因为示例代码43.3.5.4中的内容是imx6ull-alientek-emmc.dts这个文件内的，所以不会对使用I.MX6ULL这颗SOC的其他板子造成任何影响。这个就是向节点追加或修改内容，重点就是通过&label来访问节点，然后直接在里面编写要追加或者修改的内容。
43.4 创建小型模板设备树
上一节已经对DTS的语法做了比较详细的讲解，本节我们就根据前面讲解的语法，从头到尾编写一个小型的设备树文件。当然了，这个小型设备树没有实际的意义，做这个对的目的是为了掌握设备树的语法。在实际产品开发中，我们是不需要完完全全的重写一个.dts设备树文件，一般都是使用SOC厂商提供好的.dts文件，我们只需要在上面根据自己的实际情况做相应的修改即可。在编写设备树之前要先定义一个设备，我们就以I.MX6ULL这个SOC为例，我们需要在设备树里面描述的内容如下：
①、I.MX6ULL这个Cortex-A7架构的32位CPU。
②、I.MX6ULL内部ocram，起始地址0x00900000，大小为128KB(0x20000)。
③、I.MX6ULL内部aips1域下的ecspi1外设控制器，寄存器起始地址为0x02008000，大小为0x4000。
④、I.MX6ULL内部aips2域下的usbotg1外设控制器，寄存器起始地址为0x02184000，大小为0x4000。
⑤、I.MX6ULL内部aips3域下的rngb外设控制器，寄存器起始地址为0x02284000，大小为0x4000。
为了简单起见，我们就在设备树里面就实现这些内容即可，首先，搭建一个仅含有根节点“/”的基础的框架，新建一个名为myfirst.dts文件，在里面输入如下所示内容：
示例代码43.4.1 设备树基础框架
- 1/{
- 2 compatible ="fsl,imx6ull-alientek-evk","fsl,imx6ull";
- 3}
- 设备树框架很简单，就一个根节点“/”，根节点里面只有一个compatible属性。我们就在这个基础框架上面将上面列出的内容一点点添加进来。
- 1、添加cpus节点
- 首先添加CPU节点，I.MX6ULL采用Cortex-A7架构，而且只有一个CPU，因此只有一个cpu0节点，完成以后如下所示：
- 示例代码43.4.2 添加CPU0节点
- 1/{
- 2 compatible ="fsl,imx6ull-alientek-evk","fsl,imx6ull";
- 3
- 4 cpus {
- 5 #address-cells =<1>;
- 6 #size-cells =<0>;
- 7
- 8 //CPU0节点
- 9 cpu0: cpu@0 {
- 10 compatible ="arm,cortex-a7";
- 11 device_type ="cpu";
- 12 reg =<0>;
- 13 };
- 14 };
- 15}
第4~14行，cpus节点，此节点用于描述SOC内部的所有CPU，因为I.MX6ULL只有一个CPU，因此只有一个cpu0子节点。
2、添加soc节点
像uart，iic控制器等等这些都属于SOC内部外设，因此一般会创建一个叫做soc的父节点来管理这些SOC内部外设的子节点，添加soc节点以后的myfirst.dts文件内容如下所示：
示例代码43.4.3 添加soc节点
- 1/{
- 2 compatible ="fsl,imx6ull-alientek-evk","fsl,imx6ull";
- 3
- 4 cpus {
- 5 #address-cells =<1>;
- 6 #size-cells =<0>;
- 7
- 8//CPU0节点
- 9 cpu0: cpu@0 {
- 10 compatible ="arm,cortex-a7";
- 11 device_type ="cpu";
- 12 reg =<0>;
- 13};
- 14};
- 15
- 16//soc节点
- 17 soc {
- 18 #address-cells =<1>;
- 19 #size-cells =<1>;
- 20 compatible ="simple-bus";
- 21 ranges;
- 22}
- 23}
第17~22行，soc节点，soc节点设置#address-cells = <1>，#size-cells = <1>，这样soc子节点的reg属性中起始地占用一个字长，地址空间长度也占用一个字长。
第21行，ranges属性，ranges属性为空，说明子空间和父空间地址范围相同。
3、添加ocram节点
根据第②点的要求，添加ocram节点，ocram是I.MX6ULL内部RAM，因此ocram节点应该是soc节点的子节点。ocram起始地址为0x00900000，大小为128KB(0x20000)，添加ocram节点以后myfirst.dts文件内容如下所示：
示例代码43.4.4 添加ocram节点
- 1/{
- 2 compatible ="fsl,imx6ull-alientek-evk","fsl,imx6ull";
- 3
- 4 cpus {
- 5 #address-cells =<1>;
- 6 #size-cells =<0>;
- 7
- 8//CPU0节点
- 9 cpu0: cpu@0 {
- 10 compatible ="arm,cortex-a7";
- 11 device_type ="cpu";
- 12 reg =<0>;
- 13};
- 14};
- 15
- 16//soc节点
- 17 soc {
- 18 #address-cells =<1>;
- 19 #size-cells =<1>;
- 20 compatible ="simple-bus";
- 21 ranges;
- 22
- 23//ocram节点
- 24 ocram: sram@00900000 {
- 25 compatible ="fsl,lpm-sram";
- 26 reg =<0x009000000x20000>;
- 27};
- 28}
- 29}
第24~27行，ocram节点，第24行节点名字@后面的0x00900000就是ocram的起始地址。第26行的reg属性也指明了ocram内存的起始地址为0x00900000，大小为0x20000。
4、添加aips1、aips2和aips3这三个子节点
I.MX6ULL内部分为三个域：aips1~3，这三个域分管不同的外设控制器，aips1~3这三个域对应的内存范围如表43.4.1所示：
表43.4.1 aips1~3地址范围
我们先在设备树中添加这三个域对应的子节点。aips1~3这三个域都属于soc节点的子节点，完成以后的myfirst.dts文件内容如下所示：
示例代码43.4.5 添加aips1~3节点
- 1/{
- 2 compatible ="fsl,imx6ull-alientek-evk","fsl,imx6ull";
- 3
- 4 cpus {
- 5 #address-cells =<1>;
- 6 #size-cells =<0>;
- 7
- 8//CPU0节点
- 9 cpu0: cpu@0 {
- 10 compatible ="arm,cortex-a7";
- 11 device_type ="cpu";
- 12 reg =<0>;
- 13};
- 14};
- 15
- 16//soc节点
- 17 soc {
- 18 #address-cells =<1>;
- 19 #size-cells =<1>;
- 20 compatible ="simple-bus";
- 21 ranges;
- 22
- 23//ocram节点
- 24 ocram: sram@00900000 {
- 25 compatible ="fsl,lpm-sram";
- 26 reg =<0x009000000x20000>;
- 27};
- 28
- 29 //aips1节点
- 30 aips1: aips-bus@02000000 {
- 31 compatible ="fsl,aips-bus","simple-bus";
- 32 #address-cells =<1>;
- 33 #size-cells =<1>;
- 34 reg =<0x020000000x100000>;
- 35 ranges;
- 36}
- 37
- 38//aips2节点
- 39 aips2: aips-bus@02100000 {
- 40 compatible ="fsl,aips-bus","simple-bus";
- 41 #address-cells =<1>;
- 42 #size-cells =<1>;
- 43 reg =<0x021000000x100000>;
- 44 ranges;
- 45}
- 46
- 47//aips3节点
- 48 aips3: aips-bus@02200000 {
- 49 compatible ="fsl,aips-bus","simple-bus";
- 50 #address-cells =<1>;
- 51 #size-cells =<1>;
- 52 reg =<0x022000000x100000>;
- 53 ranges;
- 54}
- 55}
- 56}
第30~36行，aips1节点。
第39~45行，aips2节点。
第48~54行，aips3节点。
5、添加ecspi1、usbotg1和rngb这三个外设控制器节点
最后我们在myfirst.dts文件中加入ecspi1，usbotg1和rngb这三个外设控制器对应的节点，其中ecspi1属于aips1的子节点，usbotg1属于aips2的子节点，rngb属于aips3的子节点。最终的myfirst.dts文件内容如下：
示例代码43.4.6 添加ecspi1、usbotg1和rngb这三个节点
- 1/{
- 2 compatible ="fsl,imx6ull-alientek-evk","fsl,imx6ull";
- 3
- 4 cpus {
- 5 #address-cells =<1>;
- 6 #size-cells =<0>;
- 7
- 8//CPU0节点
- 9 cpu0: cpu@0 {
- 10 compatible ="arm,cortex-a7";
- 11 device_type ="cpu";
- 12 reg =<0>;
- 13};
- 14};
- 15
- 16//soc节点
- 17 soc {
- 18 #address-cells =<1>;
- 19 #size-cells =<1>;
- 20 compatible ="simple-bus";
- 21 ranges;
- 22
- 23//ocram节点
- 24 ocram: sram@00900000 {
- 25 compatible ="fsl,lpm-sram";
- 26 reg =<0x009000000x20000>;
- 27};
- 28
- 29//aips1节点
- 30 aips1: aips-bus@02000000 {
- 31 compatible ="fsl,aips-bus","simple-bus";
- 32 #address-cells =<1>;
- 33 #size-cells =<1>;
- 34 reg =<0x020000000x100000>;
- 35 ranges;
- 36
- 37//ecspi1节点
- 38 ecspi1: ecspi@02008000 {
- 39 #address-cells =<1>;
- 40 #size-cells =<0>;
- 41 compatible ="fsl,imx6ul-ecspi","fsl,imx51-ecspi";
- 42 reg =<0x020080000x4000>;
- 43 status ="disabled";
- 44};
- 45}
- 46
- 47//aips2节点
- 48 aips2: aips-bus@02100000 {
- 49 compatible ="fsl,aips-bus","simple-bus";
- 50 #address-cells =<1>;
- 51 #size-cells =<1>;
- 52 reg =<0x021000000x100000>;
- 53 ranges;
- 54
- 55//usbotg1节点
- 56 usbotg1: usb@02184000 {
- 57 compatible ="fsl,imx6ul-usb","fsl,imx27-usb";
- 58 reg =<0x021840000x200>;
- 59 status ="disabled";
- 60};
- 61}
- 62
- 63//aips3节点
- 64 aips3: aips-bus@02200000 {
- 65 compatible ="fsl,aips-bus","simple-bus";
- 66 #address-cells =<1>;
- 67 #size-cells =<1>;
- 68 reg =<0x022000000x100000>;
- 69 ranges;
- 70
- 71//rngb节点
- 72 rngb: rngb@02284000 {
- 73 compatible ="fsl,imx6sl-rng","fsl,imx-rng","imx-rng";
- 74 reg =<0x022840000x4000>;
- 75};
- 76}
- 77}
- 78}
第38~44行，ecspi1外设控制器节点。
第56~60行，usbotg1外设控制器节点。
第72~75行，rngb外设控制器节点。
至此，myfirst.dts这个小型的模板设备树就编写好了，基本和imx6ull.dtsi很像，可以看做是imx6ull.dtsi的缩小版。在myfirst.dts里面我们仅仅是编写了I.MX6ULL的外设控制器节点，像IIC接口，SPI接口下所连接的具体设备我们并没有写，因为具体的设备其设备树属性内容不同，这个等到具体的实验在详细讲解。
43.5 设备树在系统中的体现
Linux内核启动的时候会解析设备树中各个节点的信息，并且在根文件系统的/proc/device-tree目录下根据节点名字创建不同文件夹，如图43.5.1所示：
图43.5.1 根节点“/”的属性以及子节点
图43.5.1就是目录/proc/device-tree目录下的内容，/proc/device-tree目录下是根节点“/”的所有属性和子节点，我们依次来看一下这些属性和子节点。
1、根节点“/”各个属性
在图43.5.1中，根节点属性属性表现为一个个的文件(图中细字体文件)，比如图43.5.1中的“#address-cells”、“#size-cells”、“compatible”、“model”和“name”这5个文件，它们在设备树中就是根节点的5个属性。既然是文件那么肯定可以查看其内容，输入cat命令来查看model和compatible这两个文件的内容，结果如图43.5.2所示：
图43.5.2 model和compatible文件内容
从图43.5.2可以看出，文件model的内容是“Freescale i.MX6 ULL 14x14 EVK Board”，文件compatible的内容为“fsl,imx6ull-14x14-evkfsl,imx6ull”。打开文件imx6ull-alientek-emmc.dts查看一下，这不正是根节点“/”的model和compatible属性值吗！
2、根节点“/”各子节点
图43.5.1中各个文件夹(途中粗字体文件夹)就是根节点“/”的各个子节点，比如“aliases”、“backlight”、“chosen”和“clocks”等等。大家可以查看一下imx6ull-alientek-emmc.dts和imx6ull.dtsi这两个文件，看看根节点的子节点都有哪些，看看是否和图43.5.1中的一致。
/proc/device-tree目录就是设备树在根文件系统中的体现，同样是按照树形结构组织的，进入/proc/device-tree/soc目录中就可以看到soc节点的所有子节点，如图43.5.3所示：
图43.5.3 soc节点的所有属性和子节点
和根节点“/”一样，图43.5.3中的所有文件分别为soc节点的属性文件和子节点文件夹。大家可以自行查看一下这些属性文件的内容是否和imx6ull.dtsi中soc节点的属性值相同，也可以进入“busfreq”这样的文件夹里面查看soc节点的子节点信息。
43.6 特殊节点
在根节点“/”中有两个特殊的子节点：aliases和chosen，我们接下来看一下这两个特殊的子节点。
43.6.1 aliases子节点
打开imx6ull.dtsi文件，aliases节点内容如下所示：
示例代码43.6.1.1 aliases子节点
- 18 aliases {
- 19 can0 =&flexcan1;
- 20 can1 =&flexcan2;
- 21 ethernet0 =&fec1;
- 22 ethernet1 =&fec2;
- 23 gpio0 =&gpio1;
- 24 gpio1 =&gpio2;
- ......
- 42 spi0 =&ecspi1;
- 43 spi1 =&ecspi2;
- 44 spi2 =&ecspi3;
- 45 spi3 =&ecspi4;
- 46 usbphy0 =&usbphy1;
- 47 usbphy1 =&usbphy2;
- 48};
单词aliases的意思是“别名”，因此aliases节点的主要功能就是定义别名，定义别名的目的就是为了方便访问节点。不过我们一般会在节点命名的时候会加上label，然后通过&label来访问节点，这样也很方便，而且设备树里面大量的使用&label的形式来访问节点。
43.6.2 chosen子节点
chosen并不是一个真实的设备，chosen节点主要是为了uboot向Linux内核传递数据，重点是bootargs参数。一般.dts文件中chosen节点通常为空或者内容很少，imx6ull-alientek-emmc.dts中chosen节点内容如下所示：
示例代码43.6.2.1 chosen子节点
- 18 chosen {
- 19 stdout-path =&uart1;
- 20};
从示例代码43.6.2.1中可以看出，chosen节点仅仅设置了属性“stdout-path”，表示标准输出使用uart1。但是当我们进入到/proc/device-tree/chosen目录里面，会发现多了bootargs这个属性，如图43.6.2.1所示：
图43.6.2.1 chosen节点目录
输入cat命令查看bootargs这个文件的内容，结果如图43.6.2.2所示：
图43.6.2.2 bootargs文件内容
从图43.6.2.2可以看出，bootargs这个文件的内容为“console=ttymxc0,115200……”，这个不就是我们在uboot中设置的bootargs环境变量的值吗？现在有两个疑点：
①、我们并没有在设备树中设置chosen节点的bootargs属性，那么图43.6.2.1中bootargs这个属性是怎么产生的？
②、为何bootargs文件的内容和uboot中bootargs环境变量的值一样？它们之间有什么关系？
前面讲解uboot的时候说过，uboot在启动Linux内核的时候会将bootargs的值传递给Linux内核，bootargs会作为Linux内核的命令行参数，Linux内核启动的时候会打印出命令行参数(也就是uboot传递进来的bootargs的值)，如图43.6.2.3所示：
图43.6.2.3 命令行参数
既然chosen节点的bootargs属性不是我们在设备树里面设置的，那么只有一种可能，那就是uboot自己在chosen节点里面添加了bootargs属性！并且设置bootargs属性的值为bootargs环境变量的值。因为在启动Linux内核之前，只有uboot知道bootargs环境变量的值，并且uboot也知道.dtb设备树文件在DRAM中的位置，因此uboot的“作案”嫌疑最大。在uboot源码中全局搜索“chosen”这个字符串，看看能不能找到一些蛛丝马迹。果然不出所料，在common/fdt_support.c文件中发现了“chosen”的身影，fdt_support.c文件中有个fdt_chosen函数，此函数内容如下所示：
示例代码43.6.2.2 uboot源码中的fdt_chosen函数
- 275int fdt_chosen(void*fdt)
- 276{
- 277int nodeoffset;
- 278int err;
- 279char*str;/* used to set string properties */
- 280
- 281 err = fdt_check_header(fdt);
- 282if(err <0){
- 283 printf("fdt_chosen: %s\n", fdt_strerror(err));
- 284return err;
- 285}
- 286
- 287/* find or create "/chosen" node. */
- 288 nodeoffset = fdt_find_or_add_subnode(fdt,0,"chosen");
- 289if(nodeoffset <0)
- 290return nodeoffset;
- 291
- 292 str = getenv("bootargs");
- 293if(str){
- 294 err = fdt_setprop(fdt, nodeoffset,"bootargs", str,
- 295 strlen(str)+1);
- 296if(err <0){
- 297 printf("WARNING: could not set bootargs %s.\n",
- 298 fdt_strerror(err));
- 299return err;
- 300}
- 301}
- 302
- 303return fdt_fixup_stdout(fdt, nodeoffset);
- 304}
第288行，调用函数fdt_find_or_add_subnode从设备树(.dtb)中找到chosen节点，如果没有找到的话就会自己创建一个chosen节点。
第292行，读取uboot中bootargs环境变量的内容。
第294行，调用函数fdt_setprop向chosen节点添加bootargs属性，并且bootargs属性的值就是环境变量bootargs的内容。
证据“石锤”了，就是uboot中的fdt_chosen函数在设备树的chosen节点中加入了bootargs属性，并且还设置了bootargs属性值。接下来我们顺着fdt_chosen函数一点点的抽丝剥茧，看看都有哪些函数调用了fdt_chosen，一直找到最终的源头。这里我就不卖关子了，直接告诉大家整个流程是怎么样的，见图43.6.2.4：
图43.6.2.4 fdt_chosen函数调用流程
图43.6.2.4中框起来的部分就是函数do_bootm_linux函数的执行流程，也就是说do_bootm_linux函数会通过一系列复杂的调用，最终通过fdt_chosen函数在chosen节点中加入了bootargs属性。而我们通过bootz命令启动Linux内核的时候会运行do_bootm_linux函数，至此，真相大白，一切事情的源头都源于如下命令：
bootz 80800000 – 83000000
当我们输入上述命令并执行以后，do_bootz函数就会执行，然后一切就按照图43.6.2.4中所示的流程开始运行。
43.7 Linux内核解析DTB文件
Linux内核在启动的时候会解析DTB文件，然后在/proc/device-tree目录下生成相应的设备树节点文件。接下来我们简单分析一下Linux内核是如何解析DTB文件的，流程如图43.7.1所示：
图43.7.1 设备树节点解析流程。
从图43.7.1中可以看出，在start_kernel函数中完成了设备树节点解析的工作，最终实际工作的函数为unflatten_dt_node。
43.8 绑定信息文档
设备树是用来描述板子上的设备信息的，不同的设备其信息不同，反映到设备树中就是属性不同。那么我们在设备树中添加一个硬件对应的节点的时候从哪里查阅相关的说明呢？在Linux内核源码中有详细的.txt文档描述了如何添加节点，这些.txt文档叫做绑定文档，路径为：Linux源码目录/Documentation/devicetree/bindings，如图43.8.1所示：
图43.8.1 绑定文档
比如我们现在要想在I.MX6ULL这颗SOC的I2C下添加一个节点，那么就可以查看Documentation/devicetree/bindings/i2c/i2c-imx.txt，此文档详细的描述了I.MX系列的SOC如何在设备树中添加I2C设备节点，文档内容如下所示：
- * Freescale Inter IC (I2C) and High Speed Inter IC (HS-I2C) for i.MX
- Required properties:
- - compatible :
- - "fsl,imx1-i2c" for I2C compatible with the one integrated on i.MX1 SoC
- - "fsl,imx21-i2c" for I2C compatible with the one integrated on i.MX21 SoC
- - "fsl,vf610-i2c" for I2C compatible with the one integrated on Vybrid vf610 SoC
- - reg : Should contain I2C/HS-I2C registers location and length
- - interrupts : Should contain I2C/HS-I2C interrupt
- - clocks : Should contain the I2C/HS-I2C clock specifier
- Optional properties:
- - clock-frequency : Constains desired I2C/HS-I2C bus clock frequency in Hz.
- The absence of the propoerty indicates the default frequency 100 kHz.
- - dmas: A list of two dma specifiers, one for each entry in dma-names.
- - dma-names: should contain "tx" and "rx".
- Examples:
- i2c@83fc4000 { /* I2C2 on i.MX51 */
- compatible = "fsl,imx51-i2c", "fsl,imx21-i2c";
- reg = <0x83fc4000 0x4000>;
- interrupts = <63>;
- };
- i2c@70038000 { /* HS-I2C on i.MX51 */
- compatible = "fsl,imx51-i2c", "fsl,imx21-i2c";
- reg = <0x70038000 0x4000>;
- interrupts = <64>;
- clock-frequency = <400000>;
- };
- i2c0: i2c@40066000 { /* i2c0 on vf610 */
- compatible = "fsl,vf610-i2c";
- reg = <0x40066000 0x1000>;
- interrupts =<0 71 0x04>;
- dmas = <&edma0 0 50>,
- <&edma0 0 51>;
- dma-names = "rx","tx";
- };
有时候使用的一些芯片在Documentation/devicetree/bindings目录下找不到对应的文档，这个时候就要咨询芯片的提供商，让他们给你提供参考的设备树文件。
43.9 设备树常用OF操作函数
设备树描述了设备的详细信息，这些信息包括数字类型的、字符串类型的、数组类型的，我们在编写驱动的时候需要获取到这些信息。比如设备树使用reg属性描述了某个外设的寄存器地址为0X02005482，长度为0X400，我们在编写驱动的时候需要获取到reg属性的0X02005482和0X400这两个值，然后初始化外设。Linux内核给我们提供了一系列的函数来获取设备树中的节点或者属性信息，这一系列的函数都有一个统一的前缀“of_”，所以在很多资料里面也被叫做OF函数。这些OF函数原型都定义在include/linux/of.h文件中。
43.9.1 查找节点的OF函数
设备都是以节点的形式“挂”到设备树上的，因此要想获取这个设备的其他属性信息，必须先获取到这个设备的节点。Linux内核使用device_node结构体来描述一个节点，此结构体定义在文件include/linux/of.h中，定义如下：
示例代码43.3.9.1 device_node节点
- 49struct device_node {
- 50 constchar*name; /* 节点名字 */
- 51 constchar*type; /* 设备类型 */
- 52 phandle phandle;
- 53 constchar*full_name; /* 节点全名 */
- 54 struct fwnode_handle fwnode;
- 55
- 56 struct property *properties; /* 属性 */
- 57 struct property *deadprops; /* removed属性 */
- 58 struct device_node *parent; /* 父节点 */
- 59 struct device_node *child; /* 子节点 */
- 60 struct device_node *sibling;
- 61 struct kobject kobj;
- 62 unsignedlong _flags;
- 63 void*data;
- 64 #if defined(CONFIG_SPARC)
- 65 constchar*path_component_name;
- 66 unsignedint unique_id;
- 67 struct of_irq_controller *irq_trans;
- 68 #endif
- 69};
与查找节点有关的OF函数有5个，我们依次来看一下。
- 1、of_find_node_by_name函数
- of_find_node_by_name函数通过节点名字查找指定的节点，函数原型如下：
- struct device_node *of_find_node_by_name(struct device_node *from,
- const char *name);
函数参数和返回值含义如下：
from：开始查找的节点，如果为NULL表示从根节点开始查找整个设备树。
name：要查找的节点名字。
返回值：找到的节点，如果为NULL表示查找失败。
2、of_find_node_by_type函数
of_find_node_by_type函数通过device_type属性查找指定的节点，函数原型如下：
- struct device_node *of_find_node_by_type(struct device_node *from,const char *type)
函数参数和返回值含义如下：
from：开始查找的节点，如果为NULL表示从根节点开始查找整个设备树。
type：要查找的节点对应的type字符串，也就是device_type属性值。
返回值：找到的节点，如果为NULL表示查找失败。
3、of_find_compatible_node函数
of_find_compatible_node函数根据device_type和compatible这两个属性查找指定的节点，函数原型如下：
- struct device_node *of_find_compatible_node(struct device_node *from,
- const char *type,
- const char *compatible)
- 函数参数和返回值含义如下：
from：开始查找的节点，如果为NULL表示从根节点开始查找整个设备树。
type：要查找的节点对应的type字符串，也就是device_type属性值，可以为NULL，表示忽略掉device_type属性。
compatible：要查找的节点所对应的compatible属性列表。
返回值：找到的节点，如果为NULL表示查找失败
4、of_find_matching_node_and_match函数
of_find_matching_node_and_match函数通过of_device_id匹配表来查找指定的节点，函数原型如下：
- struct device_node *of_find_matching_node_and_match(struct device_node *from,
- const struct of_device_id *matches,
- const struct of_device_id **match)
- 函数参数和返回值含义如下：
from：开始查找的节点，如果为NULL表示从根节点开始查找整个设备树。
matches：of_device_id匹配表，也就是在此匹配表里面查找节点。
match：找到的匹配的of_device_id。
返回值：找到的节点，如果为NULL表示查找失败
5、of_find_node_by_path函数
of_find_node_by_path函数通过路径来查找指定的节点，函数原型如下：
- inline struct device_node *of_find_node_by_path(const char *path)
函数参数和返回值含义如下：
path：带有全路径的节点名，可以使用节点的别名，比如“/backlight”就是backlight这个节点的全路径。
返回值：找到的节点，如果为NULL表示查找失败
43.9.2 查找父/子节点的OF函数
Linux内核提供了几个查找节点对应的父节点或子节点的OF函数，我们依次来看一下。
1、of_get_parent函数
of_get_parent函数用于获取指定节点的父节点(如果有父节点的话)，函数原型如下：
struct device_node *of_get_parent(const struct device_node *node)
函数参数和返回值含义如下：
node：要查找的父节点的节点。
返回值：找到的父节点。
2、of_get_next_child函数
of_get_next_child函数用迭代的查找子节点，函数原型如下：
- struct device_node *of_get_next_child(const struct device_node *node,
- struct device_node *prev)
函数参数和返回值含义如下：
node：父节点。
prev：前一个子节点，也就是从哪一个子节点开始迭代的查找下一个子节点。可以设置为NULL，表示从第一个子节点开始。
返回值：找到的下一个子节点。
43.9.3 提取属性值的OF函数
节点的属性信息里面保存了驱动所需要的内容，因此对于属性值的提取非常重要，Linux内核中使用结构体property表示属性，此结构体同样定义在文件include/linux/of.h中，内容如下：
示例代码43.9.3.1 property结构体
- 35struct property {
- 36 char*name; /* 属性名字 */
- 37 int length; /* 属性长度 */
- 38 void*value; /* 属性值 */
- 39 struct property *next; /* 下一个属性 */
- 40 unsignedlong _flags;
- 41 unsignedint unique_id;
- 42 struct bin_attribute attr;
- 43};
Linux内核也提供了提取属性值的OF函数，我们依次来看一下。
- 1、of_find_property函数
- of_find_property函数用于查找指定的属性，函数原型如下：
- property *of_find_property(const struct device_node *np,
- const char *name,
- int *lenp)
函数参数和返回值含义如下：
np：设备节点。
name：属性名字。
lenp：属性值的字节数
返回值：找到的属性。
2、of_property_count_elems_of_size函数
of_property_count_elems_of_size函数用于获取属性中元素的数量，比如reg属性值是一个数组，那么使用此函数可以获取到这个数组的大小，此函数原型如下：
- int of_property_count_elems_of_size(const struct device_node *np,
- const char *propname,
- int elem_size)
函数参数和返回值含义如下：
np：设备节点。
proname：需要统计元素数量的属性名字。
elem_size：元素长度。
返回值：得到的属性元素数量。
3、of_property_read_u32_index函数
of_property_read_u32_index函数用于从属性中获取指定标号的u32类型数据值(无符号32位)，比如某个属性有多个u32类型的值，那么就可以使用此函数来获取指定标号的数据值，此函数原型如下：
- int of_property_read_u32_index(const struct device_node *np,
- const char *propname,
- u32 index,
- u32 *out_value)
- 函数参数和返回值含义如下：
np：设备节点。
proname：要读取的属性名字。
index：要读取的值标号。
out_value：读取到的值
返回值：0读取成功，负值，读取失败，-EINVAL表示属性不存在，-ENODATA表示没有要读取的数据，-EOVERFLOW表示属性值列表太小。
4、 of_property_read_u8_array函数
of_property_read_u16_array函数
of_property_read_u32_array函数
of_property_read_u64_array函数
这4个函数分别是读取属性中u8、u16、u32和u64类型的数组数据，比如大多数的reg属性都是数组数据，可以使用这4个函数一次读取出reg属性中的所有数据。这四个函数的原型如下：
- int of_property_read_u8_array(const struct device_node *np,
- const char *propname,
- u8 *out_values,
- size_t sz)
- int of_property_read_u16_array(const struct device_node *np,
- const char *propname,
- u16 *out_values,
- size_t sz)
- int of_property_read_u32_array(const struct device_node *np,
- const char *propname,
- u32 *out_values,
- size_t sz)
- int of_property_read_u64_array(const struct device_node *np,
- const char *propname,
- u64 *out_values,
- size_t sz)
函数参数和返回值含义如下：
np：设备节点。
proname：要读取的属性名字。
out_value：读取到的数组值，分别为u8、u16、u32和u64。
sz：要读取的数组元素数量。
返回值：0，读取成功，负值，读取失败，-EINVAL表示属性不存在，-ENODATA表示没有要读取的数据，-EOVERFLOW表示属性值列表太小。
- 5、of_property_read_u8函数
- of_property_read_u16函数
- of_property_read_u32函数
- of_property_read_u64函数
有些属性只有一个整形值，这四个函数就是用于读取这种只有一个整形值的属性，分别用于读取u8、u16、u32和u64类型属性值，函数原型如下：
- int of_property_read_u8(const struct device_node *np,
- const char *propname,
- u8 *out_value)
- int of_property_read_u16(const struct device_node *np,
- const char *propname,
- u16 *out_value)
- int of_property_read_u32(const struct device_node *np,
- const char *propname,
- u32 *out_value)
- int of_property_read_u64(const struct device_node *np,
- const char *propname,
- u64 *out_value)
函数参数和返回值含义如下：
np：设备节点。
proname：要读取的属性名字。
out_value：读取到的数组值。
返回值：0，读取成功，负值，读取失败，-EINVAL表示属性不存在，-ENODATA表示没有要读取的数据，-EOVERFLOW表示属性值列表太小。
6、of_property_read_string函数
of_property_read_string函数用于读取属性中字符串值，函数原型如下：
- int of_property_read_string(struct device_node *np,
- const char *propname,
- const char **out_string)
- 函数参数和返回值含义如下：
np：设备节点。
proname：要读取的属性名字。
out_string：读取到的字符串值。
返回值：0，读取成功，负值，读取失败。
7、of_n_addr_cells函数
of_n_addr_cells函数用于获取#address-cells属性值，函数原型如下：
int of_n_addr_cells(struct device_node *np)
函数参数和返回值含义如下：
np：设备节点。
返回值：获取到的#address-cells属性值。
8、of_n_size_cells函数
of_size_cells函数用于获取#size-cells属性值，函数原型如下：
int of_n_size_cells(struct device_node *np)
函数参数和返回值含义如下：
np：设备节点。
返回值：获取到的#size-cells属性值。
43.9.4 其他常用的OF函数
1、of_device_is_compatible函数
of_device_is_compatible函数用于查看节点的compatible属性是否有包含compat指定的字符串，也就是检查设备节点的兼容性，函数原型如下：
- int of_device_is_compatible(const struct device_node *device,
- const char *compat)
函数参数和返回值含义如下：
device：设备节点。
compat：要查看的字符串。
返回值：0，节点的compatible属性中包含compat指定的字符串；其他值，节点的compatible属性中不包含compat指定的字符串。
2、of_get_address函数
of_get_address函数用于获取地址相关属性，主要是“reg”或者“assigned-addresses”属性值，函数属性如下：
- const __be32 *of_get_address(struct device_node *dev,
- int index,
- u64 *size,
- unsigned int *flags)
函数参数和返回值含义如下：
dev：设备节点。
index：要读取的地址标号。
size：地址长度。
flags：参数，比如IORESOURCE_IO、IORESOURCE_MEM等
返回值：读取到的地址数据首地址，为NULL的话表示读取失败。
3、of_translate_address函数
of_translate_address函数负责将从设备树读取到的地址转换为物理地址，函数原型如下：
- u64 of_translate_address(struct device_node *dev,
- const __be32 *in_addr)
函数参数和返回值含义如下：
dev：设备节点。
in_addr：要转换的地址。
返回值：得到的物理地址，如果为OF_BAD_ADDR的话表示转换失败。
4、of_address_to_resource函数
IIC、SPI、GPIO等这些外设都有对应的寄存器，这些寄存器其实就是一组内存空间，Linux内核使用resource结构体来描述一段内存空间，“resource”翻译出来就是“资源”，因此用resource结构体描述的都是设备资源信息，resource结构体定义在文件include/linux/ioport.h中，定义如下：
示例代码43.9.4.1 resource结构体
- 18struct resource {
- 19 resource_size_t start;
- 20 resource_size_t end;
- 21 constchar*name;
- 22 unsignedlong flags;
- 23 struct resource *parent,*sibling,*child;
- 24};
- 对于32位的SOC来说，resource_size_t是u32类型的。其中start表示开始地址，end表示结束地址，name是这个资源的名字，flags是资源标志位，一般表示资源类型，可选的资源标志定义在文件include/linux/ioport.h中，如下所示：
- 示例代码43.9.4.2 资源标志
- 1 #define IORESOURCE_BITS 0x000000ff
- 2 #define IORESOURCE_TYPE_BITS 0x00001f00
- 3 #define IORESOURCE_IO 0x00000100
- 4 #define IORESOURCE_MEM 0x00000200
- 5 #define IORESOURCE_REG 0x00000300
- 6 #define IORESOURCE_IRQ 0x00000400
- 7 #define IORESOURCE_DMA 0x00000800
- 8 #define IORESOURCE_BUS 0x00001000
- 9 #define IORESOURCE_PREFETCH 0x00002000
- 10 #define IORESOURCE_READONLY 0x00004000
- 11 #define IORESOURCE_CACHEABLE 0x00008000
- 12 #define IORESOURCE_RANGELENGTH 0x00010000
- 13 #define IORESOURCE_SHADOWABLE 0x00020000
- 14 #define IORESOURCE_SIZEALIGN 0x00040000
- 15 #define IORESOURCE_STARTALIGN 0x00080000
- 16 #define IORESOURCE_MEM_64 0x00100000
- 17 #define IORESOURCE_WINDOW 0x00200000
- 18 #define IORESOURCE_MUXED 0x00400000
- 19 #define IORESOURCE_EXCLUSIVE 0x08000000
- 20 #define IORESOURCE_DISABLED 0x10000000
- 21 #define IORESOURCE_UNSET 0x20000000
- 22 #define IORESOURCE_AUTO 0x40000000
- 23 #define IORESOURCE_BUSY 0x80000000
大家一般最常见的资源标志就是IORESOURCE_MEM、IORESOURCE_REG和IORESOURCE_IRQ等。接下来我们回到of_address_to_resource函数，此函数看名字像是从设备树里面提取资源值，但是本质上就是将reg属性值，然后将其转换为resource结构体类型，函数原型如下所示
- int of_address_to_resource(struct device_node *dev,
- int index,
- struct resource *r)
函数参数和返回值含义如下：
dev：设备节点。
index：地址资源标号。
r：得到的resource类型的资源值。
返回值：0，成功；负值，失败。
5、of_iomap函数
of_iomap函数用于直接内存映射，以前我们会通过ioremap函数来完成物理地址到虚拟地址的映射，采用设备树以后就可以直接通过of_iomap函数来获取内存地址所对应的虚拟地址，不需要使用ioremap函数了。当然了，你也可以使用ioremap函数来完成物理地址到虚拟地址的内存映射，只是在采用设备树以后，大部分的驱动都使用of_iomap函数了。of_iomap函数本质上也是将reg属性中地址信息转换为虚拟地址，如果reg属性有多段的话，可以通过index参数指定要完成内存映射的是那一段，of_iomap函数原型如下：
- void __iomem *of_iomap(struct device_node *np,
- int index)
函数参数和返回值含义如下：
np：设备节点。
index：reg属性中要完成内存映射的段，如果reg属性只有一段的话index就设置为0。
返回值：经过内存映射后的虚拟内存首地址，如果为NULL的话表示内存映射失败。
关于设备树常用的OF函数就先讲解到这里，Linux内核中关于设备树的OF函数不仅仅只有前面讲的这几个，还有很多OF函数我们并没有讲解，这些没有讲解的OF函数要结合具体的驱动，比如获取中断号的OF函数、获取GPIO的OF函数等等，这些OF函数我们在后面的驱动实验中再详细的讲解。
关于设备树就讲解到这里，关于设备树我们重点要了解一下几点内容：
①、DTS、DTB和DTC之间的区别，如何将.dts文件编译为.dtb文件。
②、设备树语法，这个是重点，因为在实际工作中我们是需要修改设备树的。
③、设备树的几个特殊子节点。
④、关于设备树的OF操作函数，也是重点，因为设备树最终是被驱动文件所使用的，而驱动文件必须要读取设备树中的属性信息，比如内存信息、GPIO信息、中断信息等等。要想在驱动中读取设备树的属性值，那么就必须使用Linux内核提供的众多的OF函数。
从下一章开始所以的Linux驱动实验都将采用设备树，从最基本的点灯，到复杂的音频、网络或块设备等驱动。将会带领大家由简入深，深度剖析设备树，最终掌握基于设备树的驱动开发技能。
|
发表于 2020-6-28 15:36:10
