Hardware-description preflight

Device Tree DTB/DTS Overlay, Address & Phandle Auditor

Inspect a device tree before handing it to your target. Decode register address tuples, trace phandle references, and preview the effect of ordered overlays with a before/after diff.

Base tree and ordered overlays

No base file selected.

Up to 8 overlays. Files are added in selection order; move them before analysis. A pasted overlay below applies last. Changes invalidate the previous report.

Each file: 8 MiB; DTS: 2 million characters; each parsed/result tree: 8,192 nodes, 32,768 properties and 64 nested levels. Supported binary layout: FDT v17 or later compatible with v17. Includes, macros, expressions and incbin need preprocessing and are never fetched.

Choose a base tree or paste DTS.

File contents, names, tree paths and reports stay in this browser. Inspection runs in a cancellable local worker.

Check device-tree structure and references

A device tree describes hardware through nodes and byte-valued properties. This auditor reads the binary blocks and tokens of DTB files, or a declared subset of preprocessed DTS: nodes, labels, literal cell arrays, strings, byte arrays, /bits/ widths, memory reservations, repeated root blocks, reference blocks, and named child/property deletion. It resolves source labels into synthetic phandles for the preview; numeric assignments may differ from dtc output.

reg uses its immediate parent’s cell widths. ranges combines the child bus address width, its parent’s address width and the child bus size width. Raw values use integer arithmetic without JavaScript number rounding. Generic numeric mappings can reach root address space; PCI flags and other bus-specific encodings remain raw.

The Devicetree specification defines the structure and common properties. The Linux overlay notes and dynamic resolver notes explain fragment targets and phandle fixups.

Supported overlays and validation boundaries

Compiled DTBO fragments use target phandles or target-path strings. External fixups need existing base __symbols__ and valid phandles; local fixups relocate references with definitions. DTS shorthand &label and &{/absolute/path} blocks are also supported. Overlays apply in the displayed order. A failed overlay is discarded atomically, earlier successful overlays remain, and later overlays are skipped. No changes are sent to a kernel or bootloader.

This page does not run a bundled/WASM dtc, preprocess C headers, read include/incbin files, perform dt-schema validation, interpret interrupt-map or arbitrary vendor bindings, validate hardware routing, or export a bootable merged DTB. Overlap findings are review candidates because shared windows may be intentional. Use the board’s build system to preprocess source, dtc -@ -I dts -O dtb to compile symbol-bearing input, and the applicable schema validation workflow for authority.

Common questions

Are #address-cells and #size-cells inherited?

No. A reg property uses the values on its immediate parent. Missing values use the DTSpec defaults of two address cells and one size cell, with a warning. A size-cell count of zero omits the length field.

Can I preview a compiled DTBO overlay?

Yes. The preview resolves target or target-path fragments, external __fixups__ using base __symbols__, and phandle relocation using __local_fixups__. Overlays apply in order. A failed overlay leaves its input tree intact and blocks later overlays.

Does this replace dtc or binding validation?

No. It is a bounded structural and reference auditor. Preprocess includes, macros and expressions first. Check the actual target with dtc and its binding schemas; the browser preview does not load hardware or apply a live kernel overlay.

Are device trees uploaded?

No. Files are read in this browser and inspected in a cancellable local worker. Reports are generated locally.

Related firmware tools

Use the U-Boot FIT inspector for device trees packaged with kernels and firmware, or the legacy U-Boot uImage inspector for older firmware containers.