In computing, a devicetree (also written device tree) is a data structure describing the hardware components of a particular computer so that the operating system's kernel can use and manage those components, including the CPUs or SoC, the memory, the storage, the buses and the integrated peripherals.
The devicetree originated as part of the Open Firmware project for SPARC-based and PowerPC-based computers, withdrawn in 2005. In 2016, a stand-alone Devicetree specification was developed by simplifying and modernizing the old specifications. Its target has switched to smaller systems and embedded systems,[1] but is still used with some server-class systems (for instance, those described by the Power Architecture Platform Reference).
Personal computers with the x86 architecture generally do not use device trees, relying instead on various auto configuration protocols (e.g. ACPI) to discover hardware. Systems which use device trees usually pass a static device tree (perhaps stored in EEPROM, or stored in NAND device like eUFS) to the operating system, but can also generate a device tree in the early stages of booting. As an example, Das U-Boot and kexec can pass a device tree when launching a new operating system. On systems with a boot loader that does not support device trees, a static device tree may be installed along with the operating system; the Linux kernel supports this approach.
The Devicetree specification is currently managed by a community named devicetree.org, which is associated with, among others, Linaro and Arm.
Formats
A device tree can hold any kind of data as internally it is a tree of named nodes and properties. Nodes contain properties and child nodes, while properties are name–value pairs. Node and property names are by convention ASCII. Values are byte strings of any length (with no data type label in the binary format).
Modern device trees are authored in a textual format (Devicetree Source file, .dts). A compiler (DTC) is used to convert it into the binary format (device tree binary/blob, .dtb) used by operating systems.[1] The dtb is also known as the flattened device tree (FDT).[2] Device tree source files can include other files, referred to as device tree source includes.[3][1] The FDT is part of the original Open Firmware specification.[4]
Usage
Linux
Given the correct device tree, the same compiled kernel can support different hardware configurations within a wider architecture family. The Linux kernel for the ARC, ARM, C6x, H8/300, MicroBlaze, MIPS, NDS32, Nios II, OpenRISC, PowerPC, Power ISA, RISC-V, SuperH, and Xtensa architectures reads device tree information; on ARM, device trees have been mandatory for all new SoCs since 2012.[5] This can be seen as a remedy to the vast number of forks (of Linux and Das U-Boot) that have historically been created to support (marginally) different ARM boards. The purpose is to move a significant part of the hardware description out of the kernel binary, and into the compiled device tree blob, which is handed to the kernel by the boot loader, replacing a range of board-specific C source files and compile-time options in the kernel.[5]
It used to be customary for ARM-based Linux distributions to include a boot loader that necessarily was customized for specific boards, for example Raspberry Pi or Hackberry A10. This has created problems for the creators of Linux distributions as some part of the operating system must be compiled specifically for every board variant, or updated to support new boards. Some modern SoCs (for example, Freescale i.MX6) instead have a vendor-provided boot loader with device tree on a separate chip from the operating system.[6]
A proprietary configuration file format used for similar purposes, the FEX file format,[7] is a de facto standard among Allwinner SoCs.
Devicetree is widely used for ARM-based Android devices.
BSD
FreeBSD supports device trees as part of its Open Firmware support.[4]
Windows
Windows does not use Devicetree (DTB file) as described here. Instead, it uses ACPI to discover and manage devices.[8]
Apple
On the boot process of iOS, iPadOS and ARM macOS, the Low-Level Bootloader (LLB) will load Apple-encrypted devicetree to main memory, then loads iBoot. Apple does not use the standard DTB/FDT format; instead, it uses various Apple Device Tree (ADT) formats such as IMG3 and IM4P.[9] The current (as of 2026) generation of ADT, IM4P, mainly differs from DTB in terms of the endianness of its data. The Asahi Linux project provides tools for adapting IM4P to Linux.[10]
Coreboot
The coreboot project has a concept of "device trees" with an analogous purpose, but it is independent from the OpenFirmware/DT.org standard device tree format.[11] It is for use by coreboot itself, which boots before any operating system, and generally deals with earlier/lower-level steps of hardware initialization and the generation of ACPI tables.[12][13]
Example
Example of Devicetree Source (DTS) format:
/dts-v1/;
/ {
soc {
flash_controller: flash-controller@4001e000 {
reg = <0x4001e000 0x1000>;
flash0: flash@0 {
label = "SOC_FLASH";
erase-block = <4096>;
};
};
};
};
In the example above, the line /dts-v1/; signifies version 1 of the DTS syntax.
The tree has four nodes: / (root node), soc (stands for "system on a chip"), flash-controller@4001e000 and flash@0 (instance of flash which uses the flash controller). Besides these node names, the latter two nodes have labels flash_controller and flash0 respectively.
The latter two nodes have properties, which represent name/value pairs. Property label has string type, property erase-block has integer type and property reg is an array of integers (32-bit unsigned values). Property values can refer to other nodes in the devicetree by their phandles. Phandle for a node with label flash0 would be written as &flash0. Phandles are also 32-bit values.
Parts of the node names after the "at" sign (@) are unit addresses. Unit addresses specify a node's resource address in the address space of its parent node.
The above tree could be compiled by the standard DTC compiler to binary DTB format or assembly. In Zephyr RTOS, however, DTS files are compiled into C header files (.h), which are then used by the build system to compile code for a specific board.[14]
See also
References
- 1 2 3 "Devicetree specification" (PDF). Release v0.4. devicetree.org. 2023-06-28.
- ↑ "Kernel parameters using Flattened Device Trees". Arm Developer.
- ↑ Simmonds, Chris (2017). Mastering embedded Linux programming : unleash the full potential of embedded Linux (Second ed.). Birmingham, UK. ISBN 978-1-78728-885-0. OCLC 995052708.
{{cite book}}: CS1 maint: location missing publisher (link) - 1 2 "FDT". man.freebsd.org. Retrieved 2025-09-12.
- 1 2 "ARM SoC Linux support checklist" (PDF).
- ↑ "u-boot update for Ezurio's boards". 2013-11-08.
- ↑ "Fex Guide". linux-sunxi.org. 2014-05-30. Retrieved 2014-06-12.
- ↑ "The Windows ACPI Driver". microsoft.com. 2021-12-14. Retrieved 2022-09-19.
- ↑ "DeviceTree". The Apple Wiki. 2025-09-23.
- ↑ "Apple Device Tree (ADT) - Asahi Linux Documentation". asahilinux.org.
- ↑ Sun, Jiming (2015). Embedded firmware solutions: development best practices for the internet of things. Vincent Zimmer, Marc Jones, Stefan Reinauer. [United States]. p. 82. ISBN 978-1-4842-0070-4. OCLC 902804314.
{{cite book}}: CS1 maint: location missing publisher (link) - ↑ "Devicetree — coreboot 26.06-918-g9c046665387 documentation". doc.coreboot.org.
- ↑ "Adding new devices to a device tree — coreboot 26.06-918-g9c046665387 documentation". doc.coreboot.org.
- ↑ "Introduction to devicetree – Zephyr Project Documentation". 2.6.0. Zephyr Project. 2021-06-05.
External links
- Official website
- Device Tree Reference – eLinux.org
- Embedded Power Architecture Platform Requirements (ePAPR)
- About The Device Tree
| Processes |  | ||||||
|---|---|---|---|---|---|---|---|
| Booting firmware |
| ||||||
| Hybrid firmware bootloader | |||||||
| Bootloaders |
| ||||||
| Partition layouts | |||||||
| Partitions | |||||||
| Utilities |
| ||||||
| Network boot | |||||||
| ROM variants | |||||||
| Related | |||||||