设备树使用简介
扫描二维码
随时随地手机看文章
摘要：是不是所有的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 format>
Input formats are:
dts - device tree source text
dtb - device tree blob
fs - /proc/device-tree style directory
-O <output format>
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
图六 引脚配置为GPIO
该宏定义MX6UL_PAD_LCD_RESET__GPIO3_IO04在./arch/arm/boot/dts/imx6ull-pinfunc.h中；针对同一个引脚的全部复用，均定义了宏，可以直接调用；该dts并未直接包含imx6ull-pinfunc.h，在其他dtsi中已经包含该头文件；
（4）如果之前已经完全编译过内核，可以直接编译dtb，注意不要make menuconfig或者defconfig，否则会覆盖zImage的配置文件.config；
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- dtbs
（5）编译完成后，开发板直接进入uboot模式，tftp网络烧写dtb，reset重启生效；
run updtb
（备注：updtb为组合命令updtb=if tftp ${fdt_file}; then nand erase.part dtb; nand write ${loadaddr} dtb ${filesize}; fi;）
（6）如果dtb按照我们理解修改是正确的，那么我们将在开发板的/sys/class/leds下面看到我们的My_Cute这个LED节点；结果如下：
图七 开发板设备截图
其实，可以看到/sys/class/leds下面的设备节点都是指向/devices/platfome/leds目录的连接文件，也就是这里仅仅是这个设备的“快捷方式”，我们也可以进行文件IO操作；
（7）文件IO操作：打开My_Cute节点，可以看到以下接口可以操作，但是我们在添加GPIO_LEDS并没有添加这些属性。Brightness, trigger—led亮度以及触发方式比较常用，那么问题来了，为什么会有这些接口。因为它们继承了母节点的属性，所以我们需要找到母节点设备的定义。
图八 yellow-led的操作接口
（8）讲道理，所有的内核驱动你都可以尝试在 ./driver/下面去找，针对led类，我们直接进入leds文件夹，发现leds的驱动leds-gpio.c在，在这里就可以理解led的接口为什么是这样；当然优秀的驱动应该还有一份清晰的文档，你同样可也尝试去源码根目录的. /Documentation 中查找leds-gpio的使用文档；这里也会解释，我为什么会去开发板的/sys/class/leds下面去查看我增加的My_Cute节点；
图九 驱动使用文档
（9）增加一个驱动或者一个设备节点到设备树中，你可以先查看内核源码的/ Documentation目录，其中包含了几乎所有驱动的使用说明以及设备树属性的解释，同时也包括大量优秀的内核调试技巧；再去写节点，也可以先模仿，针对不懂的地方再来看文档，印象更为深刻。
五、结语
设备树相比于传统的配置文件，无疑是降低了Linux外设开发与使用的门槛，但是也隐藏了大量的细节，难以了解其底层的驱动原理；对于LINUX内核的了解，我所认识的还不及冰山一角，单希望对你有一点帮助。
下载文档
