Reprint address: http://blog.csdn.net/smcdef/article/details/77387975
1. Introduction to device tree
Linus Torvalds declared in the ARM Linux mailing list on March 17, 2011 that "this whole ARM thing is a fusing pain in the ass", which triggered an earthquake in the ARM Linux community, and then the ARM community made a series of major amendments. In the past ARM Linux, arch / ARM / plat XXX and arch / ARM / Mach XXX were filled with a large amount of garbage code. A considerable number of codes only described board level details, which were just garbage for the kernel, such as platform devices, resource s and I2C on the board_ board_ info,spi_board_info and various hardware platforms_ data. The community must change this situation, so the flatted Device Tree (FDT) already used under other architectures such as PowerPC has entered the vision of the ARM community. Device Tree is a data structure describing hardware, which originated from OpenFirmware(OF). In Linux 2.6, the board hardware details of ARM architecture are too hard coded in arch / ARM / plat XXX and arch / ARM / Mach XXX. After using Device Tree, many hardware details can be directly transmitted to Linux through it without a lot of redundant coding in the kernel.
Device Tree is composed of a series of named nodes and properties, and the node itself can contain child nodes. The so-called attribute is actually a pair of name and value. In the Device Tree, the describable information includes (previously, most of these information was hard code d into the kernel):
- Number and category of CPU s
- Memory base address and size
- Bus and Bridge
- Peripheral connection
- Interrupt controller and interrupt usage
- GPIO controller and GPIO usage
It basically draws a tree composed of CPU, bus and equipment on the circuit board. The Bootloader will pass the tree to the kernel, and then the kernel can identify the tree and expand the platform in the Linux kernel according to it_ device,i2c_client,spi_device and other devices. The memory, IRQ and other resources used by these devices are also passed to the kernel, which will bind these resources to the corresponding deployed devices.
2. Device Tree compilation
The format of Device Tree file is dts, and the format of header file is dtsi. dts file is an encoding format that people can understand. But uboot and Linux can't recognize directly. They can only recognize binary files, so they need to compile dts files into dtb files. dtb file is a binary file that can be recognized by kernel and uboot. The tool for compiling dts into dtb files is dtc. The scripts/dtc directory under the Linux source directory contains the source code of dtc tools. In addition to providing dtc tools in the scripts/dtc directory of Linux, you can also install dtc tools yourself. Execute sudo apt get install Device Tree compiler under Linux to install dtc tools. It also provides a tool of fdtdump, which can decompile dtb files. The transformation of dts and dtb files is shown in Figure 1.
The use method of dtc tool is: dtc – I dts – O dtb – o xxx.dtb xxx.dts to generate the DTB file corresponding to the DTS file. 
3. Device Tree header information
Use the fdtdump tool, execute ftddump – h on the Linux terminal, and output the following information:
fdtdump -h
Usage: fdtdump [options]
Options: -[dshV]
-d, –debug Dump debug information while decoding the file
-s, –scan Scan for an embedded fdt in file
-h, –help Print this help and exit
-V, –version Print version and exit
This paper adopts s5pv21_smc.dtb file as an example to illustrate the use of fdtdump tool. Linux terminal execution fdtdump – SD s5pv21_smc.dtb > s5pv21_smc.txt, open s5pv21_smc.txt file, some output information is as follows:
// magic: 0xd00dfeed
// totalsize: 0xce4 (3300)
// off_dt_struct: 0x38
// off_dt_strings: 0xc34
// off_mem_rsvmap: 0x28
// version: 17
// last_comp_version: 16
// boot_cpuid_phys: 0x0
// size_dt_strings: 0xb0
// size_dt_struct: 0xbfc
The above information is the header information of the Device Tree file, which is stored at the beginning of the dtb file. Using struct FDT in Linux kernel_ Header structure description. struct fdt_ The header structure is defined in the scripts\dtc\libfdt\fdt.h file.
The output information of the fdtdump tool is the value of each member in the above structure, struct fdt_ The header structure contains the private information of the Device Tree. For example: fdt_header.magic is the magic number of fdt. The fixed value is 0xd00dfeed, fdt_header.totalsize is the size of the fdt file. Open s5pv21 using binary tools_ Smc.dtb validation. s5pv21_ The header information of the smc.dtb binary file is shown in Figure 2. It can be seen from Figure 2 that the file of Device Tree is stored in big end mode. Moreover, the header information is consistent with the output information of fdtdump. 
An example of node information in the Device Tree is shown in Figure 3. 
The above. dts file has no real purpose, but it basically represents the structure of a Device Tree source file. 1 root node "/"; There are a series of child nodes under the root node. In this example, it is " node@0 ”And " node@1 ”； "Node" node@0 ”The following contains a series of child nodes, in this case "child"- node@0 ”； Each node has a series of attributes. These properties may be empty, such as "an empty property"; It may be A string, such as "a-string-property"; It may be A string array, such as "a-string-list-property"; It may be Cells (composed of u32 integers), such as "second child property", or binary numbers, such as "a-byte-data-property". The structure of the Device Tree source file is divided into header and fill_area,dt_struct and dt_string four regions. Header is the header information, fill_area is the filled area, filled with the number 0, dt_struct stores node value and name related information, dt_string stores the property name. For example, a-string-property is stored in dt_string area, "A string" and node1 are stored in dt_struct area.
We can add a label to a device node, and then access the label in the form of & label. This reference is made through the phase (pointer handle). For example, node1 in Figure 3 is a label, node@0 Child of- node@0 Reference via & node1 node@1 Node. For a node like this phase, after being compiled by the DTC tool, & node1 will become a special integer number n. assuming that the value of n is 1, then node@1 Two attributes are automatically generated under the node. The attributes are as follows:
linux,phandle = <0x00000001>;
phandle = <0x00000001>;
node@0 Child of- node@0 A-reference-to-something = < & node1 > in becomes a-reference-to-something = < 0x00000001 >. 0x00000001 here is the value of a phase. Each phase has a unique integer value. The referenced node is indirectly found in the subsequent kernel through this special number. By viewing the output information of FDT dump and the information of dtb binary file, the struct FDT is obtained_ The relationship information between header and file structure is shown in. 
4. Device Tree file structure
Through the above analysis, the Device Tree file structure can be obtained, as shown in Figure 5. The first thing stored in the head of dtb is FDT_ The structure information of the header, followed by the filling area, and the filling size is off_dt_struct – sizeof(struct fdt_header), the filled value is 0. Then struct fdt_property structure. Finally, dt_string part. 
The structure of the Device Tree source file is divided into header and fill_area,dt_struct and dt_string four regions. fill_ The area area is filled with a value of 0. The node information uses struct fdt_node_header structure description. Use struct FDT for attribute information_ Property structure description. The information of each structure is as follows:
struct fdt_node_header describes node information. Tag is a flag bit identifying the start and end of node, and name points to the first address of node name. The values of tag are as follows:
FDT_BEGIN_NODE and FDT_END_NODE identifies the start and end of node node, FDT_PROP identifies the attribute initiator under the node node, FDT_END identifies the end identifier of the Device Tree. Therefore, the tag identifier for each node node is generally FDT_BEGIN_NODE, the tag identifier of the attribute under each node node is generally FDT_PROP.
The description attribute adopts struct fdt_property description, tag ID is a property, and the value is FDT_PROP； len is the length of the attribute value (including '\ 0', unit: bytes); nameoff is the attribute name, and the storage location is relative to off_ dt_ Offset address of strings.
For example: compatible = "sampling, GONI", "sampling, s5pv210"; Compatible is the attribute name, "sampling, GONI" and "sampling, s5pv210" is the attribute value. The storage area of the compatible property name string is dt_string. ” The storage location of "sampling, GONI" and "sampling, s5pv210" is FDT_ After property.data. So fdt_property.data points to the property value. fdt_ The value of property.tag is the property ID, and Len is the length of the property value (including '\ 0', unit: bytes), where len = 29. Nameoff is the position of the compatible string relative to off_ dt_ Offset address of strings, i.e. & compatible = nameoff + off_dt_strings.
dt_ The structure of struct in Device Tree is shown in Figure 6. The nesting of nodes also leads to the nesting of tag identifiers. 
5. kernel parsing Device Tree
The Device Tree file structure is described in the above struct fdt_header,struct fdt_node_header and struct fdt_property three structure descriptions. The kernel will parse the struct property structure that can be used by the kernel according to the structure of the Device Tree. The kernel parses the data according to all the properties in the Device Tree and fills in the struct property structure. The struct property structure is described as follows:
In general, the kernel converts the file structure information of the Device Tree into a struct property structure, and links all the properties under the same node through the property.next pointer to form a single linked list.
How to parse the Device Tree in the kernel? Let's analyze the function parsing process. The function calling process is shown in Figure 7. The entry function of the C language phase of the kernel is init/main.c/stsrt_kernel() function, in early_init_dt_scan_nodes() does the following three things:
- Scan / chosen or/ chose@0 The value of the bootargs attribute under the node is to boot_command_line. In addition, it also processes the properties related to initrd and saves them in initrd_start and initrd_end in these two global variables;
- Scan the root node to obtain {size,address}-cells information and save it in dt_root_size_cells and dt_root_addr_cells global variable;
- Scan with device_type = "memory" attribute or/ memory@0 The reg attribute value under the node and save the relevant information in meminfo. The global variable meminfo saves the information related to the system memory.
Each node node in the Device Tree will generate a struct device after being processed by the kernel_ Structure of node, struct device_node is usually attached to a specific struct device structure. struct device_ The node structure is described as follows:
struct device_ The function of each member in the node structure has been annotated with annotation information. Let's analyze how the above information is obtained. The Device Tree is first parsed from unflatten_ device_ Starting with tree(), the code is listed as follows:
Analyze the above code in unflatten_ device_ In tree (), calling function unflatten_device_tree(), parameter initial_boot_params refers to the first address of the Device Tree in memory, of_ After being processed by this function, root will point to the root node, early_init_dt_alloc_memory_arch is a function pointer, which is struct device_node and struct property structures are callback functions that allocate memory. In__ unflatten_ device_ In the tree() function, unflatten is called twice_ dt_ Node() function, the first time is to get the Device Tree converted to struct device_ The memory size to be allocated for node and struct property structures. The second call is to fill each struct device_node and struct property structures__ unflatten_ device_ The tree () code is listed below:
All struct devices are obtained through the above function processing_ Node structure. For each node, a property named "name" will be automatically added. The value of property.length is the name of the current node. Take the last substring between "/" and "@" (including '\ 0'). For example:/ serial@e2900800 , then length = 7, property.value = device_node.name = “serial”.
6. platform_device and device_node binding
After the above analysis, all the data of Device Tree have been parsed into a specific struct device_node and struct property structures need to be bound with specific devices. First, explain the platform_device and device_node binding process. In the arch/arm/kernel/setup.c file, customize_ The machine () function is responsible for populating the struct platform_device structure. The function calling process is shown in Figure 8. 
The code analysis is as follows:
In general, when of_ platform_ After the populate () function is executed, the kernel creates a platform for all the first level nodes in the DTB that contain the compatible attribute name_ Device structure, and register the device information with the platform device bus. If the compatible attribute value of the first level node is equal to "simple bus", "simple MFD" or "arm, AMBA bus", the kernel will continue to create a platform for the second level node containing the compatible attribute of the current node_ Device structure and register the device. Most devices in the Linux system are attached to the platform bus. Therefore, after the platform bus is registered, it will be registered according to the of_ The tree structure of the root node to find the child nodes of the bus. All child nodes will be registered on the bus as devices.
7. i2c_client and device_node binding
After customize_ After the initialization of the machine () function, DTB has been converted to platform_device structure, which contains i2c adapter devices. Different SOCS need to drive i2c adapter devices by means of platform device bus. For example: I2C_ I2C will be called in the probe function driven by adapter_ add_ numbered_ Adapter () registers the adapter driver, and the function flow is executed as shown in Figure 9. 
In of_ i2c_ register_ The devices() function internally facilitates each child node under the I2C node and creates I2C for the child nodes (except those with status = "disable")_ The client structure and the device of the child node_ Node hook. Where I2C_ The client is populated in i2c_new_device(), the last device_register(). Building I2C_ When using client, the vendor name of the compatible attribute name under node will be removed as I2C_ The name of the client. For example, if compatible = "maximum, ds1338", then i2c_client->name = “ds1338”.
8. Device_Tree and sysfs
The kernel startup process is start_kernel()→rest_init()→kernel_thread():kernel_init()→do_basic_setup()→driver_init()→of_core_init() in of_ core_ In the init() function, under the sys/firmware/devicetree/base directory, expand the device tree into the directory and binary property file of sysfs. All node nodes are a directory and all property properties are a binary property file.