【i.MX6ULL】驱动开发5——设备树原理与点亮LED
1 什么是设备树
1.1 背景介绍
Linux3.x之前是没有设备树的，设备树是用来描述一个硬件平台的板级细节。对应ARM-Linux开发，这些板级描述文件存放在linux内核的 /arch/arm/plat-xxx和/arch/arm/mach-xxx 中。随着ARM硬件设备的种类增多，与板子相关的设备文件也越来越多，这就导致Linux内核越来越大，而实际这些ARM硬件相关的板级信息与Linux内核并无相关关系。
2011年，Linux之父Linus Torvalds发现这个问题后，就通过邮件向ARM-Linux开发社区发了一封邮件，不禁的发出了一句“This whole ARM thing is a f*cking pain in the ass”。之后，ARM社区就引入了PowerPC等架构已经采用的设备树(Flattened Device Tree)机制，将板级信息内容都从Linux内核中分离开来，用一个专属的文件格式来描述，即现在的.dts文件。
1.2 设备树介绍
设备树的作用就是描述硬件平台的硬件资源。它可以被bootloader传递到内核，内核可以从设备树中获取硬件信息。
设备树描述硬件资源时有两个特点：
以树状结构描述硬件资源。以系统总线为树的主干，挂载到系统地总线的IIC控制器、SPI控制器等为树的枝干，IIC控制器下的IIC设备资源，又可以再分IIC1和IIC2，而IIC1上又可以连接MPU6050这类的IIC器件...
可以像头文件那样，一个设备树文件引用另外一个设备树文件，实现代码重用。例如多个硬件平台都使用i.MX6ULL作为主控芯片，可以将 i.MX6ULL 芯片的硬件资源写到一个单独的设备树文件中(.dtsi文件)。
1.3 DTS、DTSI、DTB、DTC
DTS ，Device Tree Source，是设备树源码文件
DTSI ，Device Tree Source Include，是设备树源码文件要用到的头文件
DTB ，Device Tree Binary，是将DTS 编译以后得到的二进制文件
DTC ，Device Tree Compiler，是将.dts 编译为.dtb需要用到的编译工具
DTC工具源码在Linux内核的scripts/dtc目录下，scripts/dtc/文件夹下Makefile的内容为：
可以看出，DTC工具依赖于dtc.c、flattree.c、fstree.c等文件，最终编译并链接出DTC这个主机文件
2 设备树框架与DTS语法
2.1 设备树代码分析
在学习设备树时，可以先看一下NXP关于i.MX6ULL已有的设备树文件，来大致了解一下设备树文件是什么样子的。
2.1.1 imx6ull-14x14-evk-emmc.dts
下面是/arch/arm/boot/dts/imx6ull-14x14-evk-emmc.dts
该文件就这几行，描述了emmc版本板子的usdhc信息。该文件的主要的功能是通过头文件的形式包含了另一个imx6ull-14x14-evk.dts设备树文件。
DTS语法：设备树是可以使用“#include”引用其它文件（.dts、.h、.dtsi）。
2.1.2 imx6ull-14x14-evk.dts
下面是/arch/arm/boot/dts/imx6ull-14x14-evk.dts
该文件也是先包含一些头文件，然后是一个斜杠+一些大括号，后面还出现了&符号。
DTS语法：
/ {⋯}斜杠+大括号，表示根节点，一个设备只有一个根节点（注：一个dts包含另一个dts，两个文件里的根节点，其实也是同一个根节点）
xxx {⋯}根节点内部单独的大括号，表示子节点，如reserved-memory {...}、pxp_v4l2 {...}等
&xxx {⋯}根节点外部单独的&符号与大括号，表示节点的追加内容，如&cpu0 {...}等
2.1.3 imx6ull.dtsi
该文件是设备树的头文件，其格式与设备树基本相同。
DTS语法：节点标签
节点名“cpu”前面多了个“cpu0”, 这个“cpu0”就是我们所说的节点标签。通常节点标签是节点名的简写，它的作用是当其它位置需要引用时可以使用节点标签来向该节点中追加内容。
2.2 设备节点基本格式
设备树是采用树形结构来描述板子上的设备信息的文件，每个设备都是一个节点，叫做设备节点，每个节点都通过一些属性信息来描述节点信息，属性就是键-值对。
2.2.1 节点名称
node-name用于指定节点名称，其长度为1~31个字符：
数字：
0~9字母：
a~zA~Z英文符号：
,._+-
节点名应使用字母开头，并能描述设备类别（根节点用斜杠表示，不需要节点名）
2.2.2 单元地址
@unit-address用于指定单元地址，其中@符号表示一个分隔符，unit-address是实际的单元地址，它的值要和节点reg属性的第一个地址一致，如果没有reg属性值，则可以省略单元地址。
2.2.3 节点属性
在节点的大括号“{}”中包含的内容是节点属性， 一个节点可以包含多个属性信息，例如根节点的属性model = "Freescale i.MX6 ULL 14x14 EVK Board"，编写设备树最主要的内容是编写节点的节点属性。属性包括自定义属性和标准属性，下面来看几个标准属性：
model属性：用于指定设备的制造商和型号，多个字符串使用“,”分隔开
compatible 属性：由一个或多个字符串组成，是用来查找节点的方法之一
status属性：用于指示设备的“操作状态” ，通过status可以禁用或启用设备
reg属性：描述设备资源在其父总线定义的地址空间内的地址，通常情况下用于表示一块寄存器的起始地址（偏移地址）和长度
#address-cells 和 #size-cells：这两个属性同时存在，在设备树ocrams结构中，用在有子节点的设备节点，用于设置子节的“reg”属性的“书写格式”
ranges属性：它是一个地址映射/转换表，由子地址、父地址和地址空间长度这三部分组成：
child-bus-address： 子总线地址空间的物理地址， 由父节点的#address-cells 确定此物理地址所占用的字长
parent-bus-address：父总线地址空间的物理地址，同样由父节点的#address-cells 确定此物理地址所占用的字长
length：子地址空间的长度，由父节点的#size-cells 确定此地址长度所占用的字长
2.2.4 特殊节点
aliases子节点：其作用是为其他节点起一个别名，例如：
chosen子节点：该节点位于根节点下，它不代表实际硬件， 它主要用于给内核传递参数，例如：
表示系统标准输出 stdout 使用串口 uart1。
3 设备树编程之OF函数
内核提供了一系列函数用于从设备节点获取设备节点中定义的属性，这些函数以 of_ 开头，称为OF函数。在编写设备树版的LED驱动时，在进行硬件配置方面，就是要用这些OF函数，将寄存器地址等信息从设备树文件中获取出来，然后进行GPIO配置。
先来列举一下这些函数：
3.1 查找节点的OF函数
of_find_node_by_name
通过节点名字查找指定的节点
of_find_node_by_type
通过device_type属性查找指定的节点
of_find_compatible_node
根据device_type和compatible这两个属性查找指定的节点
of_find_matching_node_and_match
通过of_device_id匹配表来查找指定的节点
of_find_node_by_path
通过路径来查找指定的节点
3.2 查找父/子节点的OF函数
of_get_parent
用于查找父节点
of_get_next_child
用迭代的方式查找子节点
3.3 提取属性值的OF函数
of_find_property
查找指定的属性
of_property_count_elems_of_size
用于获取属性中元素的数量
of_property_read_u32_index
用于从属性中获取指定标号的u32类型数据值
of_property_read_u8_array
用于读取属性中 u8类型的数组数据（类似的函数还有u16、u32 和 u64）
of_property_read_u8
用于读取只有一个整形值的属性（类似的函数还有u16、u32 和 u64）
of_property_read_string
用于读取属性中字符串值
of_n_addr_cells
用于获取#address-cells 属性值
of_n_size_cells
用于获取#size-cells 属性值
3.4 其他常用的OF函数
of_device_is_compatible
用于查看节点的compatible属性是否有包含compat指定的字符串，也就是检查设备节点的兼容性
of_get_address
用于获取地址相关属性
of_translate_address
用于将设备树读取到的地址转换为物理地址
of_address_to_resource
用于将reg属性值，转换为resource结构体类型
of_iomap
用于直接内存映射
4 设备树LED驱动程序与实验
回忆之前的LED字符设备驱动的编写方法：直接在驱动文件regled.c中定义有关寄存器物理地址，然后使用io_remap函数进行内存映射得到对应的虚拟地址，最后操作寄存器对应的虚拟地址完成对GPIO的初始化。
使用设备树编写字符设备驱动，主要的一点区别是：使用设备树向Linux内核传递相关的寄存器物理地址，Linux驱动文件使用OF函数从设备树中获取所需的属性值，然后使用获取到的属性值来初始化相关的IO，所以，其本质还是配置寄存器。
所以，使用设备树进行LED驱动，需要的修改主要为：
修改imx6ull-myboard.dts设备树文件，在其中添加RGB-LED的设备节点
编写RGB-LED驱动程序，获取设备树中的相关属性值，并使用相关的属性值进行GPIO的初始化
编写RGB-LED应用程序，控制RGB-LED的亮灭
4.1 修改设备树文件
编译设备树，在内核源码的根目录下（我的是~/myTest/imx6ull/kernel/nxp_kernel/linux-imx-rel_imx_4.1.15_2.1.0_ga），执行如下make命令即可单独编译自己修改的设备树：
4.2 测试设备树
4.2.1 测试环境切换
由于这次是修改了设备树文件，而我的板子已经烧录了固件到emmc，因此，这次实验，重新将板子设为从SD卡启动uboot并从网络启动NFS文件系统的方式，方便修改测试设备树。（板子从网络启动的方式，可参考之前的文章）,若之前SD的uboot配置还在，将板子切换到SD卡启动，并确保网络畅通，即可从网络启动。
若nfs服务器（ubuntu虚拟器）的IP发生变化，需要和之前一样进行类似如下的bootargs和bootcmd配置：
注意这里的192.168.5.104是我的ubuntu的IP，192.168.5.102是板子的IP。
4.2.2 设备树修改后的效果
在测试设备树之前，可以先看一下目前板子的设备树中都有什么：
将编译后的dtb文件放到网络启动位置，比如我的是复制到这里：
然后重启板子，再次查看/proc/device-tree/目录：
可以看到，出现了新加的myboardled节点，进入myboardled目录下，可以看到其属性信息。
4.3 修改LED驱动程序
驱动程序整体框架和上一篇的寄存器版配置程序基本相同，主要的不同是修改硬件配置的方式，
上面的程序修改部分，从整个LED驱动的框架来看，修改的只是如下图中的黄色框部分：
4.4 实验测试
编译设备树版的LED驱动程序，并将编译好的ko文件发送到nfs文件系统对应的文件夹下。
LED是应用程序不需要修改，仍使用上一篇文章中的程序即可。
测试方法与之前基本相同：
使用设备树的方式，再次点亮LED:
5 总结
本篇介绍了设备树的基本原理以及设备树的使用方法，在上一篇点亮LED的代码基础上，通过设备树的方式，实现了LED点灯，总结一下主要的修改就是先在设备树中添加LED节点，然后在驱动文件中通过OF函数来读取设备树中的寄存器信息，再进行GPIO的初始化，其它部分的程序与上一篇的基本一样。
