Zynq SOC学习笔记之设备树

梦里梦外; 2023-03-13 03:43 549阅读 0赞

# 一. 概述 #

DTS即DeviceTree Source 设备树源码,是一种描述硬件的数据结构

以树状节点的方式描述一个设备的各种硬件信息细节：CPU、GPIO、时钟、中断、内存等，形成类似文本文件dts，直接透过它传递给Linux，使得驱动程序与硬件分离，只需要修改dts文件，便能实现需求。设备树易于扩展，硬件有变动时不需要重新编译内核或驱动程序，只需要提供不一样的dtb文件。

以飞凌MX6UL-C为例当需要增删spi1外设功能时，只需要增删修改对应dts文件源码，即可满足开发需求，方便快捷。

![format_png][]

“compatible”属性是用来匹配驱动的，他的类型是字符串数组，每个字符串表示一种设备的类型，从具体到一般。例如spi控制器节点的属性”compatible= “fsl,imx51-ecspi”；。字符串fsl,imx51-ecspi为驱动名称。compatible= "spidev";中spidev为spi对应的驱动配置。

需要增加spi1时将status = "disabled"部分改okay即可

## 二、设备树语法 ##

“/"代表根节点；

“model”是板的ID；

"compatible"是平台兼容，一般格式是"manufacturer,model"。内核或者uboot依靠这个属性找到相对应driver，若"compatible"出现多个属性，按序匹配driver；

“\#address-cells”是address的单位(32bit)，可寻址的设备使用它、\#size-cells、reg在Device Tree中编码地址信息，reg中的address 和 length 字段是可变长的，父结点的\#address-cells和\#size-cells分别决定了子结点的reg属性的address和length字段的长度。如果root结点的\#address-cells = <1>;和\#size-cells = <1>;决定了serial、gpio、spi等结点的address和length字段的长度分别为1（reg中描述address和length的字段都只能有1个）。cpus 结点的\#address-cells = <1>;和\#size-cells = <0>;决定了2个cpu子结点的address为1，而length为空。可以理解为地址需要几个维度来描述，如片选0的偏移0地址处，就需要\#address-cells为2.

“\#size-cells”是length的单位(32bit)；

"reg"是寄存器，格式是"<address,length>"，作为平台内存资源，组织形式为reg = <address1 length1 \[address2 length2\] \[address3 length3\] ... >，length则为cell的列表或者为空（若\#size-cells = 0）

"aliase" 是别名，必须节点全称，可以通过地址引用获取；

”chosen“是板级启动参数；

"cpus"是SOC的CPU信息，可以改变运行频率或者开关CPU，命名遵循的组织形式为：<name>\[@<unit-address>\]，多个相同类型设备结点的name可以一样，只要unit-address不同即可，如本例中含有cpu@0、cpu@1，设备的unit-address地址也经常在其对应结点的reg属性中给出。

"memory"是板级内存的信息。

"interrupts"是中断控制器，根据SOC自定义格式，这里是<输入类型 中断号 触发方式>，作为平台中断资源；输入类型：0是SPI中断，1是PPI中断；触发类型：0上升沿，2下降沿(对SPI无效)，4高电平，8低电平(对SPI无效)，见Documentation\\devicetree\\bindings\\interrupt-controller\\arm,gic.txt

“interrupt-controller”指示这个节点是中断控制节点，它的属性为空，中断控制器应该加上此属性表明自己的身份（直接在\{\}中写上interrupt-controller即可）

“interrupt-cells”与\#address-cells 和 \#size-cells相似，它表明连接此中断控制器的设备的interrupts属性的cell大小

"interrupt-parent"设备结点透过它来指定它所依附的中断控制器的phandle，当结点没有指定interrupt-parent 时，则从父级结点继承。

"\[label:\]"如gic: interrupt-controller@1c81000，这个标签可以作为地址赋值到其他节点的属性；

“device\_type":设备类型，寻找节点可以依据这个属性；

"status"是开关节点设备的状态，取值"okay"或者"ok"表示使能，"disabled"表示失能。

“ranges” 经过总线桥后的address往往需要经过转换才能对应的CPU的memory映射。external-bus的ranges属性定义了经过external-bus桥后的地址范围如何映射到CPU的memory区域。ranges是地址转换表，其中的每个项目是一个子地址、父地址以及在子地址空间的大小的映射。映射表中的子地址、父地址分别采用子地址空间的\#address-cells和父地址空间的\#address-cells大小。

例如：ranges = <0 0 0x10100000 0x10000 将子地址空间的片选0的0偏移地址处映射到地址0x10100000处，映射大小为0x10000 字节

1 0 0x10160000 0x10000>; 将子地址空间的片选1的0偏移地址处映射到地址0x10160000处，映射大小为0x10000 字节

## 2.1 节点名 ##

理论个节点名只要是长度不超过31个字符的ASCII字符串即可，此外  
Linux内核还约定设备名应写成形如`<name>[@<unit_address>]`的形式，其中name就是设备名，最长可以是31个字符长度。unit\_address一般是设备地址，用来唯一标识一个节点，下面就是典型节点名的写法

![format_png 1][]

上面的节点名是`firmware`，节点路径是`/firmware@0203f000`,这点要注意，因为根据节点名查找节点的API的参数是不能有"@xxx"这部分的。

### 2.1.1 chosen节点 ###

chosen节点不描述一个真实设备，而是用于firmware传递一些数据给OS，比如bootloader传递内核启动参数给内核

![format_png 2][]

### 2.1.2 aliases node ###

aliases {
    
    i2c6 = &pca9546_i2c0;
    
    i2c7 = &pca9546_i2c1;
    
    i2c8 = &pca9546_i2c2;
    
    i2c9 = &pca9546_i2c3;
    
    };

aliases node用来定义别名，类似C++中引用。上面是一个在.dtsi中的典型应用，当使用i2c6时，也即使用pca9546\_i2c0，使得引用节点变得简单方便。例：当.dts include 该.dtsi时，将i2c6的status属性赋值为okay，则表明该主板上的pca9546\_i2c0处于enable状态；反之，status赋值为disabled，则表明该主板上的pca9546\_i2c0处于disenable状态。如下是引用的具体例子：

&i2c6 \{--------------这里&i2c6到底是label还是alias???

status = "okay";

\};------------------在\*.dtsi中大多默认为设备为disable，然后在\*.dts中将其enable,进行重写使能。

### 2.1.3 memory node ###

memory {
    
    device_type = "memory";
    
    reg = <0x00000000 0x20000000>; /* 512 MB */
    
    };

对于memory node，device\_type必须为memory，由之前的描述可以知道该memory node是以0x00000000为起始地址，以0x20000000为结束地址的512MB的空间。

一般而言，在.dts中不对memory进行描述，而是通过bootargs中类似521M@0x00000000的方式传递给内核。

## 2.2 **键值对** ##

在设备树中，**键值对**是描述属性的方式，比如，Linux驱动中可以通过设备节点中的**"compatible"**这个属性查找设备节点。  
Linux设备树语法中定义了一些具有规范意义的属性，包括：**compatible**, **address**, **interrupt**等，这些信息能够在内核初始化找到节点的时候，自动解析生成相应的设备信息。此外，还有一些Linux内核定义好的，一类设备通用的有默认意义的属性，这些属性一般不能被内核自动解析生成相应的设备信息，但是内核已经编写的相应的解析提取函数，常见的有 **"mac\_addr"**，**"gpio"**，**"clock"**，**"power"**。**"regulator"** 等等。

### 2.2.1 compatible ###

设备节点中对应的节点信息已经被内核构造成**struct platform\_device**。驱动可以通过相应的函数从中提取信息。compatible属性是用来查找节点的方法之一，另外还可以通过节点名或节点路径查找指定节点。dm9000驱动中就是使用下面这个函数通过设备节点中的**"compatible"**属性提取相应的信息，所以二者的字符串需要严格匹配。  
在下面的这个dm9000的例子中，我们在相应的板级dts中找到了这样的代码块：  
![format_png 3][]  
然后我们取内核源码中找到dm9000的网卡驱动，从中可以发现这个驱动是使用的设备树描述的设备信息(这不废话么，显然用设备树好处多多)。我们可以找到它用来描述设备信息的结构体，可以看出，驱动中用于匹配的结构使用的**compatible**和设备树中一模一样，否则就可能无法匹配，这里另外的一点是**struct of\_device\_id**数组的最后一个成员一定是空，因为相关的操作API会读取这个数组直到遇到一个**空**。

![format_png 4][]

### 2.2.2 address ###

(几乎)所有的设备都需要与CPU的IO口相连，所以其IO端口信息就需要在设备节点节点中说明。常用的属性有

*  **\#address-cells**，用来描述子节点**"reg"**属性的地址表中用来描述首地址的cell的数量，
 *  **\#size-cells**，用来描述子节点**"reg"**属性的地址表中用来描述地址长度的cell的数量。

有了这两个属性，子节点中的**"reg"**就可以描述一块连续的地址区域。下例中，父节点中指定了**\#address-cells = <2>;\#size-cells = <1>**，则子节点dev-bootscs0中的**reg**中的前两个数表示一个地址,即**MBUS\_ID(0xf0, 0x01)**和**0x1045C**，最后一个数的表示地址跨度，即是**0x4**

![format_png 5][]

### **2.2.3 Reg属性** ###

在device node 中，reg是描述memory-mapped IO register的offset和length。子节点的reg属性address和length长度取决于父节点对应的\#address-cells和\#size-cells的值。例：

![format_png 6][]

在上述的aips节点中，存在子节点spda。spda中的中reg为<0x70000000 0x40000 >，其0x700000000为address，0x40000为size。这一点在图3-1下有作介绍。

这里补充的一点是：设备节点的名称格式node-name@unit-address，节点名称用node-name唯一标识，为一个ASCII字符串。其中@unit-address为可选项，可以不作描述。unit-address的具体格式和设备挂载在哪个bus上相关。如：cpu的unit-address从0开始编址，以此加1；本例中，aips为0x70000000。

### **2.2.4. ranges属性** ###

ranges属性为地址转换表，这在pcie中使用较为常见，它表明了该设备在到parent节点中所对用的地址映射关系。ranges格式长度受当前节点\#address-cell、parent节点\#address-cells、当前节点\#size-cell所控制。顺序为ranges=<前节点\#address-cell, parent节点\#address-cells , 当前节点\#size-cell。在本例中，当前节点\#address-cell=<1>,对应于⑤中的第一个0x20000000；parent节点\#address-cells=<1>，对应于⑤中的第二个0x20000000；当前节点\#size-cell=<1>，对应于⑤中的0x30000000。即ahb0节点所占空间从0x20000000地址开始，对应于父节点的0x20000000地址开始的0x30000000地址空间大小。

### 2.2.5 interrupts ###

一个计算机系统中大量设备都是通过中断请求CPU服务的，所以设备节点中就需要在指定中断号。常用的属性有

*  **interrupt-controller** 一个空属性用来声明这个node接收中断信号，即这个node是一个中断控制器。
 *  **\#interrupt-cells**，是中断控制器节点的属性，用来标识这个控制器需要几个单位做中断描述符,用来描述子节点中**"interrupts"**属性使用了父节点中的**interrupts**属性的具体的哪个值。一般，如果父节点的该属性的值是3，则子节点的interrupts一个cell的三个32bits整数值分别为:<中断域 中断 触发方式>,如果父节点的该属性是2，则是<中断 触发方式>
 *  **interrupt-parent**,标识此设备节点属于哪一个中断控制器，如果没有设置这个属性，会自动依附父节点的
 *  **interrupts**,一个中断标识符列表，表示每一个中断输出信号

设备树中中断的部分涉及的部分比较多，**interrupt-controller**表示这个节点是一个中断控制器，需要注意的是，一个SoC中可能有不止一个中断控制器，这就会涉及到设备树中断组织的很多概念，下面是在文件**"arch/arm/boot/dts/exynos4.dtsi"**中对exynos4412的中断控制器(GIC)节点描述：

![format_png 7][]

要说**interrupt-parent**，就得首先讲讲Linux设备管理中对中断的设计思路演变。随着linux kernel的发展，在内核中将interrupt controller抽象成**irqchip**这个概念越来越流行，甚至GPIO controller也可以被看出一个interrupt controller chip，这样，系统中至少有两个中断控制器了，另外，在硬件上，随着系统复杂度加大，外设中断数据增加，实际上系统可以需要多个中断控制器进行级联，形成事实上的硬件中断处理结构：

> ![format_png 8][]

在这种趋势下，内核中原本的中断源直接到中断号的方式已经很难继续发展了，为了解决这些问题，linux kernel的大牛们就创造了**irq domain**(中断域)这个概念。domain在内核中有很多，除了irqdomain，还有power domain，clock domain等等，所谓domain，就是领域，范围的意思，也就是说，任何的定义出了这个范围就没有意义了。如上所述，系统中所有的interrupt controller会形成树状结构，对于每个interrupt controller都可以连接若干个外设的中断请求（interrupt source，中断源），interrupt controller会对连接其上的interrupt source（根据其在Interrupt controller中物理特性）进行编号（也就是HW interrupt ID了）。有了**irq domain**这个概念之后，这个编号仅仅限制在本interrupt controller范围内，有了这样的设计，CPU(Linux 内核)就可以根据级联的规则一级一级的找到想要访问的中断。当然，通常我们关心的只是内核中的中断号，具体这个中断号是怎么找到相应的中断源的，我们作为程序员往往不需要关心，除了在写设备树的时候，设备树就是要描述嵌入式软件开发中涉及的所有硬件信息，所以，设备树就需要准确的描述硬件上处理中断的这种树状结构，如此，就有了我们的**interrupt-parant**这样的概念：用来连接这样的树状结构的上下级，用于表示这个中断归属于哪个interrupt controller，比如，一个接在GPIO上的按键，它的组织形式就是：

> **中断源**\--interrupt parent-->**GPIO**\--interrupt parent-->**GIC1**\--interrupt parent-->**GIC2**\--...-->**CPU**

有了parant，我们就可以使用一级一级的**偏移量**来最终获得当前中断的绝对编号，这里，可以看出，在我板子上的dm9000的的设备节点中，它的**"interrupt-parent"**引用了**"exynos4x12-pinctrl.dtsi"**（被板级设备树的exynos4412.dtsi包含）中的gpx0节点：  
![format_png 9][]

而在gpx0节点中，指定了**"\#interrupt-cells = <2>;"**，所以在dm9000中的属性**"interrupts = <6 4>;"**表示dm9000的的中断在作为irq parant的gpx0中的中断偏移量，即gpx0中的属性**"interrupts"**中的**"<0 22 0>"**，通过查阅exynos4412的手册知道，对应的中断号是EINT\[6\]。  
![format_png 10][]

### 2.2.6 gpio ###

gpio也是最常见的IO口，常用的属性有

*  **"gpio-controller"**，用来说明该节点描述的是一个gpio控制器
 *  **"\#gpio-cells"**，用来描述gpio使用节点的属性一个cell的内容，即 \`属性 = <&引用GPIO节点别名 GPIO标号 工作模式>

GPIO的设置同样采用了上述**偏移量**的思想，比如下面的这个led的设备书，表示使用GPX2组的第7个引脚：  
![format_png 11][]

###  ###

## **2.3 VALUE** ##

dts描述一个键的值有多种方式，当然，一个键也可以没有值

### 字符串信息 ###

![format_png 12][]

### 32bit无符号整型数组信息 ###

![format_png 13][]

### 二进制数数组 ###

![format_png 14][]

### 字符串哈希表 ###

![format_png 15][]

# 三. dtb、dtsi、dtb文件作用、关系 #

dtsi——类似于c语言的头文件

dts——类似于c语言的源文件

dtb——类似于c语言的编译产物、二进制文件

由于一个soc可能有多个不同电路板，而每个电路板拥有一个.dts。这些dts势必会存在许多共同部分，为了减少代码的冗余，设备树讲这些共同部分提炼保存在.dtsi文件中，供不同的dts共同使用。编译工具编译.dts生成的二进制文件(.dtb),uboot在引到内核时，会预先读取.dtb到内存，进而由内核解析，系统启动

1.编译设备树：cd linux-x.xx & make dtbs，生成的dtb在目录linux-x.xx/arch/xxx/boot/dts下

2.反编译dtb，生成dts: linux-x.xx/scripts/dtc/dtc -I dtb -O dts xxxx.dtb -o xxxx.dts

3.将.dts编译为.dtb的工具。DTC的源代码位于内核的scripts/dtc目录，在Linux内核使能了Device Tree的情况下，编译内核的时候主机工具dtc会被编译出来，对应scripts/dtc/Makefile中的“hostprogs-y := dtc”这一hostprogs编译target。  
在Linux内核的arch/arm/boot/dts/Makefile中，描述了当某种SoC被选中后，哪些.dtb文件会被编译出来。

在Linux下，我们可以单独编译Device Tree文件。当我们在Linux内核下运行make dtbs时，若我们之前选择了ARCH\_VEXPRESS，上述.dtb都会由对应的.dts编译出来。因为arch/arm/Makefile中含有一个dtbs编译target项目。

4..dtb是.dts被DTC编译后的二进制格式的Device Tree描述，可由Linux内核解析。通常在我们为电路板制作NAND、SD启动image时，会为.dtb文件单独留下一个很小的区域以存放之，之后bootloader在引导kernel的过程中，会先读取该.dtb到内存。

5.对于Device Tree中的结点和属性具体是如何来描述设备的硬件细节的，一般需要文档来进行讲解，文档的后缀名一般为.txt。这些文档位于内核的Documentation/devicetree/bindings目录，其下又分为很多子目录。

# 四. 设备树/驱动移植实例 #

设备树就是为驱动服务的，配置好设备树之后还需要配置相应的驱动才能检测配置是否正确。比如dm9000网卡，就需要首先将示例信息挂接到我们的板级设备树上，并根据芯片手册和电路原理图将相应的属性进行配置，再配置相应的驱动。需要注意的是，dm9000的地址线一般是接在片选线上的，所以设备树中就应该归属与相应片选线节点，我这里用的exynos4412，接在了bank1，所以是**"<0x50000000 0x2 0x50000004 0x2>"**  
最终的配置结果是：

![format_png 16][]

勾选相应的选项将dm9000的驱动编译进内核。

make menuconfig
    [*] Networking support  --->
    	Networking options  --->
    		<*> Packet socket
    		<*>Unix domain sockets 
    		[*] TCP/IP networking
    		[*]   IP: kernel level autoconfiguration
    Device Drivers  --->
    	[*] Network device support  --->
    		[*]   Ethernet driver support (NEW)  --->
    			<*>   DM9000 support
    File systems  --->
    	[*] Network File Systems (NEW)  --->
    		<*>   NFS client support
    		[*]     NFS client support for NFS version 3
    		[*]       NFS client support for the NFSv3 ACL protocol extension
    		[*]   Root file system on NFS

执行`make uImage;make dtbs`,tftp下载，成功加载nfs根文件系统并进入系统，表示网卡移植成功  
![format_png 17][]

参考文献：

*  [Linux设备树语法详解][Linux]
 *  [初识linux设备树 ][linux_]
 *  [Device Tree机制][Device Tree]
 *  [Linux设备树(1)——先前总结][Linux_1]
 *  [Linux设备树(2)——设备树格式和使用][Linux_2]
 *  [Linux设备树(3)——Linux内核对设备树的处理][Linux_3_Linux]
 *  [Linux设备树详解(一) 基础知识][Linux_]
 *  [Linux设备树详解(二)文件构成][Linux 1]
 *  [Linux设备树详解(三)u-boot设备树的传递][Linux_u-boot]
 *  [Linux设备树详解(四)kernel的解析][Linux_kernel]
 *  [Linux设备树详解(五)设备树的使用][Linux 2]
 *  [Linux设备驱动程序学习（十六）——Linux设备树解析][Linux_Linux]
 *  [【Device Tree】设备树(一)——GPIO][Device Tree_GPIO]

[format_png]: /images/20230312/4f2a2321a0bd4e93a1097aad6dfd1395.png
[format_png 1]: /images/20230312/61b0fd69f7744b60b55b99335de1efbf.png
[format_png 2]: /images/20230312/a97e25fd87f7499dab048b7117d2e639.png
[format_png 3]: /images/20230312/8727354a17df40f98adaa0df60cea853.png
[format_png 4]: /images/20230312/6875d587839d4a159a4c7ae8f7030d42.png
[format_png 5]: /images/20230312/0c3fbc42661b4ad6a5177a08d324f8fe.png
[format_png 6]: /images/20230312/14aa1e8842a24e57bd1a78277731894c.png
[format_png 7]: /images/20230312/725c199e359248b99f0d05767f95f059.png
[format_png 8]: /images/20230312/a6179b37927e4c0b8714b8e2ac47532f.png
[format_png 9]: /images/20230312/364329f03dbc4378bbbf50412ec86b9a.png
[format_png 10]: /images/20230312/efaf0036385846af806e9e96ae955e38.png
[format_png 11]: /images/20230312/54ffb6935d134c4193f19b7408365569.png
[format_png 12]: /images/20230312/07fff12c14b64927890abbdc9f1cc05c.png
[format_png 13]: /images/20230312/86bc410a02334e1facf42887a6b08c07.png
[format_png 14]: /images/20230312/91aaf03b61d64b408b6857eae23f0c5c.png
[format_png 15]: /images/20230312/a2c6cc73b035462e9882d8a66efa1324.png
[format_png 16]: /images/20230312/d34ce7b114954c47a8468a6f1c9fc4dd.png
[format_png 17]: /images/20230312/ee584bcdfbde422fa65ed6ccc9a5a4b8.png
[Linux]: https://www.cnblogs.com/xiaojiang1025/p/6131381.html
[linux_]: https://www.sohu.com/a/304095747_516434
[Device Tree]: https://www.cnblogs.com/aaronLinux/p/5496559.html#t8
[Linux_1]: https://www.cnblogs.com/hellokitty2/p/7406181.html
[Linux_2]: https://www.cnblogs.com/hellokitty2/p/10992949.html
[Linux_3_Linux]: https://www.cnblogs.com/hellokitty2/p/10999432.html
[Linux_]: https://blog.csdn.net/u012489236/article/details/97137007
[Linux 1]: https://blog.csdn.net/u012489236/article/details/97249706
[Linux_u-boot]: https://blog.csdn.net/u012489236/article/details/97256928
[Linux_kernel]: https://blog.csdn.net/u012489236/article/details/97271797
[Linux 2]: https://blog.csdn.net/u012489236/article/details/97395748
[Linux_Linux]: https://blog.csdn.net/baidu_38661691/article/details/97013406?utm_medium=distribute.pc_relevant_right.none-task-blog-BlogCommendFromMachineLearnPai2-3.nonecase&depth_1-utm_source=distribute.pc_relevant_right.none-task-blog-BlogCommendFromMachineLearnPai2-3.nonecase
[Device Tree_GPIO]: https://blog.csdn.net/qq_38131812/article/details/88956752?utm_medium=distribute.pc_relevant_right.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase&depth_1-utm_source=distribute.pc_relevant_right.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase