PowerPC Device Tree DTS detailed

Original address: http://blog.chinaunix.net/uid-26675482-id-3358038.html

Abstract: The introduction of the device tree reduces the changes required by the kernel to support new hardware, improves code reuse, accelerates the development of Linux support packages, and enables a single kernel image to support multiple systems. As a dynamic between the U-boot and the Linux kernel
Interface, this paper describes the data storage format of the device tree and the source code description syntax, and then analyzes the u-boot to the flat set

Backup tree support settings, the Linux kernel to the device tree parsing process.

Key words: flat device tree; DTS; PowerPC; Linux

IBM, Sun and other manufacturers of servers initially used firmware (a program embedded in the hardware device, with
interface between the software and hardware) for initializing the system configuration, providing the connection between the operating system software and the hardware
Start and run the system. Later, for standardization and compatibility, IBM, Sun, etc. jointly launched the Firmware Interface IEEE 1275
Standards, so that their servers such as IBM PowerPC Pseries,apple Powerpc,sun SPARC are all using the open
Firmware, the device tree information of the system hardware is passed to the kernel at runtime, and the system starts and runs [1]. Such
The benefits of doing this include reducing the kernel's heavy reliance on system hardware, facilitating the development of support packages, and reducing hardware changes
Requirements and costs, reducing the need for kernel design and compilation.
With the development of the LINUX/PPC64 kernel, the kernel code gradually migrated from the original ARCH/PPC32 and ARCH/PPC64 to
Unified Arch/powerpc Directory and introduces the open Firmware API to the kernel code to use the standard firmware interface [2].
When the Linux kernel is running, you need to know some information about the hardware. For a compiler that uses the ARCH=POWERPC parameter
Kernel mirroring, this information needs to be present in the form of a device tree based on the Open Firmware specification [3]. This allows the kernel to start
Scan Open Firmware provides the device tree to obtain the platform hardware device information, search the matching set
Driver and bind the driver to the device.
In embedded PowerPC, system boot code, such as U-boot, is generally used instead of open Firmware.
The early u-boot used the static data structure in the include/asm-ppc/u-boot.h struct bd_t to pass the basic information of the Board
Pass to the kernel, and the rest is handled by the kernel. Such an interface is not flexible enough, hardware changes will require the re-customization of the compilation Burn
Write the boot code and kernel, and no longer adapt to the current kernel. In order to adapt to the development of the kernel and embedded PowerPC
Platform of the ever-changing, absorbing the advantages of standard open Firmware, U-boot introduced a flat device tree FDT such
Dynamic interface, using a separate FDT blob (binary large object, is a container that can store binary files)
Stores the parameters passed to the kernel [3]. Some deterministic information, such as cache size, in-circuit breakers, is provided directly from the device tree,
Other information, such as Etsec's MAC address, frequency, and number of PCI buses, is modified by u-boot at runtime.

The u-boot uses a flat device tree instead of the bd_t, and no longer guarantees back-to-bd_t compatibility.

2 Device Tree Concept
Simply put, the device tree is a tree-shaped data structure that describes the hardware configuration and has only one root node [4]. It packs
Contains information about the CPU, physical memory, bus, serial, PHY, and other peripheral devices. The tree inherits the open
Firmware the definition of the IEEE 1275 device tree. The operating system is able to parse this structure at startup, with

Kernel, and load the appropriate driver.

3 Device Tree Storage format
U-boot needs to pass the storage address of the device tree in memory to the kernel. The tree consists of three major parts: Head
(Header), structure block (Structure block), string block (Strings block). Storage of device trees in memory
The storage layout Figure 1 is as follows:
Figure 1 Device Tree storage format diagram
FIG1 the layout of a DT block
3.1 Head (header)
The header mainly describes the basic information of the device tree, such as the device Tree magic number flag, the device tree block size, the structure block's offset address
And so on, its concrete structure boot_param_header as follows. The values in this structure are represented in the big-endian mode, and the offset
The address is calculated relative to the start address of the device tree header.
3.2 Structure block (structure block)
Flat device a tree block is a linear tree structure, which, together with a string block, makes up the body of the device tree, with nodes
Format to save device information for the target board. In the structure block, the node start flag is a constant-value macro Of_dt_begin_node,
The node end flag is the macro Of_dt_end_node, and the child node is defined before the node end flag. A node can be generalized
Include the node path, the attribute list, the child node list, and finally the Of_dt_begin_node, starting with
Of_dt_end_node the end of the sequence, each child node itself is a similar structure.
3.3 String Blocks (Strings block)
In order to save space, some property names, especially those repeated redundancy occurrences, are extracted and stored separately.
to a string block. This block contains a number of property name strings that have a closing flag. stored in the structure block of the device tree
The offset addresses of these strings, which makes it easy to find the property name string. The introduction of string blocks saves the embedded

More intense storage space in the system.

4 Device Tree Source DTS representation
Device tree source file (. dts) describes the system hardware configuration device tree in readable, editable text form
method, the structure has a unique root node "/", each node has its own name and can contain multiple
Child nodes. The data format of the device tree follows the open Firmware IEEE standard 1275. This article describes only the device tree
Data layout and syntax, LINUX Board Support package developers should refer in detail to the IEEE 1275 standard [5] and other references [2] [4].
To illustrate, the first example of a device tree source code based on the minimum system of the PowerPC mpc8349e processor is given.
As you can see, there are many nodes in this device tree, and each node specifies the node cell name. Each property is followed by a
Give the corresponding value. The contents quoted in double quotation marks are ASCII strings, with angle brackets given in 32-bit 16 binary
Value. This tree structure is a simplified collection of nodes and attributes required to start the Linux kernel, including the basic mode of the root node
Information, CPU, and physical memory layouts, which also include command-line parameter information passed to the kernel through the/chosen node.
/ {
Model = "MPC8349EMITX";
compatible = "Mpc8349emitx", "Mpc834xmitx", "MPC83XXMITX";
#address-cells = <1>; /* 32bit Address */
#size-cells = <1>; /* 4GB Size */
CPUs {
#address-cells = <1>;
#size-cells = <0>;
powerpc,8349@0 {
Device_type = "CPU";
Reg = <0>;
D-cache-line-size = <20>; /* Bytes */
I-cache-line-size = <20>;
D-cache-size = <8000>; /* L1 Dcache, 32K */
I-cache-size = <8000>;
Timebase-frequency = <0>; /* FROM Bootloader */
Bus-frequency = <0>;
Clock-frequency = <0>;
};
};
Memory {
Device_type = "Memory";
Reg = <00000000 10000000>; /* 256MB */
};
Chosen {
Name = "Chosen";
Bootargs = "Root=/dev/ram rw console=ttys0,115200";
Linux,stdout-path = "/soc8349@e0000000/serial@4500";
};
};
4.1 Root Nodes
The starting point of the device tree is called the root node "/". The property model indicates the name of the target Board platform or module, and the properties
The compatible value indicates that the target board is the same series of compatible Development Board names. For most 32-bit platforms, the properties
The values for the #address-cells and #size-cells are typically 1.
4.2 CPU Nodes
The/cpus node is the child node of the root node and has a corresponding node for each CPU in the system. /cpus node
There are no attributes that must be specified, but #address-cells = <1> and #size-cells = <0> is a good habit, which also means
The reg attribute format for each CPU node facilitates the physical CPU number.
This node should contain the properties of each CPU on the board. CPU name General writing Powerpc,<name>
Freescale uses powerpc,8349 to describe the mpc8349e processor in this article. The cell name of the CPU node should be
cpu@0 format, this node typically specifies device_type (fixed as "CPU"), primary data/instruction cache table entries
Size, level of data/instruction cache size, core, bus clock frequency, etc. In the example above, booting through the system
The code dynamically fills in the clock-frequency correlation.
4.3 System memory Nodes
This node is used to describe the range of physical memory on the target board, commonly referred to as the/memory node, and can have one or more.
When there are multiple nodes, it needs to be distinguished by the address of the cell, and only one cell address, the cell address can not be written,
The default is 0.
This node contains the properties of the physical memory on the board, typically specifying Device_type (fixed to "memory") and Reg
Property. Where the property value of Reg is given in the form of < start address space size >, as in the example above, the target board memory start
The address is 0 and the size is 256M bytes.
4.4/chosen node
This node is a bit special. Typically, this is where the open Firmware stores variable environmental information, such as parameters,
Default input.
The Bootargs and Linux,stdout-path attribute values are typically specified in this node. The Bootargs property is set to pass to the inside
The argument string for the kernel command line. Linux,stdout-path are often the node path names of standard terminal devices, which are used by the kernel to
As the default terminal.
U-boot added support for the flat device tree FDT after the 1.3.0 release, u-boot loading the Linux kernel,
Ramdisk file System (if used) and device tree binary mirroring to physical memory, after starting the execution of Linux
Before the kernel, it modifies the device tree binaries. It fills in the necessary information into the device tree, such as the MAC address,
Number of PCI buses. U-boot also fills in the "/chosen" node in the device tree file, including the serial, root
Device (Ramdisk, hard drive, or NFS boot).
4.5 on-chip system SOC Nodes
This node is used to describe the on-chip system SOC, which must exist if the processor is a soc. Top-Level SOC Section
The information contained in the point is visible to all devices on this soc. The node name should contain the cell address of this SOC, which is the SOC
The base address of the memory-mapped register. The SOC node name is named in/soc<socname>, such as the MPC8349 Soc
The node is "soc8349".
Attributes such as device_type (fixed to SOC), ranges, bus-frequency should be specified in the properties. Ranges
The property values are specified as <bus_addr parent_bus_addr size>. The SOC node also contains each of the objects used by the target board
Soc device subnodes, which should describe the peripheral devices on this SOC in as much detail as possible in the device tree. The following is given with
Example of the SOC node DTS for the watchdog device.
soc8349@e0000000 {