vlambda博客
学习文章列表

整理出了 6 种驱动开发时与设备注册、设备树相关的调试方法，彼此间没有优先级之分，每种方法不一定是最优解，但可以作为一种 debug 查找问题的手段，快速定位问题原因。例如在芯片验证时，不同时钟频率下系统启动情况摸底时，U-Boot fdt 命令可以方便快捷的帮助我们完成这个实验。

1. dtdiff 工具

这个文件需要在宿主机安装，在对比二进制的 dtb 文件时比较方便。文本格式的 dts 文件对比并不需要这个工具。

对比以下两个 dtb 文件的结果如下：

2. kernel device-tree base

系统启动后进入到/sys/firmware/devicetree/base 目录可以看到当前已注册设备的设备树信息，通过相关命令可以查看当前设备的结点信息、状态等。

上面各个子目录里显示的信息和设备树 dts 文件中定义的条目数是一样的。

3. U-Boot fdt command

驱动代码在 debug 期间，若希望更改外设模块的设备树属性时，在不改变存储设备中 dtb 文件的前提下，进入到 U-Boot 的命令行界面，通过 U-Boot 的 fdt 命令来实现。例如修改外设时钟源、修改外设时钟名、status 属性等。为了使 U-Boot 支持 fdt 命令需要打开 CONFIG_OF_LIBFDT。

通过 fdt print 查看测试驱动 driver-test 的设备树信息，当查看某一个设备树结点的信息时，需要使用绝对路径进行设备树结点的索引。

driver-test 的设备树定义在源文件中 dts 如下图，dtb 内的信息是完全展开的，实际上和 dts 中信息完全一致。clocks = <0x00000005>是 dtc 编译时对结点引用 label 重新插入的 phandle 值。

3. 修改设备时钟

设备树文件中 driver_test 的时钟源为 oscclk2，时钟名为 apb_clk。现在将 driver_test 时钟源设置为 oscclk1，时钟名改为 ahb_clk。oscclk1 在 dtc 编译后的 label 编号时 0x00000012。

修改后如下图：

修改完之后，手动加载 kernel 镜像来启动系统。系统启动后查看设备树信息是否修改成功。可以看见 clock-names 已经由原来的 apb_clk 更改为 ahb_clk。

3. 修改设备 status 状态

设备树里 status 可以决定设备使能状态，status 状态支持以下几种格式，若设置了 status 为 disable，那么设备是不可用的。若不设置 status，默认设备可用。

在 platform_device 创建时会检查设备的可用性，若设备不可用，那么是不会创建 platform_device 的。of_device_is_available 用于检查 status 属性。

driver-test 的设备树里定义了 status = “disable”，查看设备结点的 status 信息也显示为 disable。

加载 driver-test 驱动以后设备未创建成功，当然也就无法执行驱动的 probe 函数。这是除 compatible 不匹配之外的另一个无法执行驱动 probe 函数的原因。

现在重启系统进入到 U-Boot 的命令行模式，通过 fdt 修改 status 的值为 okay。

启动系统，再次确认设备树结点信息是否修改成功以及驱动是否执行了 probe 函数。通过系统启动的 log 信息可以看到，当修改完 status 状态值之后，driver_test 的 probe 函数得到了执行。

driver_test 设备也正常的注册进 platform 设备中。

3. fdt 其他功能

fdt print 可以打印整个的 dtb FDT 信息

fdt header 查看 dtb 的头部信息，通过 size 大小也可以间接的判断当前加载的设备树文件是否为所需的设备树。

4. dtc 工具

dtc 可以使用宿主机提供的亦可以使用 kernel 提供的。这个工具是将已编译的 dtb 文件反汇编。

5. 查看 kernel fdt 文件

这个 fdt 是未解压缩的 dtb 文件，里面的内容和 dtb 完全一样。在 kernel 系统中执行 hexdump 查看：

通过 UE 查看原始的 dtb 文件，与 fdt 文件内容完全一致。

6. of_property_xxx

在代码中可以调用 of.h 中提供的 API 来检查或这获取 device node 的信息。

例如下面的调用方式