Linux dts 设备树详解(一) 基础知识
Linux dts 设备树详解(二) 动手编写设备树dts
文章目录
1 前言
关于设备树,之前就已经接触过许久了,但是本着够用的原则,基本上是哪里不会点哪里,现学现卖,没有再进行全面性的总结,导致很多知识点都是比较碎片状,没有形成一个系统的知识网络,于是乎,决定挪用一部分打篮球的时间,整理一下这方面的思路,毕竟温故知新,感觉会收获良多。
2 概念
2.1 什么是设备树 dts(device tree)?
设备树(Device Tree)是描述计算机的特定硬件设备信息的数据结构,以便于操作系统的内核可以管理和使用这些硬件,包括CPU或CPU,内存,总线和其他一些外设。
设备树是通过Open Firmware
项目从基于SPARC的工作站和服务器派生而来的。当前的Devicetree一般针对嵌入式系统,但仍然与某些服务器级系统一起使用(例如,Power Architecture Platform Reference所描述的系统)。
然而x86架构
的个人计算机通常不使用设备树,而是依靠各种自动配置协议来识别硬件。使用设备树的系统通常将静态设备树(可能存储在ROM中)传递给操作系统,但也可以在引导的早期阶段生成设备树。例如,U-Boot和kexec可以在启动新操作系统时传递设备树。一些系统使用的引导加载程序可能不支持设备树,但是可以与操作系统一起安装静态设备树,Linux内核支持这种方法。
Device Tree规范目前由名为devicetree.org
的社区管理,该社区与Linaro和Arm等相关联。
2.2 使用设备树的优势有哪些?
Linux内核从3.x版本之后开始支持使用设备树,这样做的意义重大,可以实现驱动代码与设备的硬件信息相互的隔离,减少了代码中的耦合性,在此之前,一些与硬件设备相关的具体信息都要写在驱动代码中,如果外设发生相应的变化,那么驱动代码就需要改动。但是在引入了设备树之后,这种尴尬的情况找到了解决的办法,通过设备树对硬件信息的抽象,驱动代码只要负责处理逻辑,而关于设备的具体信息存放到设备树文件中,这样,如果只是硬件接口信息的变化而没有驱动逻辑的变化,开发者只需要修改设备树文件信息,不需要改写驱动代码。
3 简介
3.1 dts
硬件的相应信息都会写在.dts
为后缀的文件中,每一款硬件可以单独写一份xxxx.dts
,一般在Linux
源码中存在大量的dts
文件,对于arm架构可以在arch/arm/boot/dts
找到相应的dts
,另外mips
则在arch/mips/boot/dts
,powerpc
在arch/powerpc/boot/dts
。
3.2 dtsi
值得一提的是,对于一些相同的dts
配置可以抽象到dtsi
文件中,然后类似于C语言的方式可以include
到dts
文件中,对于同一个节点的设置情况,dts
中的配置会覆盖dtsi
中的配置。具体如下图所示;
3.3 dtc
dtc
是编译dts
的工具,可以在Ubuntu
系统上通过指令apt-get install device-tree-compiler
安装dtc
工具,不过在内核源码scripts/dtc
路径下已经包含了dtc
工具;
3.4 dtb
dtb(Device Tree Blob)
,dts
经过dtc
编译之后会得到dtb
文件,dtb
通过Bootloader
引导程序加载到内核。所以Bootloader
需要支持设备树才行;Kernel也需要加入设备树的支持;
4 基本框架
下图是一个设备树文件的基本架构;大概看了一下有点类似于XML
文件,简单概括一下有这几个部分;
- 根节点:
- 设备节点:
nodex
- 节点名称:图中
node
; - 节点地址:
node@0
就是节点的地址; - 子节点:
childnode
- 节点名称:图中
- 属性:属性名称(
Property name
)和属性值(Property value
) - 标签
具体如下图所示;
5 总结
本文简单的介绍了设备树的概念以及设备树dts文件的最基本的框架,通过给出的具体的例子,我们大概可以知道,一个最小的设备树文件都具备哪些属性,并且它会被如何编译,dtb
文件会被保存到ROM
中,最终通过bootbolader
被加载到内核,这样内核就可以通过解析设备树来让驱动去控制实际的硬件了。接下来,再深入到实际的硬件上去去学习一下设备树。
参考
Linux设备驱动开发详解4.0内核
petazzoni-device-tree-dummies
Kernel_Source_Documentation