转自: https://cloud.tencent.com/developer/article/1855138

整理出了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。

U-Boot提供的fdt命令是针对内存中的FDT而言的，因此，需要将存储设备中的dtb文件加载到内存RAM中。然后再告知FDT设备树在内存中的地址。

将dtb文件从mmc中加载到DDR的0x61000000地址处，并告知U-Boot FDT文件在内存中所在的位置为0x61000000。

通过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的信息。

例如下面的调用方式

------END------