设备树概述

BSP：板级支持包

对于一个给定的嵌入式平台，如ARM平台，他们的硬件电路的资源是不尽相同的，要在各种不同的ARM板子上都要跑一个给定的operating system（os),如linux。板级支持包（BSP）是介于主板硬件和操作系统中驱动层程序之间的一层，主要是实现对操作系统的支持，为上层的驱动程序提供访问硬件设备寄存器的函数包，使之能够更好的运行于硬件主板

BSP是相对于操作系统而言的，不同的操作系统对应于不同定义形式的BSP，例如VxWorks的BSP和Linux的BSP相对于某一CPU来说尽管实现的功能一样，可是写法和接口定义是完全不同的，所以写BSP一定要按照该系统BSP的定义形式来写（BSP的编程过程大多数是在某一个成型的BSP模板上进行修改）。这样才能与上层OS保持正确的接口，良好的支持上层OS。
通常BSP包是由开发板的公司提供的，它一般包含有一个底层的bootloader,如Das U-Boot，里面实现了少量的设备驱动，如串口，网络等等，用以在加载kernel时用到。它还包括给kernel用的所有的板上设备的驱动程序。有一些供应商BSP甚至还提供了root file system、一个完整的tool chain，用以开发程序、用于系统在运行时的系统配置程序。

（摘自(22条消息) 什么是BSP_alada007的博客-CSDN博客_bsp是什么）

linux设备树：

操作系统一直在不断的更新和发展，而在Linux驱动的架构上面也是不断的进步和完善。早期的Linux内核和ARM架构中并没有采用设备树。

早期描述板级信息的做法：

在没有设备树的时候Linux是通过大量的arch/arm/mach-xxx 和arch/arm/plat-xxx文件夹来描述对应平台的板级信息。

淘汰原因：

而随着智能终端设备，智能手机的发展，每年新出的ARM架构芯片都有数百款，从而导致Linux内核中的板机信息文件过多，使得Linux内核虚胖。当 Linux之父 linus看到 ARM社区向 社区向 Linux内核添加了大量“无用”、冗余的板级信息文件，不禁发出了一句“ This whole ARM thing is a f*cking pain in the ass”。从此以后 ARM社区就引入了PowerPC等架构已经采用的设备树(Flattened Device Tree),

设备树：

设备树将这些描述板机硬件信息的内容都从Linux中分离出来，用一个专属的文件格式来描述，这个专属的文件就叫做设备树。 这个用这个通用的文件就是.dtsi文件，类似于C语言中的头文件。一般用.dts描述板机信息（也就是开发板上有多少个IIC设备、SPI设备等），dtsi描述SOC级信息（也就是SOC有几个CPU、主频是多少、多少个外设控制寄存器信息等）。

描述设备设备树的文件叫做DTS(Device Tree Source),这个DTS文件采用了树形结构来描述板机设备，也就是开发板信息，比如CPU数量、内存基地址、IIC接口上接了那些设备、SPI接口上接了那些设备等。

DTS、DTB和DTC

设备树源文件扩展名为.dts， 之前我跟着正点原子的教程时一直使用的是.dtb文件，这两个文件的关系是什么呢？其实DTS是设备树源码文件，DTB是将DTS编译以后得到的一个二进制文件。在Linux中将.c文件编译成.o文件需要用到gcc编译器，那么将 ** .dts编译为.dtb需要用到的工具就是DTC工具**！而这个.dtb文件就是UBOOT通过bootz或者bootm命令向Linux内核中传递的二进制设备树文件(.dtb））。
 

DTS语法

可以尝试着学习一下，在工作可能修改SOC原厂提供的.dts文件上进行修改。DTS其实是一种ASCII文本文件，不论是阅读还是修改都相对比较方便。

.dtsi头文件

和C语言一样，设备树也支持头文件，设备树的头文件扩展名为.dtsi。.dtsi文件中可以直接通过include来引用.h、.dtsi、.dts。一般的.dtsi用于描述SOC的内部外设信息，比如CPU架构、主频、外设寄存器地址范围，比如UART、IIC等等。

设备节点

 设备树采用树形结构来描述板子上的设备信息的文件，每一个设备都是一个节点，叫做设备节点，每个节点都是通过一些属性信息来描述节点信息，属性就是键值对。以下是借鉴正点原子驱动开发手册的从imx6ull.dtsi文件中缩减出来的设备树文件内容：

/ {
	aliases {
		can0 = &flexcan1; 
	}; 
	 cpus {
	  	#address-cells = <1>; 
	  	#size-cells = <0>;  
	  	cpu0: cpu@0 { 
		  	compatible = "arm,cortex-a7"; 
		  	device_type = "cpu"; 
		  	reg = <0>; 
	  	}; 
	}; 
	intc: interrupt-controller@00a01000 { 
		compatible = "arm,cortex-a7-gic"; 
		#interrupt-cells = <3>; 
		interrupt-controller; 
		reg = <0x00a01000 0x1000>, 
		<0x00a02000 0x100>; 
	}; 
} 

1.

/是根节点，每个设备树文件只有一个根节点，如果工程中有两个或者多个文件都有一个/根节点，那么这些文件中的根节点的内容会合并成一个根节点。
2.

aliases、cpus和intc是三个子节点，在设备树中节点命名格式为node-name@unit-address
2.1

node-name是节点的名字，为ASCII字符串，节点名字应该能够清晰的辨别出节点的功能，比如uart1就表示这个节点是UART1外设。unit-address一般表示设备的地址或寄存器首地址，如果某个节点没有地址或者寄存器的话unit-address可以不要，比如cpu@0、interrupt-controller@00a01000
2.2

cpu0:cpu@0并不是node-name@unit-address这样的格式，而是用：隔开成了两部分，：前面是节点标签，：后面是节点名字，格式为lable:node-name@unit-address，引入label的目的就是为了方便访问节点，可以直接通过&label来访问这个节点，比如通过&cpu0就可以访问cpu@0这个节点，而不需要输入完整的节点名字。
3.

上述代码中的cpu0也是一个节点，只是cpu0是cpus的子节点。每个节点都有不同的属性，不同的属性又有不同的内容，属性都是键值对，值可以为空或任意的字节流。

 设备树中常用的几种数据形式如下所示：

标准属性：

 节点是由一堆属性组成，节点都是具体的设备,不同的设备需要的属性不同，用户可以自定义属性。除了用户自定义的属性，有很多属性是标准属性，Linux下的很多外设驱动都会使用这些标准属性。

1）compatible属性
        compatible属性也叫做“兼容性”属性，这是一个非常重要的属性！compatible属性的值是一个字符串列表，compatibel属性用于将设备和驱动绑定起来。字符串列表用于选择设备所要使用的驱动程序，compatible属性格式如下：
 

"manufacturer,model"
 其中的manufacturer表示厂商，model一般是模块对应驱动的名字。

I.MX6U-ALPHA开发板上的音频芯片采用的欧圣出品的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匹配表中的任何一个值相等，那么就表示设备可以使用这个驱动。

2）model属性

 model属性值也就是一个字符串，一般model属性描述设备模块信息，比如名字什么的，比如：

model=”wm8960-audio";

3）status属性

   status属性看名字就知道是和设备状态有关的，status属性值也是字符串，字符串是设备的状态信息，可以选择的状态如表所示：

4）#address-cells和#size-cells属性

这两个属性都是无符号32位整型，#address-cells和#size-cells这两个属性可以用在任何拥有子节点的设备中，用于描述子节点的地址信息。

#address-cells属性决定了子节点reg属性中地址信息所占用的字长（32位）， #size-cells属性值决定了子节点应该如何编写reg属性值，一般reg属性都是和地址有关的内容，和地址相关的信息有两种：起始地址和地址长度，reg属性的格式为：reg = <address1 length1 address2 length2 address3 length3…… >
       每个address length组合表示一个地址范围，其中address是起始地址，length是地址长度，#address-cells：表明address这个数据所占用的字长

#size-cells：表明length这个数据所占用的字长
例如：

spi4 { 
	compatible = "spi-gpio"; 
	#address-cells = <1>; #说明了spi4的子节点reg属性中起始地址所占用的字长为1
	#size-cells = <0>; #地址长度所占用的字长为0
	gpio_spi: gpio_spi@0 { #reg属性值为0，因为父节点中设置了相关的值，继承父节点起始地址，没有设置地址长度
		compatible = "fairchild,74hc595"; 
		reg = <0>; 
	}; 
 }; 
aips3: aips-bus@02200000 { 
	compatible = "fsl,aips-bus", "simple-bus"; 
	#address-cells = <1>; 
	#size-cells = <1>; 
	dcp: dcp@02280000 { 
		compatible = "fsl,imx6sl-dcp"; 
		reg = <0x02280000 0x4000>; #address=0X02280000，length=0X4000
	 }; 
};

5）reg属性
       reg属性值一般是（address,length）。一般用于描述设备地址空间资源信息，一般都是某个外设的寄存器地址范围信息

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属性值为空值，说明子地址空间和父地址空间完全相同，不需要进行地址转换。

7）name属性
       name属性值为字符串，name属性用于记录节点名字，name属性已经被弃用，不推荐使用name属性，一些老的设备树文件可能会使用此属性。

8）device_type属性
       device_type属性值为字符串，IEEE1275会用到此属性，用于描述设备的Fcode，但是设备树没有FCode，所以此属性也被抛弃了。此属性只能用于cpu节点或者memory节点。imx6ull.dtsi的CPU0节点用到了此属性，内容如下所示：

cpu0: cpu@0 { 
	compatible = "arm,cortex-a7"; 
	device_type = "cpu"; 
	reg = <0>; 
	...... 
};

根节点 compatible属性

/{
	model = "Freescale i.MX6 ULL 14x14 EVK Board"; 
	compatible = "fsl,imx6ull-14x14-evk", "fsl,imx6ull";
	......
}

可以看出根节点的compatible属性可以知道我们所使用的设备，一般第一个值描述了所使用的硬件设备名字，使用某个设备第二个值就是描述设个设备所使用的SOC，如果使用的是imx6ull这颗SOC。Linux内核会通过根节点的compoatible属性查看是否支持此设备，如果支持这个设备的话设备就会启动Linux内核。

未使用设备树的设备匹配方法

在没有使用设备树之前，uboot会向Linux内核传递一个叫machine id的值，machine id也就是设备ID，告诉Linux内核自己是一个什么设备，看看Linux内核是否支持。具体实现就是判断machine id这个参数是否与代码中的宏MACH_TYPE_XXX进行对比，看有没有相等的，如果相等的话就表示Linux内核支持这个设备，如果不支持的话那么这个设备就没法启动Linux内核。

使用设备树的设备匹配方法

当Linux内核引入设备树以后就不在使用MACHINE_START了，而是换为了DT_MACHINE_START。说明引入了设备树以后就不会根据machine id来检查Linux 内核是否支持这个设备。在Linux内核中通过start_kernel函数启动内核，然后start_kernel函数会调用setup_arch函数来匹配machine_desc，然后再调用setup_machine_fdt函数进一步获取匹配的machine_desc，这个函数的参数就是atags的首地址（也就是uboot传递给Linux内核的dtb文件首地址），setup_machine_fdt函数返回值就是找到的最匹配的machine_desc。然后通过of_get_flat_dt_root获取设备树的根节点。

————————————————
版权声明：本文为CSDN博主「万里羊」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_44895651/article/details/113242154