设备树使用简介

设备树使用简介

摘要：是不是所有的Linux内核都是完美的？毕竟诸多黑客效力于此，当然不是，至少在内核3.x版本之前不是，之前的代码臃肿，代码利用率较低，直到设备树的引入，彻底改善这一情况；

一、FDT的概念

系统启动时，Bootloader开始加载，将内核文件，如zImage读取到内存中，内核按照我们的代码，逐一去配置每个寄存器，每个外设，似乎没有什么问题。但是试想一下，100种ARM芯片，就要写100个配置文件么？当然，如果你非要这么做，我也无话可说。如果能抽象出一种数据结构，它可以直接抽象出内核需要配置的所有硬件以及硬件属性，BootLoader预读取到内存中，在内核启动以后，可以直接配置，对于用户而言，配置MCU 的外围时我们直接面对的就只是这个DTS文件，极其方便快捷。FDT准确来讲是一种数据结构，使得硬件可以用形如XML的描述语言来描述。

二、设备树结构

图一设备树结构

设备树一般包含以上内容：

根节点“/”下的model ，这个一般为字符串类型，它描述了厂商以及板子名称；

根节点“/”下的compitable，这个一般为字符串类型，用以匹配model选定的开发板对应的代码；包括后续外围驱动的匹配均是有这个compitable来完成；

根节点“/”下的aliases，这个设备节点只能放在根节点目录，主要用以存放外设的别名，简单讲，"/soc/aips-bus@02000000/spba-bus@02000000/serial@02020000"其实是一个串口，但是开发人员自己看起来并不直观，我可以在aliases中写作：serial ="/soc/aips-bus@02000000/spba-bus@02000000/serial@02020000";serial即可代替刚才的串口设备；

根节点“/”下的chosen:这个并非物理设备节点，而是内核启动参数的节点，类似于uboot阶段的bootargs参数；

当然，这个节点也可以是子节点，不一定要在根节点下；

实例：chosen {

stdout-path = &uart1;

};

snvs@020b0000:除以上节点，剩下的我一般称之为物理设备节点（可能不准确），以snvs 外设举例，直接举例；

实例：snvs@020b0000{

conpitable = “fsl,imx6ul-snvs”;

reg = <0x020b0000 0x4000>;

interrupts = <0x0 0x4 0x4>;

};

（1）“@”后面紧跟就是该外设在MCU总线的地址，这个不难理解，可以理解为外设的基地址，外设模型name@addresss;”

（2）“compitable”:如上陈述，非常关键的属性，匹配外设驱动，属性模型 compitable = “[manufacture,[model]]”;

（3）“reg”:该属性为外设地址属性，第一个参数为该节点总线地址，后者为地址长度；（4）“interrupt”:顾名思义，该外设的中断，para1表示该中断是不是SPI中断（shared peripheral interrupt），注意名词区分，参数值为1表示为SPI中断，反之不是SPI中断；para2是该中断号；para3表示触发方式，参数值为1，表示上升沿触发，为4表示高电平触发；如果需要低电平以及下降沿触发，硬件需要加非门；

三、编译设备树与反编译

设备树编译，我们都知道使用如下命令编译：

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- dtbs 或者

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- all

实际上，是dtc这个文件在负责把dts解释成dtb文件，该文件在内核源码根目录 ./scripts/dtc

编译命令：

./scripts/dtc/dtc –I dts –O dtb /home/gyh/tmp/imx6y2c-256m.dtb ./arch/arm/boot/dts/imx6y2c-256m.dts 反编译命令：

./scripts/dtc/dtc -I dtb -O dts -o /home/gyh/tmp/imx6y2c_asm.dts ./arch/arm/boot/dts/imx6y2c-256m.dtb 对于Linux命令的使用，可以使用help cmdname 或者man cmdname，对于dtc，非内建命令，man dtc:

-I

Input formats are:

dts - device tree source text

dtb - device tree blob

fs - /proc/device-tree style directory

-O

Output formats are:

dts - device tree source text

dtb - device tree blob

asm - assembler source

系统提供的dts一般引用dtsi这个母设备树，所以大量外设都是直接引用dtsi中的，因此很难理解这些字符串是怎样的匹配驱动程序的，但是一旦将已经生产的dtb文件反编译，生产

的dts文件将更直观；但是易读性也更差。这并不矛盾；我选择，” /” ,”chosen” ,”aliases”三个节点来对比。

图二BSP提供的dts文件

图三反编译的dts文件

对同一个chosen节点：BSP中dts描述为stdout-path = &uart1;这样很难想象它是怎样把该外设定义为标准输出的，但是如果看反编译文件可以较好的理解，标准输出被重定向到某个可以作为输出的外设地址；

四、设备树节点添加与验证

（1）直接在dts文件中查找，是否已经存在你需要的外设节点；如果有，且该外设支持多从机或者多节点，直接在该节点下面，添加子节点，以GPIO_LED为例。

图四GPIO_LEDS节点

（2）假设，你需要添加一个黄色的LED，那么仿照已经存在的节点，复制一个节点在母节点下，命名为green-led,同时用GPIO3_4为该LED驱动引脚；你希望在arm板上叫他，My_Cute （这个名字不好），那么最后修改如下：

图五增加yellow-led节点

（3）节点添加完成，引用了GPIO3_4，所以你需要确认该MCU引脚已经配置为GPIO功能，这里直接贴出配置代码：MX6UL_PAD_LCD_RESET__GPIO3_IO04 0x40017059