1.Linux 备树文件.DTS文件格式
2.ARM处理器超频、设备树源内存超频方法——以主线内核设备树、码设主线u-boot为例
3.linux设备驱动程序——i2c总线的备树添加与实现
4.linux设备驱动程序——设备树(0)-dtb格式
5.Linux驱动开发 - Linux 设备树学习 - DTS语法
6.案例分享基于全志科技T3与Xilinx Spartan-6的SPI通信

Linux 备树文件.DTS文件格式

       设备树是一种用于描述板级硬件信息的专用文件，其扩展名为.dts。源码译此文件用于分离Linux中关于板级硬件的外编描述内容，便于管理和引用。设备树源直播源码怎么找

       在使用设备树前，码设ARM架构板级信息存于/arch/arm/mach-xxx和/arch/arm/plat-xxx目录下。备树而使用设备树后，源码译这些信息转移至/arch/arm/boot/dts目录，外编并且dts工具源码位于scripts/dtc/Makefile中。设备树源

       设备树的码设语法结构丰富，包括文件引用、备树文件布局、源码译节点格式与属性格式等。外编

       在文件引用方面，如同C语言一般，可以使用`#include`引用.dtsi、.dts和.h文件。文件布局则需遵循特定规范，确保结构清晰、易于理解和维护。

       节点格式中的`[]`表示某项内容可省略，`[label]`用于标记以方便访问，`node-name`为节点名称，`[@unit-address]`则表示设备的地址或寄存器首地址。属性格式则分为`[label:] property-name = value;`（有值）和`[label:] property-name;`（无值）两种。

       属性内容包括字符串、位无符号整数、位字节序列和字符串列表。例如，`compatible`属性用于将设备与驱动绑定，`model`描述设备模块信息，`status`描述设备状态。

       根节点的`compatible`属性用于确认Linux内核是否支持该设备，通常包括硬件设备名称和所使用的SOC。设备节点的`compatible`属性则用于匹配Linux内核中的驱动程序。

       在使用设备树的场景下，通过在.dts文件中`#include`相关.dtsi文件，并在.dts文件中追加或修改内容，可以实现对设备的灵活配置。

       设备匹配方法涉及在`arch/arm/mach-imx/mach-imx6ul.c`文件中设置`dt_compat`变量，此变量包含多个兼容值。当设备根节点`/`的`compatible`属性值与`dt_compat`表中的任一值相匹配时，表示Linux内核支持此设备。

ARM处理器超频、内存超频方法——以主线内核设备树、主线u-boot为例

       ARM处理器超频和内存超频可以通过主线内核设备树和u-boot来实现。首先，内存频率设置可通过查看/sys/kernel/debug/clk/clk_summary得到，初始频率为 MB/s。为了提升到厂商推荐的netty源码笔记 MB/s，需在u-boot源码的menuconfig中修改sunxi dram clock speed，编译并刷写后，内存频率即提升至 MB/s，操作后系统反应速度会有所提升。

       对于CPU频率，ARM平台的Linux内核主要通过设备树文件配置。以香橙派pc为例，通过修改sun8i-h3-orangepi-pc.dts文件，根据SYA提供的电压管理，可增加新的频率档位。注意在超频前确保良好的散热措施，如安装散热片或风扇，以防止过热。我的CPU在调整后最高频率可达1.5GHz。

       GPU频率设置同样在设备树中进行，Mali GPU的频率通常受负载自动调节，可以通过powertop或搜索GPU名称查看。全志H3的GPU理论上可达MHz，但在良好散热下可以超频至MHz，但仍需注意避免过度导致性能问题。

       为了进一步提升系统速度，可以考虑将USB固态硬盘作为系统盘，通过修改boot argument和fstab文件来优化系统分区。这样可以有效提升系统的运行速度。

linux设备驱动程序——i2c总线的添加与实现

       一文看懂linux内核详解

       深入了解使用linux查看磁盘io使用情况

       在实际驱动开发过程中，i2c总线也是集成在系统中的，驱动开发者不需要关心i2c总线的初始化，只需要将相应的i2c_client和i2c_driver挂载在总线上进行匹配即可。

       那么，i2c总线在系统中是如何初始化得来的呢？

       答案就在文件i2c-core-base.c中，它的过程是这样的：

       在i2c_init函数中，使用bus_register()将i2c总线注册到系统中，那么这个i2c_init()函数是在哪里被调用的呢？

       在内核启动的过程中，进入C语言环境的第一个入口函数是start_kernel()，但是i2c_init()并非由start_kernel()间接调用，而是借助于linux内核中的initcall机制被调用，简而言之，就是将这个函数地址在编译阶段放入特定的段中，在内核初始化时由某个启动函数将这些段中的函数一一取出并执行。

       i2c总线通过postcore_initcall()将init函数注册到系统中。

       当模块被加载进系统时，就会执行i2c_init函数来进行初始化。

       在i2c_bus_type结构体中，定义了match(),probe(),remove()和shutdown()函数，match()函数就是当有新的i2c_client或者i2c_driver添加进来时，试图寻找与新设备匹配的项，返回匹配的结果。

       remove()和shutdown()，顾名思义，这两个函数是管理的驱动移除行为的。

       对于probe函数，ubuntu打包源码在之前的章节中提到：当相应的device和driver经由总线匹配上时，会调用driver部分提供的probe函数。

       那么：

       带着这两个疑问，我们接着往下看。

       在这里我们不免要回顾一下前面章节所说的，作为一个驱动开发者，如果我们要开发某些基于i2c的设备驱动，需要实现的框架流程是怎样的：

       但是问题是，为什么device和driver都注册进去之后，就会调用driver部分提供的probe函数呢？

       为了解决这些问题，最好的办法就是看源代码，假设我们是以设备树的方式进行匹配，device(即i2c_client)部分已经被注册到系统中，此时我们向系统中注册(insmod由driver部分程序编译的模块)相应的driver部分,接下来我们跟踪driver部分注册到i2c总线的流程，看看它是怎么实现的：

       跟踪i2c_add_driver：

       经过一系列的代码跟踪，找到了bus_add_driver()，根据名称可以知道，这个函数就是将当前i2c_driver添加到i2c_bus_type(即i2c总线)中。

       接着往下看：

       从第一部分可以看到，将当前drv链入到bus->p->klist_drivers链表中，那么可以猜到，在注册device部分的时候，就会将device链入到bus->p->klist_devices中。

       然后，再看driver_attach(drv):

       driver_attach调用bus_for_each_dev，传入当前驱动bus(即i2c_bus_type)，当前驱动drv，以及一个函数__driver_attach。

       bus_for_each_dev对每个device部分调用__driver_attach。

       在__driver_attach中，对每个drv和dev调用driver_match_device()，并根据函数返回值决定是否继续执行调用driver_probe_device()。

       从函数名来看，这两个函数大概就是我们在前文中提到的match和probe函数了，我们不妨再跟踪看看，先看看driver_match_device()函数：

       果然不出所料，这个函数十分简单，如果当前驱动的所属的bus有相应的match函数，就调用match函数，否则返回1.

       当前driver所属的总线为i2c_bus_type，根据上文i2c总线的初始化部分可以知道，i2c总线在初始化时提供了相应的match函数，所以，总线的match函数被调用，并返回匹配的结果。

       接下来我们再看看driver_probe_device()函数：

       在driver_probe_device中又调用了really_probe，在really_probe()中，先判断当前bus总线中是否注册probe()函数如果有注册，就调用总线probe函数，否则，就调用当前drv注册的淘宝源码工具probe()函数。

       到这里，我们解决了上一节中的一个疑问：总线和driver部分都有probe函数时，程序是怎么处理的？

       答案已经显而易见了：优先调用总线probe函数。

       而且我们理清了总线的match()函数和probe()函数是如何被调用的。

       那么，上一节中还有一个疑问没有解决：总线的match和probe函数执行了一些什么行为？

       对于总线probe函数，获取匹配成功的device，再由device获取driver，优先调用driver->probe_new,因为driver中没有设置，直接调用driver的probe函数。

       总线probe和driver的probe函数的关系就是：当match返回成功时，优先调用总线probe，总线probe完成一系列的初始化，再调用driver的probe函数，如果总线probe函数不存在，就直接调用driver的probe函数，所以当我们在系统中添加了相应的device和driver部分之后，driver的probe函数就会被调用。

       对于总线match函数，我们直接查看在i2c总线初始化时的函数定义：

       i2c_device_match就是i2c_driver与i2c_device匹配的部分，在i2c_device_match函数中，可以看到，match函数并不只是提供一种匹配方式：

       接下来再深入函数内部，查看匹配的细节部分：

       在i2c_of_match_device中，调用了of_match_device()和i2c_of_match_device_sysfs()两个函数，这两个函数代表了两种匹配方式，先来看看of_match_device：

       of_match_device调用of_match_node。

       of_match_node调用__of_match_node函数。

       如果你对设备树有一定的了解，就知道系统在初始化时会将所有设备树子节点转换成由struct device_node描述的节点。

       在被调用的__of_match_node函数中，对device_node中的compatible属性和driver部分的of_match_table中的compatible属性进行匹配，由于compatible属性可以设置多个，所以程序中会对其进行逐一匹配。

       我们再回头来看设备树匹配方式中的i2c_of_match_device_sysfs()匹配方式：

       由i2c_of_match_device_sysfs()的实现可以看出:当设备树中不存在设备节点时，driver部分的of_match_table中的compatible属性试图去匹配i2c_client(device部分)的.driver.name属性.

       因为设备树的默认规则，compatible属性一般形式为"vender_id,product_id"，当compatible全字符串匹配不成功时，取product_id部分再进行匹配，这一部分主要是兼容之前的不支持设备树的版本。

       acpi匹配方式较为少用且较为复杂，这里暂且不做详细讨论

       id_table匹配方式中，这种匹配方式一目了然，就是对id_table(driver部分)中的.name属性和i2c_client(device部分)的.name属性进行匹配。那么i2c_client的.name是怎么来的呢？

       在非设备树的匹配方式中，i2c_client的.name属性由驱动开发者指定，而在设备树中，i2c_client由系统对设备树进行解析而来,i2c_client的name属性为设备树compatible属性"vender_id,product_id"中的"product_id",所以，在进行匹配时，默认情况下并不会严格地要求 of_match_table中的compatible属性和设备树中compatible属性完全匹配，driver中.drv.name属性和.id.name属性也可以与设备树中的软件源码模块"product_id"进行匹配。

       关于linux i2c总线的初始化以及运行机制的讨论就到此为止啦

linux设备驱动程序——设备树(0)-dtb格式

       设备树的一般操作方式是：开发人员根据开发需求编写dts文件，然后使用dtc将dts编译成dtb文件。

       dts文件是文本格式的文件，而dtb是二进制文件，在linux启动时被加载到内存中，接下来我们需要来分析设备树dtb文件的格式。

       为什么要了解设备树dtb文件的格式

       dtb作为二进制文件被加载到内存中，然后由内核读取并进行解析，如果对dtb文件的格式不了解，那么在看设备树解析相关的内核代码时将会寸步难行，而阅读源代码才是了解设备树最好的方式，所以，如果需要更透彻的了解设备树解析的细节，第一步就是需要了解设备树的格式。

       dtb格式总览

       dtb的格式是这样的：

       dtb header

       但凡涉及到数据的记录，就一定会有一个总的描述部分，就像磁盘的超级块，书的目录，dtb当然也不例外，这个描述头部就是dtb的header部分，通过这个header部分，用户可以快速地了解到整个dtb的大致信息。

       header可以用这么一个结构体来描述：

       magic

       设备树的魔数，魔数其实就是一个用于识别的数字，表示设备树的开始，linux dtb的魔数为 0xddfeed.

       totalsize

       这个设备树的size，也可以理解为所占用的实际内存空间。

       off_dt_struct

       offset to dt_struct，表示整个dtb中structure部分所在内存相对头部的偏移地址

       off_dt_strings

       offset to dt_string，表示整个dtb中string部分所在内存相对头部的偏移地址

       off_mem_rsvmap

       offset to memory reserve map，dtb中memory reserve map所在内存相对头部的偏移地址，

       version

       设备树的版本，截至目前的最新版本为.

       last_comp_version

       最新的兼容版本

       boot_cpuid_phys

       这部分仅在版本2中存在，后续版本不再使用。

       size_dt_strings

       表示整个dtb中string部分的大小

       size_dt_struct

       表示整个dtb中struct部分的大小

       alignment gap

       中间的alignment gap部分表示对齐间隙，它并非是必须的，它是否被提供以及大小由具体的平台对数据对齐和的要求以及数据是否已经对齐来决定。

       memory reserve map

       memory reserve map：描述保留的内存部分，这个map的数据结构是这样的：

       这部分存储了此结构的列表，整个部分的结尾由一个数据为0的结构来表示(即physical_address和size都为0，总共字节)。

       这一部分的数据并非是节点中的memory子节点，而是在设备开始之前(也就是第一个花括号之前)定义的,例如：

       这一部分的作用是告诉内核哪一些内存空间需要被保留而不应该被系统覆盖使用，因为在内核启动时常常需要动态申请大量的内存空间，只有提前进行注册，用户需要使用的内存才不会被系统征用而造成数据覆盖。

       值得一提的是，对于设备树而言，即使不指定保留内存，系统也会默认为设备树保留相应的内存空间。

       同时，这一部分需要位(8字节)对齐。

       device-tree structure

       device-tree structure：每个节点都会被描述为一个struct，节点之间可以嵌套，因此也会有嵌套的struct。

       structure的的结构是这样的：

       device-tree strings

       device-tree strings：在dtb中有大量的重复字符串，比如"model","compatile"等等，为了节省空间，将这些字符串统一放在某个地址，需要使用的时候直接使用索引来查看。

       需要注意的是，属性部分格式为key = value，key部分被放置在strings部分，而value部分的字符串并不会放在这一部分，而是直接放在structure中。

       dtb文件解析示例

       光说不练假把式，下面我就使用一个简单的示例来剖析dtb的文件格式。

       下述示例仅仅是一个演示demo，不针对任何平台，为了演示方便，编写了一个非常简单的dts文件。 /dts-v1/; / {

       编译当前dts文件，获取对应的dtb文件。

       鉴于dtb文件为二进制文件，普通编辑器打开显示乱码，我们使用ultraEdit查看，它将数据以进制形式显示：

       整个dtb文件还是比较简单的，图中的红色框出的部分为header部分的数据，可以看到：

       整个头部为字节，进制为0x，从头部信息中off_mem_rsvmap部分可以得到，reserve memory起始地址为0x，上文中提到，这一部分使用一个字节的struct来描述，以一个全为0的struct结尾。

       后字节全为0，可以看出，这里并没有设置reserve memory。

       structure 部分

       上文回顾：每一个属性都是以 key = value的形式来描述，value部分可选。

       偏移地址来到0x(0x+0x),接下来8个字节为，根据上述structure中的描述，这是OF_DT_PROP，即标示属性的开始。

       接下来4字节为，表明该属性的value部分size为字节。

       接下来4字节是当前属性的key在string 部分的偏移地址，这里是，由头部信息中off_dt_strings可以得到，string部分的开始为，偏移地址为0，所以对应字符串为"compatible".

       之后就是value部分，这部分的数据是字符串，可以直接从右侧栏看出，总共字节的字符串"hd,test_dts", "hd,test_xxx",因为字符串之间以0结尾，所以程序可以识别出这是两个字符串。

       可以看出，到这里，compatible = "hd,test_dts", "hd,test_xxx";这个属性就被描述完了，对于属性的描述还是非常简单的。

       按照固有的规律，接下来就是对#address-cells = <0x1>的解析，然后是#size-cells = <0x1>...

       然后就是递归的子节点chosen，memory@等等都是按照上文中提到的structure解析规则来进行解析，最后以结尾。

       与根节点不同的是，子节点有一个unit name，即chosen，memory@这些名称，并非节点中的.name属性。

       而整个结构的结束由来描述。

       一般而言，在位系统中，dtc在编译dts文件时会自动考虑对齐问题，所以对于设备树的对齐字节，我们只需要有所了解即可，并不会常接触到。

       好了，关于linux设备树dtb文件格式的讨论就到此为止啦。

Linux驱动开发 - Linux 设备树学习 - DTS语法

       设备树(Device Tree)是一种描述硬件设备的树形结构文件，主要用于Linux系统中描述板级设备信息，如CPU数量、内存基地址、IIC接口和SPI接口所连接的设备等。设备树的主干是系统总线，IIC控制器、GPIO控制器、SPI控制器等设备是系统总线上的分支。例如，IIC控制器分为IIC1和IIC2，其中IIC1连接了FT和ATC这两个IIC设备，IIC2仅连接了MPU一个设备。

       在开发Linux设备驱动时，需要了解DTS（Device Tree Source）、DTB（Device Tree Binary）和DTC（Device Tree Compiler）之间的关系。DTC工具依赖于特定的源代码文件，最终生成主机文件DTC。要编译DTS文件，只需在Linux源码根目录下执行命令“make all”或“make dtbs”，后者仅编译设备树。

       在开发板中，每个板子都对应一个DTS文件，以I.MX6ULL芯片为例，打开arch/arm/boot/dts/Makefile文件，可以找到特定编译配置。当选中I.MX6ULL芯片后，与该芯片相关的DTS文件会被编译成DTB文件。若要为新的板子编写DTS文件，只需新建此板子对应的DTS文件，并在dtb-$(CONFIG_SOC_IMX6ULL)下添加对应的DTB文件名，这样在编译设备树时会自动编译为二进制文件。

       在Linux内核源码分析学习方面，可参考指定地址。此外，Linux内核源码分析交流群提供学习资源，包括书籍、视频等，通过加入该群可以获取这些资源。

       在编写设备树文件时，需要了解DTS语法。DTS文件支持头文件，扩展名为.dtsi。设备树节点通过属性信息描述，属性是键值对形式。例如，在imx6ull.dtsi文件中，描述了CPU架构、频率、外设寄存器地址范围等信息。设备节点是树形结构中描述设备的节点，通过节点名字和地址来描述。

       兼容性属性(compatible)是设备树中非常重要的属性，用于将设备与驱动绑定。属性值是一个字符串列表，格式为“厂商名称, 设备名称”。Linux下的外设驱动通常会使用这些兼容性属性来查找与设备匹配的驱动程序。

       模型属性(model)描述设备模块信息，如设备名字。状态属性(status)记录设备状态，可选状态包括正在运行、已停止、错误等。地址属性(address-cells和size-cells)用于描述设备子节点的地址信息，reg属性用于描述设备地址空间资源信息。ranges属性用于描述设备子地址和父地址的映射关系。

       在产品开发过程中，设备树文件需要随着硬件需求的变更而更新。例如，需要在I.MX6U-ALPHA开发板的I2C1接口上添加一个新设备时，需要在对应的DTS文件中向已有节点添加新子节点。

       在Linux内核启动时，设备树信息会被解析并在根文件系统中以目录/proc/devicetree的形式体现。通过该目录可以查看根节点的属性和子节点，如模型、兼容性、地址等信息。这些信息与设备树文件中的描述相匹配。

案例分享基于全志科技T3与Xilinx Spartan-6的SPI通信

       本文主要介绍基于全志科技T3与Xilinx Spartan-6的SPI通信案例。本案例采用的评估底板为创龙科技TLT3-EVM，它是一款基于全志科技T3处理器设计的4核ARM Cortex-A7高性能低功耗国产评估板，每核主频高达1.2GHz，由核心板和评估底板组成。案例源码位于“4-软件资料\Demo\platform-demos\spi_rw\”目录下。FPGA端程序实现SPI Slave功能，ARM实现SPI Master功能，支持误码率测试和速率测试两种模式。本案例使用的设备树源文件为"driver\dts\"目录下的tlt3-evm-spidev.dts。评估板上电启动，在评估板文件系统boot_package.fex文件所在路径下，执行如下命令替换原来的固件，并重启评估板。之后，执行如下命令查看新生成的spidev设备节点，执行命令查询程序命令参数，运行程序，ARM通过SPI总线写入2KByte随机数到FPGA BRAM，然后读出数据、进行数据校验，同时打印SPI总线读写速率和误码率，读速率为0.MB/s，写速率为0.MB/s，误码率为0。执行命令运行程序，ARM通过向FPGA发送Byte随机数据，并从FPGA读取回来，循环次，测试SPI总线读写速率，读写速率为：(.8//8)MB/s≈4.MB/s。同时测得进行SPI读写速率测试时，CPU的占用率约为8%。案例编译中，将案例"driver\dts\"目录下tlt3-evm-spidev.dts设备树拷贝至LinuxSDK开发包内核源码"arm/arm/boot/dts/"目录下，替换并重命名为tlt3-evm.dts。进行编译Linux内核、设备树等，重新执行"./build.sh pack"命令，生成新的boot_package.fex镜像，将其拷贝至评估板文件系统进行固化，评估板重启后将会加载新的设备树文件，生成"/dev/spidev0.0"设备节点。ARM端程序关键代码包括打开SPI设备、配置SPI总线、误码率测试和读写速率测试功能实现。

Linux内核DTB文件启动的几种方式

       Device Tree简介

       Linus Torvalds在年提出Device Tree概念，作为一种硬件描述数据结构，它源于OpenFirmware。在Linux2.6中，ARM架构的板级硬件细节过多地被硬编码在内核中。Device Tree引入后，许多硬件细节可以直接传递给Linux，减少内核中的冗余编码。

       Device Tree由结点和属性组成，描述硬件信息如CPU、总线、设备的连接关系。Bootloader将Device Tree传递给内核，内核识别并展开硬件，创建如platform_device、i2c_client等设备对象。

       Device Tree编译

       Device Tree文件(dts)需编译为dtb格式，便于Linux和Bootloader识别。编译工具是dtc，可以通过在Linux源码目录下执行命令安装。

       早期Linux内核启动

       早期Linux内核通过硬编码的方式描述硬件信息，如在arch/arm/mach-xxx文件中。zImage文件需要通过u-boot转换为uImage后，通过bootm命令启动。

       设备树启动

       Linux-3.x后内核统一启用Device Tree，硬件信息描述在dts文件中。编译内核时使用make dtbs生成dtb文件。启动时需要加载uImage和dtb文件。

       设备树和uImage合并

       dtb文件将硬件信息与内核分离，通过合并uImage和dtb文件，可为不同硬件开发板提供统一内核。例如，使用cat命令合并文件后，使用mkimage生成uImage文件。

       u-boot FIT image合并

       使用FIT Image格式合并uImage和dtb文件。FIT Image利用Device Tree Source files语法，通过mkimage命令生成itb文件。u-boot需要配置支持FIT Image启动。

       总结

       Device Tree提供了一种灵活的硬件描述方式，使内核与硬件解耦。通过合并uImage和dtb文件，或使用FIT Image格式，可简化启动流程，支持不同硬件开发板。