在探索Linux的庞大和复杂世界时🌌，我们经常会遇到许多关键概念和工具🛠️，它们使得Linux成为了一个强大和灵活的操作系统💪。其中，"设备树"（Device Tree）是一个不可或缺的部分🌲，尤其是在嵌入式系统🖥️和多平台硬件支持方面🔌。让我们深入了解Linux设备树是什么，它的起源，以及为什么Linux需要它🌳。
设备树(Device Tree)，将这个词分开就是“设备”和“树”，描述设备树的文件叫做 DTS(DeviceTree Source)，这个 DTS 文件采用树形结构描述板级设备，也就是开发板上的设备信息，比如CPU 数量、 内存基地址、IIC 接口上接了哪些设备、SPI 接口上接了哪些设备等等。
设备树(Device Tree),将这个词分开就是“设备”和“树”，描述设备设备树的文件叫做DTS(Device Tree Source),这个DTS文件采用了树形结构来描述板机设备，也就是开发板信息，比如CPU数量、内存基地址、IIC接口上接了那些设备、SPI接口上接了那些设备等。如最开始的图片所示！ 在图片中，树的主干就是系统总线，IIC控制器、SPI控制器等都是接到系统主线的分支上的。通过DTS这个文件描述设备信息是有相关的语法规则的，并且在Linux内核中只有3.x版本以后的才支持设备树。
在platform_device部分有简单说明描述设备有两种方法：一种是使用platform_device结构体来指定；另一种是使用设备树来描述。
设备树是一种数据结构，它通过特有的语法格式描述片上片外的设备信息。由BootLoader传递给kernel，kernel进行解析后形成和驱动程序关联的dev结构供驱动代码使用。
Linux内核从3.x开始引入设备树的概念，用于实现驱动代码与设备信息相分离。在设备树出现以前，所有关于设备的具体信息都要写在驱动里，一旦外围设备变化，驱动代码就要重写。引入了设备树之后，驱动代码只负责处理驱动的逻辑，而关于设备的具体信息存放到设备树文件中，这样，如果只是硬件接口信息的变化而没有驱动逻辑的变化，驱动开发者只需要修改设备树文件信息，不需要改写驱动代码。比如在ARM Linux内，一个.dts(device tree source)文件对应一个ARM的machine，一般放置在内核的"arch/arm/boot/dts/"目录内，比如exynos4412参考板的板级设备树文件就是"arch/arm/boot/dts/exynos4412-origen.dts"。这个文件可以通过$make dtbs命令编译成二进制的.dtb文件供内核驱动使用。
上篇文章（【i.MX6ULL】驱动开发4--点亮LED(寄存器版)）介绍了在驱动程序中，直接操作寄存器了点亮LED。本篇，介绍另外一种点亮LED的方式——设备树，该方式的本质也是操作寄存器，只是寄存器的相关信息放在了设备树中，配置寄存器时需要使用OF函数从设备树中读取处寄存器数据后再进行配置。
设备树源 (DTS，device tree source) 格式是设备树的文本表示形式。设备树编译器 (DTC) 可将这种格式处理为二进制设备树，这是 Linux 内核要求的形式。
上一篇文章学习了字符设备的注册，操作过的小伙伴都知道上一篇文章中测试驱动时是通过手动创建设备节点的，现在开始学习怎么自动挂载设备节点和设备树信息的获取，这篇文章中的源码将会是我以后编写字符驱动的模板。
参考地址 http://blog.csdn.net/green1900/article/details/45646095 http://www.cnblogs.com/xiaojiang1025/p/6131381.html http://blog.csdn.net/21cnbao/article/details/8457546
在现在的linux内核中都采用设备树来管理资源分配和模块装载，减少依赖性，在树莓派的内核系统中也是这样，设备树其实就是硬件资源的描述文件，代表硬件配置的节点，每一个节点又可以包括子节点和属性。设备树文件一般都是以.dts为后缀的文本文件，即我们常说的DTS(Device TreeSource), 语法有点像C语言，但还是有区别的，要注意。如下面的文件就是一个DTS文件 /dts-v1/; /include/ "common.dtsi"; / { node1 { a-string-
Linux内核从3.x开始引入设备树的概念，用于实现驱动代码与设备信息相分离。在设备树出现以前，所有关于设备的具体信息都要写在驱动里，一旦外围设备变化，驱动代码就要重写。
本文基于Linux kernel 5.15版本进行说明，旨在解析Linux设备树覆盖（Device Tree Overlay, DTO）的工作原理及其应用场景。
在之前使用 S3C2440 开发板移植 Linux 3.4.2 内核时，修改了很多关于 c 文件去适配开发板，和开发板相关的文件放在arch/arm/mxch-xxx目录下，因此 linux 内核 arm 架构下添加了很多开发板的适配文件：
今天和大家分享的依然是设备树，上一节里主要是介绍了设备树文件的基本格式、语法规则等，今天介绍一下如何使用设备树，以及如何动态加载设备树。
在Linux 2.6中， ARM架构的板极硬件细节过多地被硬编码在arch/arm/plat-xxx和arch/arm/mach-xxx中，采用设备树后，许多硬件的细节可以直接通过它传递给Linux，而不再需要在内核中进行大量的冗余编码。
内核Documentation\devicetree\bindings\interrupt-controller\interrupts.txt
上面介绍的编译模块是和内核一起编译的，这种编译方式比较耗时。在Linux3.x 以后的版本才引入了设备树，有了设备树之后，只需要一次编译内核，编译内核的时候会生成的dtc 工具，利用dtc工具就可以完成驱动的编译。我们这里只是简单介绍如何编译设备树、加载设备树，关于设备树，后面会有更加详细的解释。
A：设备号是用来标识设备的关键信息，主设备号用于标识设备的类型，次设备号用于区分同类型的不同设备。
我们需要编写设备树文件 (dts: device tree source) ，它需要编译为 dtb(device tree blob) 文件，内核使用的是 dtb 文件。
上一节说过设备树的出现是为了解决内核中大量的板级文件代码，通过 DTS 可以像应用程序里的 XML 语言一样很方便的对硬件信息进行配置。关于设备树的出现其实在 2005 年时候就已经在 PowerPC Linux 里出现了，由于 DTS 的方便性，慢慢地被广泛应用到 ARM、MIPS、X86 等架构上。为了理解设备树的出现的好处，先来看下在使用设备树之前是采用什么方式的。
Dts：DTS即Device Tree Source，是一个文本形式的文件，用于描述硬件信息。一般都是固定信息，无法变更，无法overlay。
在根文件系统中查看设备树，是一种不错的调试手段。因为很多时候会出现你修改了 dts 文件，并且也编译了新的 dtb，但是下载到板子上的还是以前的 dtb，因此查看板子中真实生效的设备树配置信息是很重要的。
传统的配置 pin 的方式就是直接操作相应的寄存器，但是这种配置方式比较繁琐、而且容易出问题(比如 pin 功能冲突)。pinctrl 子系统就是为了解决这个问题而引入的，pinctrl 子系统主要工作内容如下：
对于linux3.0之后，linux内核支持了设备树“这个家伙”，刚接触Device Tree的人，一开始会比较迷茫，不知道怎么用，他究竟有多强大。作者刚接触的时候也是一样，在我之前的一篇文章《linux 设备树与驱动的关系》中，将早先时候的设备模块与现在的设备树的区别进行了比较。作者在这里也说说我在学习一点小经验：
在内核源码中，存在大量对板级细节信息描述的代码。这些代码充斥在/arch/arm/plat-xxx和/arch/arm/mach-xxx目录，对内核而言这些platform设备、resource、i2c_board_info、spi_board_info以及各种硬件的platform_data绝大多数纯属垃圾冗余代码。为了解决这一问题，ARM内核版本3.x之后引入了原先在Power PC等其他体系架构已经使用的Flattened Device Tree。
今天跟大家分享的是设备树，设备树是Linux3.x以后的版本才引入的，设备树用于描述一个硬件平台的板级细节。
本篇文章主要讲解嵌入式板卡中Linux系统是如何正确测试、使用的，其中内容包含有U-Boot编译、U-Boot命令和环境变量说明、Linux内核编译、xtra驱动编译、系统信息查询、程序开机自启动说明、NFS使用说明、TFTP使用说明、TFTP + NFS的系统启动测试说明、inux设备驱动说明等，其中案例源码部分公开。
总线、设备和驱动模型，如果把它们之间的关系比喻成生活中的例子是比较容易理解的。举个例子，充电墙壁插座安静的嵌入在墙面上，无论设备是电脑还是手机，插座都能依然不动的完成它的使命——充电，没有说为了满足各种设备充电而去更换插座的。其实这就是软件工程强调的高内聚、低耦合概念。
在内核里，使用gic_chip_data结构体表示GIC，gic_chip_data里有什么？
之前发了LCD调试笔记，大家很感兴趣，所以这次再来一篇：六轴传感器ICM20608驱动移植笔记，大家还需要什么移植笔记？可以留言。我们尽量满足。
修改内核文件：drivers/video/fbdev/Makefile，把内核自带驱动程序mxsfb.c对应的那行注释掉，如下：
Linux内核下的 drivers/input/keyboard/gpio_keys.c实现了一个体系结构无关的GPIO按键驱动，使用此按键驱动，只需在设备树gpio-key节点添加需要的按键子节点即可。驱动的实现非常简单，但是较适合于实现独立式按键驱动。
很多学员有过STM32的学习经验，他们手上的开发板很多，LCD也很多。 一个LCD还挺贵的，不能浪费。 各家的LCD引脚顺序都不一样，所以别家的LCD不能直接接到100ASK_IMX6ULL开发板，需要转接板。 大部分单片机学员都是使用正点原子、野火的板子，有他们的屏。 针对这两家的屏，我们做了转接板，如下：
您可以使用设备树编译器 (DTC) 编译设备树源文件。不过，在将叠加层 DT 应用于目标主 DT 之前，您还应该通过模拟 DTO 的行为来验证结果。
最近有一些riscv的项目做，虽然以前也用过例如k210之类的riscv架构的芯片，但是都止于能够做一些应用，并未特别关注其芯片的体系架构方面的东西，但是随着接触的芯片架构的种类的逐渐的增加，发现要想使用一款好芯片的，仅仅做上层应用并不能完全发挥出特定架构芯片的全部优势。比如aarch64的el层级和虚拟化的模型，mips的mmu特性，以及sparc的窗口寄存器等等，芯片架构的特点要是能够完全的发挥出来，写起应用起来，那真是觉得很爽的事情。
NAND FLASH版本和eMMC版本核心板使用方法基本一致。本文主要描述U-Boot编译、基础设备树文件编译、固化Linux系统NAND FLASH分区说明和NAND FLASH启动系统、固化Linux系统、AND FLASH读写测试等，NAND FLASH版本与eMMC版本核心板在使用方面的不同之处，相同之处将不重复描述。
NXP官方linux仓库地址为：https://github.com/Freescale/linux-fslc/tree/5.4-2.1.x-imx。
参考文档： a. 内核 Documentation\devicetree\bindings\Pinctrl\ 目录下： Pinctrl-bindings.txt
Linux驱动程序 = 驱动程序框架 + 硬件编程。 在前面已经基于QEMU编写了LCD驱动程序，对LCD驱动程序的框架已经分析清楚。 核心就是：
Pinctrl驱动由芯片厂家的BSP工程师提供，一般的驱动工程师只需要在设备树里：
我们来看看内核是如何把设备树解析成所需的device_node。Linux最底层的初始化部分在HEAD.s中，这是汇编代码，暂且不作过多讨论。在head.s完成部分初始化之后，就开始调用C语言函数，而被调用的第一个C语言函数就是start_kernel：
默认情况下，所有接口信号引脚都配置为GPIO输入，除了引脚3和5、引脚27和28 (I2C SDA和SCL)、引脚8和10 (UART TX和RX)。
设备树 (DT, Device Tree) 是用于描述 non-discoverable(google这样写的，意思应该就是硬件信息看不到) 硬件的命名节点和属性构成的一种数据结构。操作系统（例如在 Android 中使用的 Linux 内核）会使用 DT 来支持 Android 设备使用的各种硬件配置。硬件供应商会提供自己的 DT 源文件，接下来 Linux 会将这些文件编译成引导加载程序使用的DTB（Device Tree BLOB）文件。
本文将以Myirtech的MYD-YF13X以及STM32MP135F-DK为例，讲解如何使用STM32CubeMX结合Developer package实现最小系统启动。
理想状况是：按下、松开按键，各产生一次中断，也只产生一次中断。 但是对于机械开关，它的金属弹片会反复震动。GPIO电平会反复变化，最后才稳定。一般是几十毫秒才会稳定。 如果不处理抖动的话，用户只操作一次按键，会发生多次中断，驱动程序可能会上报多个数据。
要操作GPIO引脚，先把所用引脚配置为GPIO功能，这通过Pinctrl子系统来实现。 然后就可以根据设置引脚方向(输入还是输出)、读值──获得电平状态，写值──输出高低电平。 以前我们通过寄存器来操作GPIO引脚，即使LED驱动程序，对于不同的板子它的代码也完全不同。 当BSP工程师实现了GPIO子系统后，我们就可以： a. 在设备树里指定GPIO引脚 b. 在驱动代码中： 使用GPIO子系统的标准函数获得GPIO、设置GPIO方向、读取/设置GPIO值。 这样的驱动代码，将是单板无关的。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
