devicetree
Scannednpx machina-cli add skill beriberikix/zephyr-agent-skills/devicetree --openclawZephyr Devicetree
The Devicetree (DT) is the source of truth for your hardware topology in Zephyr.
Core Workflows
1. Understanding Syntax & Nodes
Nodes, properties, and phandles form the hierarchy.
- Reference: dt_syntax.md
- Key Tools: Labels (
&label), Properties (reg,status,compatible).
2. Working with Bindings
Mapping hardware descriptions to driver schemas.
- Reference: dt_bindings.md
- Key Tools: YAML bindings, compatible strings,
pinctrl.
3. Application Overlays & HWMv2
Modifying board behavior for specific application needs.
- Reference: dt_overlays.md
- Key Tools:
.overlayfiles,zephyr,chosen, variant-specific overlays.
4. Advanced Hardware Modification
Deleting and redefining nodes/properties for product variants.
- Reference: dt_overlays.md
- Key Tools:
/delete-node/,/delete-property/.
Tooling & Validation
west build -t rom_report: See how devicetree definitions impact memory.build/zephyr/zephyr.dts: Inspect the FINAL resolved devicetree after all overlays are applied.scripts/devicetree/gen_defines.py: (Internal) The tool that turns DT into C macros.
Resources
- References:
dt_syntax.md: Core syntax and properties.dt_bindings.md: Binding definitions and compatible mapping.dt_overlays.md: Overlays, HWMv2, and deletion patterns.
Source
git clone https://github.com/beriberikix/zephyr-agent-skills/blob/main/skills/devicetree/SKILL.mdView on GitHub Overview
Devicetree is the single source of truth for Zephyr hardware topology. It organizes nodes, properties, and bindings to map hardware to drivers, supports application overlays and Hardware Model v2 (HWMv2), and enables advanced customization for product variants.
How This Skill Works
Devicetree describes hardware as a hierarchy of nodes and properties, using phandles and labels to reference components. Bindings map hardware descriptions to driver schemas, while overlays and HWMv2 modify the top-level DT without changing base board files. Advanced deletion patterns like /delete-node/ and /delete-property/ let you tailor the DT for variants.
When to Use It
- Defining hardware topology for a new board or MCU
- Applying application-specific behavior via overlays (HWMv2)
- Mapping pins, peripherals, and drivers using bindings and compatible strings
- Creating product variants by deleting/redefining nodes or properties
- Validating the effect of DT changes by inspecting build output (rom_report) and final dt (zephyr.dts)
Quick Start
- Step 1: Review core docs: dt_syntax.md, dt_bindings.md, dt_overlays.md (references section).
- Step 2: Create or modify .overlay files and apply via your board's configuration; use labels, &label references, and compatible strings.
- Step 3: Build and inspect: run west build -t rom_report and check build/zephyr/zephyr.dts for the final DT.
Best Practices
- Start with core references (dt_syntax.md, dt_bindings.md, dt_overlays.md)
- Use YAML bindings and compatible strings to map hardware to drivers
- Leverage .overlay files and HWMv2 for safe, non-destructive changes
- Use /delete-node/ and /delete-property/ only for robust variant customization
- Always validate memory impact with west build -t rom_report and inspect build/zephyr/zephyr.dts
Example Use Cases
- Add a new SPI peripheral using a labeled node and reg properties
- Bind a sensor to a driver via dt_bindings and compatible string
- Create an overlay to enable pinctrl for a specific board variant
- Remove an unused GPIO node in a product variant using /delete-node/
- Review the final resolved DT in build/zephyr/zephyr.dts after applying overlays
