Interpretation of Linux Device Tree Decoupling Architecture-V1.0

Terms and Abbreviations

This document uses the following terms and acronyms

Dts: DTS is Device Tree Source, which is a text file used to describe hardware information. Generally, it is fixed information, which cannot be changed or overlayed.

Dtsi: It can be understood as the public part of dts, and it is very flexible to add and change. Dtsi is included in dts.

Dtb: binary compiled by Dtb

Dtbo: Binary compiled by Overlay

dtbo-base: Specifies which dtb is the base to cover the overlay.

Node: the node of the tree

Property: property

1. Introduction to Device Tree

1. Origin of device tree

The linux kernel source code was previously filled with a large number of platform-related (platform Device) configurations, and most of these codes were messy and repetitive, which made the code maintainers and kernel maintainers of the ARM architecture have a hard time when releasing a new version. So much work that Linus Torvalds declared "Gaah.Guys, this whole ARM thing is af*cking pain in the ass" on the ARM Linux mailing list on March 17, 2011, which made the entire ARM community have to reconsider Considering the platform configuration, the Device Tree (DT) was adopted by the ARM community. It should be noted that the device tree was originally part of the communication method used by the development firmware (Open Firmware) to transfer data to the client program (usually an operating system). At runtime, the client program discovers the topology of the device through the device tree, so that hardware information does not need to be hardcoded into the program.

2. The role of the device tree

The device tree is a data structure that describes the hardware, and you can even think of it as a large structure (the structure is the platform, and the members are the specific devices). It should be noted that the device tree cannot solve all hardware configuration problems ( For example: machine recognition), it just provides a language to extract the hardware configuration from the source code of the linux kernel.

The main reasons why Linux uses the device tree are as follows

A: Platform identification

B: Real-time configuration

C: Device Implantation

2. Device tree decoupling target

Target-vendor-related modification is completely independent, and it is forbidden to modify in the original dtsi of the soc, and only allowed to exist in the form of dtbo;

Target 2 is the same as the baseline project dtbo to share binary

3. Device tree decoupling framework design

Device tree identification principle and device tree co-binary principle

The two variables of project number (Project No) and PCB ID are completely matched with the two attributes "dtsi_No" and "pcb_No" in dtbo at the same time, and the corresponding dtbo file can be found. And dtbo can be packaged into dtbo.img through the control of Makefile, so that the co-binary is realized.

4. Device tree code structure

5. Device tree overlay rules

The content of this section is the native rules of the overlay mechanism, which are listed to help driver engineers solve various abnormal problems.

Rule 1: For the setting of the same node, the configuration in dts will override the configuration in dtsi;

Rule 2: For the modification of a node, reference it first and then modify it; for example, the definition of a native node is as follows:

If you need to add a new node to the reserved-memory node or directly modify the properties of the reserved-memory node, you need to reference the reserved_memory node first (note that the reference name of the node and the node name may be inconsistent)

In the above case, the reserved-memory node is referenced, the ranges attribute is deleted, the hyp_mem node is deleted, and the kboot_uboot_logmem node is added;

Rule 3: "&node name" in dtsi will take effect only if the declared node is referenced, otherwise the reference point will not be valid; for example: the fstab node under the firmware node is defined as follows

firmware: The content before ":" in firmware is a reference declaration. It can only be cited elsewhere after being declared. The fstab node under Firmware has no reference statement, so it cannot be referenced in other places. If you want to modify the attributes in the fstab node, refer to the firmware node and then modify the attributes in it, the case is as follows:

For the setting of the same node, the content in the dts file will overwrite the one in dtsi.

 Information through train: Linux kernel source code technology learning route + video tutorial kernel source code

Learning through train: Linux kernel source code memory tuning file system process management device driver/network protocol stack

6. Debugging method

In the process of debugging, if the expectation is not met, you need to determine whether the modification has been compiled into the corresponding dtbo.img, and then you need to decompile dtbo.img

1. Decompilation tool

The decompilation tool code comes with it, and you only need to initialize the environment variables to use it. The initialization instructions are as follows:

2. Decompile dtb.img

dtc-I dtb -O dts dtb.img -o dtsi.txt

3.  Decompile dtbo.img

mkdtimgdump dtbo.img -b dtbo
dtc -I dtb -O dts dtbo.00 -o dtsi.txt

Original Author: Kernel Craftsman
Source: Interpretation of Linux Device Tree Decoupling Architecture-V1.0

 

 

Guess you like

Origin blog.csdn.net/youzhangjing_/article/details/131791600