--- title: "Device trees" --- # Device trees Device tree sources with navigation, hovers and the merged tree, checks with dtc and dt-validate as Kbuild runs them, board device trees in the kernel recipe, overlays applied with fdtoverlay, U-Boot overlay lines, and the board's live tree. 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.](https://neuralinverse.com/docs-images/modules/embedded-linux/devicetree-property-hover.webp) **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.](https://neuralinverse.com/docs-images/modules/embedded-linux/devicetree-problems-dtbs-check.webp) ## 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](https://neuralinverse.com/docs/modules/embedded-linux/images/).