Linux dts 设备树详解(一) 基础知识

Linux dts 设备树详解(一) 基础知识
 Linux dts 设备树详解(二) 动手编写设备树dts

文章目录

1 前言
2 概念

2.1 什么是设备树 dts(device tree)?
2.2 使用设备树的优势有哪些？

3 简介

3.1 dts
3.2 dtsi
3.3 dtc
3.4 dtb

4 基本框架
5 总结
参考

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被加载到内核，这样内核就可以通过解析设备树来让驱动去控制实际的硬件了。接下来，再深入到实际的硬件上去去学习一下设备树。