Device tree

In computing, a device tree (also written devicetree) 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 CPU or CPUs, the memory, the buses and the peripherals.

Not to be confused with Device file system.

The device tree was derived from SPARC-based computers via the Open Firmware project. The current Devicetree specification[1] is targeted at smaller systems, 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 ROM) 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.

Device Tree 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.

Device trees have both a binary format for operating systems to use and a textual format for convenient editing and management.[1]

Usage in 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, RISC-V, SuperH, and Xtensa architectures reads device tree information; on ARM, device trees have been mandatory for all new SoCs 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 the boot loader, replacing a range of board-specific C source files and compile-time options in the kernel.[2]

It has been customary for ARM-based Linux distributions to include a boot loader, that necessarily was customised 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. 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.[3]

A proprietary configuration file format used for similar purposes, the FEX file format,[4] is a de facto standard among Allwinner SoCs.

Usage in Windows

In Windows, an ACPI device tree is maintained by the Plug-and-Play manager to evaluate things like whether devices can be safely ejected.[5]

See also

References
  1. "Devicetree specification" (PDF). Release v0.3. devicetree.org. 2020-02-13.
  2. "ARM SoC Linux support checklist" (PDF).
  3. "u-boot update for Boundary Devices' boards".
  4. "Fex Guide". linux-sunxi.org. 2014-05-30. Retrieved 2014-06-12.
  5. Hudek, Ted; Sherer, Tim (2017-06-16). "Device Tree - Windows drivers". docs.microsoft.com. Microsoft. Retrieved 2020-02-08.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.