Notes on DTS (Device Tree) Debugging

Categories:

  2 minute read  

The thought process for debugging the DTS of an external peripheral is as follows:

1. Logical Node

  • There is a logical node representing the entirety of the logical device that the developer can control (e.g., USB). Generally, this logical node is also defined in the board-level or product-level dtsi file.

2. Controller Node

3. PHY Node

  • Within the controller node, there will be a PHY node. For USB 3.0, there will be two PHYs: one providing support for USB 2.0 mode and the other for USB 3.0 mode.
    • This is because the USB protocol is backward compatible (meaning a USB 3.0 interface can support USB 2.0 devices). Therefore, USB 3.0 must provide a 2.0 PHY to achieve this “backward compatibility.”

4. Enable Everything in the Product-Level DTSI

  • The corresponding logical nodes, controller nodes, and PHY nodes must all be enabled and configured to the correct modes.

Remarks

  1. The method described above is based on operating on the DTS provided by the SoC vendor and assumes that no major hardware changes have been made.
  2. Refer to the Hardware Dataflow Pipeline, which discusses common hardware data flow models. This is very helpful for debugging DTS as it allows you to know which component you are currently working on.
  3. Two important types of nodes in USB DTS:
    • Some are host-only, typically named usbhost30 in the DTS.
    • Some can function as either host or device (i.e., OTG), typically named usbdrd30 in the DTS.

How to identify which node is the controller from the code?

  • It has interrupts to notify the CPU (interrupts).
  • It possesses a PHY (phys, phy-names).
  • It is bound to a driver (has a compatible property).
  • It has a large register address space (reg = <0x0 0xfcc00000 0x0 0x400000>).
  • It has complex clock and reset logic.
  • It has high-level mode configurations (e.g., dr_mode="otg").