辽宁网站建站,营销信息,动图制作网站,wordpress 制作小程序QA#xff1a;dts和dtsi的区别
在嵌入式 Linux 系统中#xff0c;DTS#xff08;Device Tree Source#xff09;和 DTSI#xff08;Device Tree Source Include#xff09;是描述硬件设备树的文件格式。它们本质上是同一种语法的文件#xff0c;但在使用上有一定区别。…QAdts和dtsi的区别
在嵌入式 Linux 系统中DTSDevice Tree Source和 DTSIDevice Tree Source Include是描述硬件设备树的文件格式。它们本质上是同一种语法的文件但在使用上有一定区别。以下是两者的主要差异和用途
1. 文件类型和用途 DTS (Device Tree Source) DTS 文件是设备树的主文件描述了一个具体设备或板子的硬件配置。每个具体的硬件设备都会有一个对应的 DTS 文件它是系统用来解析设备硬件结构的主要输入。 例如board.dts。 DTSI (Device Tree Source Include) DTSI 文件是设备树的包含文件通常是一个共享的硬件描述片段供多个 DTS 文件引用。DTSI 文件中定义的是通用或模块化的硬件配置目的是实现代码复用。 例如chip.dtsi。 2. 内容层次 DTS 通常定义特定板级硬件相关的配置例如 GPIO 引脚分配、外设启用等。 /dts-v1/;
/include/ chip.dtsi/ {model Custom Board;compatible custom,board;aliases {serial0 uart0;};chosen {stdout-path uart0;};
}; DTSI 通常定义 SoC芯片级或通用硬件部分的配置适用于多个设备树文件。 /dts-v1/;/ {soc {uart0: serial10000000 {compatible ns16550;reg 0x10000000 0x1000;clock-frequency 24000000;};};
}; 3. 继承和覆盖
DTS 文件通过 /include/ 指令包含 DTSI 文件中的内容然后可以覆盖其中的属性。
例如
在 chip.dtsi 中定义了 UART 外设在 board.dts 中可以基于 chip.dtsi启用或修改 UART 的配置。
继承示例
chip.dtsi:
/include/ chip.dtsiuart0 {status okay; // 覆盖为启用
}; board.dts:
/include/ chip.dtsiuart0 {status okay; // 覆盖为启用
}; 4. 文件组织
DTSI 通常由芯片厂商或 SoC 开发人员提供用于定义通用部分例如 CPU、外设等。DTS 通常由板级开发人员创建用于描述特定开发板或产品的具体硬件配置。 5. 总结对比
属性DTSDTSI用途定义具体设备或板级配置定义共享或通用硬件配置作用具体化设备树描述模块化、复用包含关系可引用多个 DTSI 文件通常不引用其他文件适用范围针对单个设备/板子针对芯片级或通用配置
通过这种分层结构可以实现设备树文件的模块化和复用从而简化开发和维护工作。 QA如果我是板级工程师那么我不应该修改dtsi文件而是只能新增或者修改dts文件
是的作为板级工程师一般不建议直接修改 DTSI 文件而是通过新增或修改 DTS 文件来完成硬件描述。这样做的原因如下 为什么不建议修改 DTSI 文件 DTSI 文件通常由芯片厂商或 BSP 提供 DTSI 文件一般描述的是芯片级SoC 级的硬件资源和特性这些内容是通用的适用于多种不同的开发板或设备。修改 DTSI 可能会影响其他使用相同芯片的项目。如果您修改了 DTSI 文件在后续升级厂商提供的 BSPBoard Support Package时可能会导致冲突甚至丢失修改内容。 分层设计的目的 DTSI 文件的作用是描述通用硬件资源而 DTS 文件是为具体板级定制的。通过继承和覆盖可以避免直接修改通用内容从而维护良好的分层结构。 方便维护和协作 当多个工程师协作开发时如果每个人都能随意修改 DTSI 文件会导致难以追踪改动来源增加协作复杂度。如果只修改 DTS 文件改动是板级特有的容易维护和调试。 正确的做法通过 DTS 文件实现定制化
如果需要在板级启用或修改某些硬件资源可以在 DTS 文件中通过继承和覆盖的方式实现。以下是常见情况的处理方式
1. 启用某些外设
DTSI 文件中通常将外设状态设置为 disabled您可以在 DTS 文件中将其改为 okay。
/include/ chip.dtsiuart0 {status okay; // 启用 UART0pinctrl-names default;pinctrl-0 uart0_pins;
}; 2. 添加板级特有的外设
如果板子上有芯片厂商未定义的外设比如额外的传感器或定制模块可以直接在 DTS 文件中新增节点而无需修改 DTSI 文件。
i2c1 {status okay;temp_sensor48 {compatible mycompany,temp-sensor;reg 0x48;};
}; 3. 覆盖特定配置
如果板级需要调整某些硬件资源例如 GPIO 引脚或时钟频率可以在 DTS 中覆盖 DTSI 的默认配置
spi0 {status okay;cs-gpios gpio1 5 GPIO_ACTIVE_LOW; // 修改片选引脚
}; 如果修改 DTSI 是必需的情况
尽管一般不建议修改 DTSI 文件但在以下情况下可以考虑调整 厂商提供的 DTSI 文件存在错误 如果您确认芯片厂商的 DTSI 文件有问题如硬件地址或属性错误可以修复后在项目内使用。 特定项目的定制需求 如果您确定该 DTSI 文件仅用于当前项目且不会影响其他设备或板子可以直接修改但需要清楚记录原因。 实验性调试 如果某些问题需要快速验证您可以临时修改 DTSI但在正式实现时应将更改移到 DTS 文件中。
总结建议
优先修改 DTS 文件通过覆盖或新增节点实现板级定制。尽量避免修改 DTSI 文件保持芯片级硬件描述的通用性。如需修改 DTSI 文件确保原因充分并明确记录以便后续维护。
通过这种方式可以既满足项目需求又维持代码的模块化和可维护性。 QA有人说dts和dtsi的关系就像.c文件和.h文件的include关系。这样的说法准确吗
网上将 DTS 和 DTSI 的关系类比为 .c 文件和 .h 文件的关系并不完全准确。这种类比可能有助于初学者快速理解它们的引用方式但实际上两者的作用和结构存在显著差异。 为什么类比不准确
1. .h 文件与 .c 文件的分工明确
.h 文件主要是接口声明定义函数、变量或结构体的原型。它不包含具体实现。.c 文件主要是实现具体功能编写函数的逻辑代码。
这种分工明确的方式在 DTS 和 DTSI 中并不存在因为 DTSI 文件不仅包含“声明”内容还包含许多具体配置属性和硬件节点可以直接被系统解析和使用。
2. DTSI 文件包含具体实现
DTSI 文件并不是简单的“声明文件”而是包含大量具体硬件配置。例如
uart0: serial10000000 {compatible ns16550;reg 0x10000000 0x1000;clock-frequency 24000000;status disabled;
}; 以上代码实际上已经定义了 UART 的硬件地址、寄存器大小和时钟频率这些是完整的硬件描述直接参与设备树解析并非简单的“接口声明”。
3. DTS 和 DTSI 的关系是“继承与覆盖”
DTS 文件从 DTSI 文件中“继承”节点配置并可以通过覆盖来调整具体的属性值。这种行为更接近面向对象编程中的“继承”关系而不是简单的“引用”关系。 更贴切的类比是什么
将 DTSI 比作一个“父类”或“模板”将 DTS 比作一个“子类”可能更恰当
DTSI 定义了通用的硬件节点和默认配置相当于父类提供的通用功能和默认属性。DTS 则在继承 DTSI 内容的基础上进一步细化或修改配置相当于子类对父类进行扩展或覆盖。
示例继承与覆盖关系
// chip.dtsi
soc {uart0: serial10000000 {compatible ns16550;reg 0x10000000 0x1000;clock-frequency 24000000;status disabled; // 默认禁用};
};
// board.dts
/include/ chip.dtsiuart0 {status okay; // 覆盖为启用
};
在这个例子中
chip.dtsi 定义了通用的 UART 硬件节点和属性board.dts 继承了 chip.dtsi 中的内容并根据具体板级需求调整状态。 总结为什么网上的类比有局限性
DTSI 文件不仅仅是“声明”性质它包含具体实现而 .h 文件不包含实现。DTS 文件不是从零开始实现所有功能而是基于 DTSI 的内容进行扩展或覆盖。它们的关系更接近“模板父类”与“实例子类”而不是“接口与实现”。
因此用 继承与覆盖 来描述 DTS 和 DTSI 的关系比简单的 .c 和 .h 文件类比更准确也更符合设备树的实际用法。
