Device Tree: How Linux Describes Hardware

Device Tree separates a board's hardware description from much of the driver code. It tells Linux which devices exist, where their registers are, and which resources they need.

Why Device Tree exists

Embedded boards may share a processor family but differ in attached peripherals, memory maps, clocks, GPIO wiring, and interrupts. Device Tree represents those differences as data rather than hard-coding every board variation into a driver.

A small example

sensor@48 {
    compatible = "acme,example-sensor";
    reg = <0x48>;
    status = "okay";
};

This is illustrative only: the node belongs under the correct bus controller, and the meaning of reg depends on that bus's address and size cells. For I²C, the address is typically a bus address, not a CPU physical register address.

From DTS to probe()

A board description is compiled from DTS into a DTB.
The bootloader passes the DTB to the kernel.
The kernel creates device objects from enabled nodes.
A driver's of_match_table matches the node's compatible string.
The driver core calls probe() when matching and dependencies permit it.

Resources and dependencies

Drivers should retrieve resources through subsystem APIs rather than parsing arbitrary properties manually. Clocks, regulators, resets, GPIOs, and interrupts may be described as dependencies. Deferred probing can occur when a required provider is not ready yet.

Debugging checklist

Confirm the running DTB is the one you edited.
Check that the node has status = "okay" or no disabled status.
Verify bus address, interrupt polarity, pin muxing, and clock references against the schematic and SoC manual.
Inspect /proc/device-tree, kernel logs, and the driver's match table.
Validate bindings with the kernel's Device Tree schema tools when available.

Device Tree is an interface contract between firmware, board description, and drivers. Keep it consistent with the actual hardware and kernel binding documentation.

Final takeaway

Low-level engineering is about understanding the contract between hardware, firmware, and the operating system. Start with the specification, form a testable hypothesis, collect evidence, and validate behavior on the target platform.