Incomputing, adevicetree (also writtendevice tree) is adata structure describing the hardware components of a particular computer so that theoperating system'skernel can use and manage those components, including theCPU or CPUs, thememory, thebuses and theintegrated peripherals.
The device tree was derived fromSPARC-based andPowerPC-based computers via theOpen Firmware project. The current Devicetree specification[1]is targeted at smaller systems and embedded systems, but is still used with some server-class systems (for instance, those described by thePower Architecture Platform Reference).
Personal computers with thex86 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 inEEPROM, or stored in NAND device likeeUFS) to the operating system, but can also generate a device tree in the early stages ofbooting. As an example,Das U-Boot andkexec 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; theLinux kernel supports this approach.
The Devicetree specification is currently managed by a community nameddevicetree.org, which is associated with, among others,Linaro andArm.
A device tree can hold any kind of data as internally it is atree of named nodes andproperties. Nodes contain properties and child nodes, while properties arename–value pairs.
Device trees have both abinary format for operating systems to use and a textual format for convenient editing and management.[1]
Given the correct device tree, the same compiled kernel can support different hardware configurations within a wider architecture family. TheLinux kernel for theARC,ARM,C6x,H8/300,MicroBlaze,MIPS, NDS32,Nios II,OpenRISC,PowerPC,Power ISA,RISC-V,SuperH, andXtensa architectures reads device tree information; on ARM, device trees have been mandatory for all newSoCs since 2012.[2] 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 theboot loader, replacing a range of board-specificCsource files and compile-time options in the kernel.[2]
It is specified in a Devicetree Source file (.dts) and is compiled into a Devicetree Blob or device tree binary (.dtb) file through the Devicetree compiler (DTC). Device tree source files caninclude other files, referred to as device tree source includes.[3][1]
It has been customary for ARM-basedLinux distributions to include a boot loader, that necessarily was customized for specific boards, for exampleRaspberry 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. However, some modern SoCs (for example,Freescale i.MX6) have a vendor-provided boot loader with device tree on a separate chip from the operating system.[4]
A proprietary configuration file format used for similar purposes, the FEX file format,[5] is ade facto standard amongAllwinner SoCs.
Devicetree is widely used for ARM-basedAndroid devices.
Windows does not use DeviceTree (DTB file) as described here. Instead, it usesACPI to discover and manage devices.[6]
On the boot process ofiOS,iPadOS and ARMmacOS, the Low Level Bootloader (LLB) will load Apple-encrypted devicetree to main memory, then loadsiBoot.
Thecoreboot project makes use of device trees, but they are different from the flattened device trees used in the Linux kernel.[7]
Example of Devicetree Source (DTS) format:
/dts-v1/;/{soc{flash_controller:flash-controller@4001e000{reg=<0x4001e0000x1000>;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 andflash@0 (instance of flash which uses the flash controller). Besides thesenode names, the latter two nodes havelabelsflash_controller andflash0 respectively.
The latter two nodes haveproperties, which represent name/value pairs. Propertylabel has string type, propertyerase-block has integer type and propertyreg is an array of integers (32-bit unsigned values). Property values can refer to other nodes in the devicetree by theirphandles. Phandle for a node with labelflash0 would be written as&flash0. Phandles are also 32-bit values.
Parts of the node names after the "at" sign (@) areunit 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 orassembly. InZephyr RTOS, however, DTS files are compiled intoC header files (.h), which are then used by the build system to compile code for a specificboard.[8]
{{cite book}}: CS1 maint: location missing publisher (link){{cite book}}: CS1 maint: location missing publisher (link)
| Processes |  | ||||||
|---|---|---|---|---|---|---|---|
| Bootingfirmware |
| ||||||
| Hybrid firmware bootloader | |||||||
| Bootloaders |
| ||||||
| Partition layouts | |||||||
| Partitions | |||||||
| Utilities |
| ||||||
| Network boot | |||||||
| ROM variants | |||||||
| Related | |||||||