Device trees

Board bring-up and every hardware change go through the device tree. .dts, .dtsi and .dtso files open in the device tree language, resolved along the kernel's include path on the build host.

Edit device tree sources

• Go to a label's node, an include's file and a macro's #define along the kernel include path.
• Hovers show macro values, and each property's final value with what it replaced and where.
• The outline lists the nodes.

A hover on a property: its final value, the file and line that set it last, and the value it replaced in the SoC include.

State: modelled: the merged tree equals dtc 1.6.1's and 1.7.2's on an i.MX 8M Plus gateway board (257 nodes, 1,495 properties, all positions and values) and on NXP's imx8mp-evk.dts (linux-imx lf-6.6.52-2.2.0); dt-validate (dtschema 2026.9) run on the board with findings placed; parsers checked on captured cpp, dtc and dtschema output; the build host a local stand-in. Not run against a real SSH build server, with bitbake -e linux-imx, through Kbuild's make dtbs_check, on Windows or on Wind River kernel trees.

Merged tree and checks

• Show Merged Device Tree opens the tree after every include, override and /delete-property/, each value with the file and line that set it. Load from dtc shows dtc's own -T -T tree from the build host instead; Only what ... sets filters to the board file's own lines.
• Check Device Tree with dtc runs cpp and dtc as the kernel's scripts/Makefile.lib does, and Check Device Tree Against Bindings (dtbs_check) runs dt-validate as CHECK_DTBS runs it. Findings land in Problems at the board's lines.

dt-schema findings from the bindings check in Problems, at the lines of the board device tree.

Board device trees in the kernel recipe

• Open Board Device Tree opens the board device trees KERNEL_DEVICETREE names for the machine. Over a remote build host this has taken 512 to 570 seconds (one SSH session per file call, 807 calls for the layer scan, against 79 ms on a local disk): a known issue.
• Add Board Device Tree to the Kernel Recipe... writes the bbappend lines after a confirmation.
• Edit KERNEL_DEVICETREE... shows KERNEL_DEVICETREE with its file and line from bitbake -e and the DTBs in the deploy folder; adding or removing entries writes the bbappend after a confirmation, and BitBake reads it back.

Overlays

State: modelled with dtc and fdtoverlay 1.7.2 on linux-imx lf-6.6.52-2.2.0: the EVK plus NXP's imx8mp-evk-revb4.dtso merged byte-identical to Kbuild's make freescale/imx8mp-evk-revb4.dtb; a base without -@, a wrong label and a wrong path named; U-Boot v2024.04's sandbox ran the generated lines with the i.MX 8M Plus EVK environment to the same tree (and refused without fdt resize); KERNEL_DEVICETREE with file and line and a bbappend edit read back with BitBake 2.8; a QEMU arm64 board's live tree compared; the running app. Not run with U-Boot on an i.MX board, with DTBs built by the kernel recipe (the deploy folder was laid out by hand), on Windows or against a real build server.

1. Open an overlay .dtso and run Apply Device Tree Overlay... (Apply to Base...), then pick the board .dts or a built .dtb.
2. The base and the overlay are built with Kbuild's flags (dtc -@) on the build host and applied with fdtoverlay. The merged tree marks what the overlay added, changed or deleted, at the overlay's lines. Labels the base cannot resolve (a base built without -@) are named at their lines.
3. Write to Boot Configuration... gives the U-Boot fdt addr, fdt resize and fdt apply lines from the build's U-Boot environment, with what it lacks, and writes them into boot.cmd or extlinux.conf in the product layer after a confirmation with the exact lines.
4. Compare with Board... reads /sys/firmware/devicetree/base from a board in Targets, read-only, and compares it with what the build expects.

Agent tools

Reading and checking are read-only tools; every write to the product layer asks first with the exact lines.

Next: Images and partition layout.