Shulou(Shulou.com)06/02 Report--

How to carry out Linux device tree transmission and Kernel device tree analysis, in view of this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

The concept of device tree was introduced into the Linux kernel from 3.x, which is used to separate driver code from device information. The concept of device tree did not exist from the very beginning. It appeared in Linus Torvalds in March 2011. For kernel/arch/arm/plat-xxx and kernel/arch/arm/mach-xxx contain a lot of code describing board-level details, the concept of device tree (Device tree) is proposed to solve this phenomenon. Next, I would like to share with you the specific method of transferring Linux device tree.

Transmission of device tree

When using bootm to load a kernel image (bootz is an encapsulation and functional extension of bootm, essentially the same). The entry function for U-Boot to jump to kernel is boot_jump_linux

The C file for this function is under arch/arm/lib, indicating that the way the device tree is passed is related to the SoC architecture. This function is particularly important when different SoC is in bring-up, which is a key API for the connection and exchange of information between U-Boot and kernel. After the execution of this function in U-Boot, complete control of CPU is handed over to kernel.

/ * Subcommand: GO * / static void boot_jump_linux (bootm_headers_t * images, int flag) { Debug ("# # Transferring control to Linux (at address lx)"\ "...\ n", (ulong) kernel_entry); bootstage_mark (BOOTSTAGE_ID_RUN_OS); announce_and_cleanup (fake); if (IMAGE_ENABLE_OF_LIBFDT & & images- > ft_len) R2 = (unsigned long) images- > ft_addr; else R2 = gd- > bd- > bi_boot_params;...}

R2, as a register for storing the address of the device tree, has two ways: instantiating the ft_addr of the data structure bootm_header_t, and using the board-level startup parameters of U-Boot as the address of the device tree.

Bootm_header_t mode

The data structure bootm_header_t is defined as follows and is used by various kernel SoC. Each manufacturer instantiates each member according to the characteristics of its own CPU.

/ * * Legacy and FIT format headers used by do_bootm () and do_bootm_ () * routines.*/typedef struct bootm_headers {. Char * ft_addr; / * flat dev tree address * / ulong ft_len; / * length of flat device tree * /...} bootm_headers_t

In the bootm_header_t way, U-Boot needs to support device trees and files that are not empty.

Transmission of Linux device Tree and Analysis of device Tree in Kernel transfer of Linux device Tree and Analysis of device Tree in Kernel

Ft_len and ft_addr belong to bootm_header_t, which are instantiated when U-Boot parses the image file. The function call stack is as follows:

Do_bootz (struct cmd_tbl * cmdtp, int flag, int argc, char * const argv [])-bootz_start ()-bootm_find_images (int flag, int argc, char * const argv [], ulong start,ulong size)-boot_get_fdt (flag, argc, argv, IH_ARCH_DEFAULT, & images,&images.ft_addr, & images.ft_len); u-boot-v2021.04/common/image-fdt.c

Gd- > bd- > bi_boot_params mode

This is a relatively old way, and it will not be adopted at present. Bi_boot_params is an address where kernel startup parameters are stored, usually specified in board-level initialization.

When the code is executed here, whether R2 is the expected value can be confirmed by printing and using debugging tools.

Parsing of device Tree by kernel

Parsing is divided into two stages, the first stage is to verify and re-adjust the startup parameters; the second stage completes the decompression of the device tree, that is, changing the device tree from FDT to EDT, and creating a device_node.

The first stage

The first entry in the kernel startup log related to the device tree is printed as follows, that is, the model name of the current hardware device, "OF: fdt: Machine model: V2P-CA9".

Booting Linux on physical CPU 0x0Linux version 5.4.124 (qemu@qemu) (gcc version 6.5.0 (Linaro GCC 6.5-2018.12)) # 3 SMP Fri Jun 25 15:26:02 CST 2021CPU: ARMv7 Processor [410fc090] revision 0 (ARMv7), cr=10c5387dCPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cacheOF: fdt: Machine model: V2P-CA9

This model name is defined in the header of the device tree file, defining the overall name of the current device.

/ / SPDX-License-Identifier: GPL-2.0/** ARM Ltd. Versatile Express** CoreTile Express A9x4 * Cortex-A9 MPCore (V2P-CA9) * * HBI-0191B*//dts-v1/;#include "vexpress-v2m.dtsi" / {model = "V2P-CA9";...}

But this is not the first time kernel has processed the device tree. There have been other operations before that. The function call stack is as follows:

Setup_arch (char * * cmdline_p) arch/arm/kernel/setup.c atags_vaddr = FDT_VIRT_BASE (_ _ atags_pointer); setup_machine_fdt (void * dt_virt) arch/arm/kernel/devtree.c early_init_dt_verify () of_flat_dt_match_machine () drivers/of/fdt.c early_init_dt_scan_nodes (); _ _ machine_arch_type = mdesc- > nr

Line 2, _ _ atags_pointer, is the in-memory address of dtb, which is obtained in the assembly phase (if the image is zImage, then it is completed in the decompression phase). Since the mmu has been enabled and the 4K segment page table has been mapped when executing to setup_arch, and the device tree fdt address passed by U-Boot to kernel belongs to the physical address, the physical address needs to be translated into a virtual address.

Head-common.S .align 2 .type _ _ mmap_switched_data % object__mmap_switched_data:#ifdef CONFIG_XIP_KERNEL#ifndef CONFIG_XIP_DEFLATED_DATA .long _ sdata @ r0.long _ _ data_loc @ R1 .long _ edata_loc @ r2#endif .long _ _ bss_stop @ sp (temporary stack in .bss) # endif .long _ bss_start @ r0.long _ bss_stop @ R1 .long init_thread_union + THREAD_START_SP @ sp .long processor_id @ r0.long _ _ machine_arch_type @ R1 .long _ atags_pointer @ R2

The configuration of the device tree in the first phase mainly includes:

A performs crc32 check on the dtb file to check whether the device tree file is legal early_init_dt_verify ()

B early_init_dt_scan_nodes () / * Retrieve various information from the / chosen node * / of_scan_flat_dt (early_init_dt_scan_chosen, boot_command_line); / * Initialize {size,address}-cells info * / of_scan_flat_dt (early_init_dt_scan_root, NULL) / * Setup memory, calling early_init_dt_add_memory_arch * / of_scan_flat_dt (early_init_dt_scan_memory, NULL); C update _ _ machine_arch_typeD update chosen

The above chosen information can see what changes have been made again after kernel is up.

The second stage

In the second stage, the ABI file of the device tree is decompressed and changed from FDT to EDT to generate the corresponding device_node nodes. The function call stack for this stage is as follows:

Unflatten_device_tree (); * _ unflatten_device_tree () / * First pass, scan for size * / size = unflatten_dt_nodes (blob, NULL, dad, NULL); / * Second pass, do actual unflattening * / unflatten_dt_nodes (blob, mem, dad, mynodes); unflatten_dt_nodes () populate_node ()

The device_nodes node is as follows:

Transmission of Linux device Tree and Analysis of device Tree in Kernel transfer of Linux device Tree and Analysis of device Tree in Kernel

After the creation of the device_node, when kernel creates the platform_device, it registers the corresponding devices according to the work completed at this stage, which is used by the driver code.

What is Linux system Linux is a free-to-use and free-spread UNIX-like operating system, is a POSIX-based multi-user, multi-task, multi-threaded and multi-CPU operating system, using Linux can run major Unix tools, applications and network protocols.

On how to carry out Linux device tree transmission and Kernel device tree analysis questions shared here, I hope the above content can be of some help to you, if you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.