调试RK3588必看！这个临时设备树文件，藏着你要的所有配置答案

做RK3588 芯片开发的小伙伴，肯定在kernel/arch/arm64/boot/dts/rockchip/目录下见过一个“长名字文件”——rk3588-evb7-v11-linux.dtb.dts.tmp。不少人以为它是编译过程的“临时垃圾”，看完这篇你就知道：它其实是解决硬件适配、内核启动问题的“调试钥匙”。
 

 

一、先搞懂：这个“长名字文件” 到底是什么？

 

在解释“为什么要关注” 之前，咱们先拆解文件名，搞懂它的 “身份”：

 

 

•rk3588-evb7-v11：对应硬件型号——RK3588 芯片的 EVB7 版本 11 开发板，明确了文件的硬件适配范围；

 

 

•dtb.dts.tmp：核心属性——dts是设备树源码，dtb是编译后的二进制设备树，tmp表示它是内核编译过程中生成的“临时中间文件”，本质是“展开后的完整设备树源码”。

 

 

简单说：它是编译器将所有关联的设备树文件（.dts/.dtsi）整合后生成的 “全量源码快照”，比原始分散的 dts 文件更能反映 “最终生效的配置”。

 

 

二、关键信息提取：从文件里能挖到哪些“宝藏”？

 

调试时最头疼的问题：“我改的配置到底生效了吗？”“内核用了哪些设备树文件？”—— 这些答案都在这个临时文件里。

 

 

1. 看 “最终生效的硬件配置”

 

打开文件后，所有硬件节点的实际配置一目了然，不用再逐个查分散的 dtsi 文件：

 

 

•外设使能状态：比如uart2节点是否有status = "okay"，判断串口是否真的启用；

 

 

•引脚与地址：spi1的片选引脚cs-gpios、寄存器基地址reg，直接对应硬件接线；

 

 

•时钟与电源：clk-frequency = <100000000>（SPI 时钟 100MHz）、vdd-supply = <&vdd_3v3>（供电来源），这些关键参数直接影响外设工作。

 

 

举个例子：如果调试 I2C 传感器时发现设备不响应，打开这个文件搜i2c3，就能快速确认：是节点被禁用（status="disabled"），还是地址写错（reg=0x48 写成 0x49）。

 

 

2. 查 “被引用的所有文件路径”

 

设备树配置常分散在多个文件（如芯片级 dtsi、板级 dtsi、通用头文件），这个临时文件会通过#include明确列出所有依赖文件及路径：

 

 

#include   // 通用GPIO定义头文件（内核通用路径）     #include   // RK3588时钟定义     #include "rk3588.dtsi"  // RK3588芯片核心设备树（同目录）     #include "rk3588-evb7-common.dtsi"  // EVB7开发板通用配置（同目录）     #include "rk3588-sdmmc.dtsi"  // SD卡控制器配置（同目录）

通过这些路径，你能快速定位：

 

 

•某个配置来自哪个文件（比如时钟参数来自rk3588-cru.h）；

 

 

•是否漏引 / 错引文件（比如想启用 HDMI，却没找到#include "rk3588-hdmi.dtsi"）。

 

 

三、核心原因：为什么调试 RK3588 必须盯紧它？

 

咱们调试时踩过的很多坑，本质都是“配置没生效” 或 “文件引用错”，而这个临时文件正好能解决这些核心痛点。

 

 

1. 避免 “改了 dts 却没生效” 的无效调试

 

你有没有遇到过：明明在rk3588-evb7-v11.dts里改了 SPI 时钟，内核启动后却还是老频率？

 

 

问题可能出在“配置被覆盖”—— 比如rk3588-evb7-common.dtsi里的 SPI 时钟参数优先级更高，覆盖了你改的配置。

 

 

这时候打开临时文件搜spi1，就能看到最终生效的clk-frequency是多少，快速定位“被覆盖的配置”，避免在原始 dts 里反复修改却没用。

 

 

2. 快速定位 “编译报错 / 启动异常” 的根源

 

•编译报错“undefined reference to 'GPIO_ACTIVE_HIGH'”：打开临时文件，看是否漏引了dt-bindings/gpio/gpio.h；

 

 

•内核启动提示“Cannot find device tree node for 'mmc0'”：搜mmc0节点，看是否被禁用，或引用的rk3588-sdmmc.dtsi路径错了；

 

 

•外设驱动加载失败：查对应节点的compatible属性（如compatible = "rockchip,rk3588-i2c"）是否与驱动匹配，避免“驱动和设备树不兼容” 的问题。

 

 

3. 校验 “版本一致性”，排除环境问题

 

多人协作或更换编译环境时，很容易出现“用了旧版本 dts 文件” 的问题。比如同事更新了rk3588-evb7-common.dtsi，你本地却还是老版本，编译后配置不一致。

 

 

这时候对比两个环境生成的rk3588-evb7-v11-linux.dtb.dts.tmp文件（用diff命令），就能快速发现哪些配置或引用文件有差异，排除“环境不一致” 的坑。

 

 

四、实操技巧：3 步用好这个 “调试利器”

 

知道了它的价值，咱们再讲怎么实际用起来：

 

 

1. 找到文件：编译后自动生成

 

只要执行过 RK3588 内核编译（如make dtbs或make），文件就会自动生成在kernel/arch/arm64/boot/dts/rockchip/目录下，不用手动创建。

 

 

2. 查看关键配置：用 grep 快速搜索

 

不用逐行翻文件，用grep命令精准定位：

 

 

•查 UART2 配置：grep -A 10 "uart2" rk3588-evb7-v11-linux.dtb.dts.tmp（-A 10 表示显示匹配行后 10 行）；

 

 

•查所有引用文件：grep "#include" rk3588-evb7-v11-linux.dtb.dts.tmp。

 

 

3. 对比配置差异：用 diff 命令

 

比如对比“修改 dts 前后” 的配置变化：

 

 

# 先备份修改前的文件     cp rk3588-evb7-v11-linux.dtb.dts.tmp old.tmp     # 修改dts后重新编译，生成新文件     make dtbs     # 对比差异     diff old.tmp rk3588-evb7-v11-linux.dtb.dts.tmp

最后总结

 

对 RK3588 调试者来说，rk3588-evb7-v11-linux.dtb.dts.tmp不是“临时垃圾”，而是：

 

 

•「配置快照」：反映最终生效的硬件参数；

 

 

•「文件地图」：明确所有依赖的设备树文件；

 

 

•「排障工具」：快速定位编译 / 启动 / 外设问题。

 

 

下次调试时，别再忽略这个文件了—— 打开它，很多问题可能一眼就有答案。你平时调试设备树时还遇到过哪些坑？欢迎在评论区分享，咱们一起避坑～