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 CPU or CPUs, the memory, the buses and the integrated peripherals.
The device tree was derived from SPARC-based computers via the Open 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 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.
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]
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 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 can include other files, referred to as device tree source includes. [3] [1]
It has been 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. 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 a de facto standard among Allwinner SoCs.
Devicetree is widely used for ARM-based Android devices.
Windows (except for Windows CE) does not use DeviceTree (DTB file) as described here. Instead, it uses ACPI to discover and manage devices. [6]
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.
The coreboot 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
and flash@0
(instance of flash which uses the flash controller). Besides these node names, the latter two nodes have labelsflash_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 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. [8]
In computing, BIOS is firmware used to provide runtime services for operating systems and programs and to perform hardware initialization during the booting process. The firmware comes pre-installed on the computer's motherboard.
In computing, firmware is software that provides low-level control of computing device hardware. For a relatively simple device, firmware may perform all control, monitoring and data manipulation functionality. For a more complex device, firmware may provide relatively low-level control as well as hardware abstraction services to higher-level software such as an operating system.
Hardware abstractions are sets of routines in software that provide programs with access to hardware resources through programming interfaces. The programming interface allows all devices in a particular class C of hardware devices to be accessed through identical interfaces even though C may contain different subclasses of devices that each provide a different hardware interface.
Unified Extensible Firmware Interface is a specification that defines an architecture for the platform firmware used for booting a computer's hardware and its interface for interaction with the operating system. Examples of firmware that implement the specification are AMI Aptio, Phoenix SecureCore, TianoCore EDK II, InsydeH2O.
udev is a device manager for the Linux kernel. As the successor of devfsd and hotplug, udev primarily manages device nodes in the /dev directory. At the same time, udev also handles all user space events raised when hardware devices are added into the system or removed from it, including firmware loading as required by certain devices.
QEMU is a free and open-source emulator. It emulates a computer's processor through dynamic binary translation and provides a set of different hardware and device models for the machine, enabling it to run a variety of guest operating systems. It can interoperate with Kernel-based Virtual Machine (KVM) to run virtual machines at near-native speed. QEMU can also do emulation for user-level processes, allowing applications compiled for one processor architecture to run on another.
coreboot, formerly known as LinuxBIOS, is a software project aimed at replacing proprietary firmware found in most computers with a lightweight firmware designed to perform only the minimum number of tasks necessary to load and run a modern 32-bit or 64-bit operating system.
In computer science, execute in place (XIP) is a method of executing programs directly from long-term storage rather than copying it into RAM. It is an extension of using shared memory to reduce the total amount of memory required.
Advanced Configuration and Power Interface (ACPI) is an open standard that operating systems can use to discover and configure computer hardware components, to perform power management, auto configuration, and status monitoring. It was first released in December 1996. ACPI aims to replace Advanced Power Management (APM), the MultiProcessor Specification, and the Plug and Play BIOS (PnP) Specification. ACPI brings power management under the control of the operating system, as opposed to the previous BIOS-centric system that relied on platform-specific firmware to determine power management and configuration policies. The specification is central to the Operating System-directed configuration and Power Management (OSPM) system. ACPI defines hardware abstraction interfaces between the device's firmware, the computer hardware components, and the operating systems.
In Linux systems, initrd
is a scheme for loading a temporary root file system into memory, to be used as part of the Linux startup process. initrd
and initramfs
refer to two different methods of achieving this. Both are commonly used to make preparations before the real root file system can be mounted.
The ETRAX CRIS is a RISC ISA and series of CPUs designed and manufactured by Axis Communications for use in embedded systems since 1993. The name is an acronym of the chip's features: Ethernet, Token Ring, AXis - Code Reduced Instruction Set. Token Ring support has been taken out from the latest chips as it has become obsolete.
The Apple–Intel architecture, or Mactel, is an unofficial name used for Macintosh personal computers developed and manufactured by Apple Inc. that use Intel x86 processors, rather than the PowerPC and Motorola 68000 ("68k") series processors used in their predecessors or the ARM-based Apple silicon SoCs used in their successors. As Apple changed the architecture of its products, they changed the firmware from the Open Firmware used on PowerPC-based Macs to the Intel-designed Extensible Firmware Interface (EFI). With the change in processor architecture to x86, Macs gained the ability to boot into x86-native operating systems, while Intel VT-x brought near-native virtualization with macOS as the host OS.
Das U-Boot is an open-source boot loader used in embedded devices to perform various low-level hardware initialization tasks and boot the device's operating system kernel. It is available for a number of computer architectures, including M68000, ARM, Blackfin, MicroBlaze, AArch64, MIPS, Nios II, SuperH, PPC, RISC-V and x86.
A live USB is a portable USB-attached external data storage device containing a full operating system that can be booted from. The term is reminiscent of USB flash drives but may encompass an external hard disk drive or solid-state drive, though they may be referred to as "live HDD" and "live SSD" respectively. They are the evolutionary next step after live CDs, but with the added benefit of writable storage, allowing customizations to the booted operating system. Live USBs can be used in embedded systems for system administration, data recovery, or test driving, and can persistently save settings and install software packages on the USB device.
The EFIsystem partition or ESP is a partition on a data storage device that is used by computers that have the Unified Extensible Firmware Interface (UEFI). When a computer is booted, UEFI firmware loads files stored on the ESP to start operating systems and various utilities.
In BSD-derived computer operating systems and in related operating systems such as SunOS, a disklabel is a record stored on a data storage device such as a hard disk that contains information about the location of the partitions on the disk. Disklabels were introduced in the 4.3BSD-Tahoe release. Disklabels are usually edited using the disklabel utility. In later versions of FreeBSD, this was renamed as bsdlabel.
In the context of free and open-source software, proprietary software only available as a binary executable is referred to as a blob or binary blob. The term usually refers to a device driver module loaded into the kernel of an open-source operating system, and is sometimes also applied to code running outside the kernel, such as system firmware images, microcode updates, or userland programs. The term blob was first used in database management systems to describe a collection of binary data stored as a single entity.
The Linux booting process involves multiple stages and is in many ways similar to the BSD and other Unix-style boot processes, from which it derives. Although the Linux booting process depends very much on the computer architecture, those architectures share similar stages and software components, including system startup, bootloader execution, loading and startup of a Linux kernel image, and execution of various startup scripts and daemons. Those are grouped into 4 steps: system startup, bootloader stage, kernel stage, and init process. When a Linux system is powered up or reset, its processor will execute a specific firmware/program for system initialization, such as the power-on self-test, invoking the reset vector to start a program at a known address in flash/ROM, then load the bootloader into RAM for later execution. In IBM PC–compatible personal computers (PCs), this firmware/program is either a BIOS or a UEFI monitor, and is stored in the mainboard. In embedded Linux systems, this firmware/program is called boot ROM. After being loaded into RAM, the bootloader will execute to load the second-stage bootloader. The second-stage bootloader will load the kernel image into memory, decompress and initialize it, and then pass control to this kernel image. The second-stage bootloader also performs several operation on the system such as system hardware check, mounting the root device, loading the necessary kernel modules, etc. Finally, the first user-space process starts, and other high-level system initializations are performed.
ELinOS is a commercial development environment for embedded Linux. It consists of a Linux distribution for the target embedded system and development tools for a development host computer. The development host computer usually is a standard desktop computer running Linux or Windows. The Linux system and the application software for the target device are both created on the development host.
Zephyr is a small real-time operating system (RTOS) for connected, resource-constrained and embedded devices supporting multiple architectures and released under the Apache License 2.0. Zephyr includes a kernel, and all components and libraries, device drivers, protocol stacks, file systems, and firmware updates, needed to develop full application software.
{{cite book}}
: CS1 maint: location missing publisher (link){{cite book}}
: CS1 maint: location missing publisher (link)