Device Tree (i): Background introduction

Original URL: http://www.wowotech.net/device_model/why-dt.html

First, preface

As a developer of the Linux 2.6.23 kernel for many years, the development of various peripheral peripheral drivers in various projects and the trivial, petty and mundane chores occupy most of the time. When the opportunity to download the 3.14 kernel and prepare to learn, suddenly found that Linux kernel for me seems to become very unfamiliar, a variety of new mechanisms, various frameworks, various new concepts make me feel the reading kernel code is difficult. Fortunately, the analysis of the core of enthusiasm is still, the rest of the time to give. The first step into the line of sight is the device tree mechanism, which is very relevant to the porting kernel, and Device tree is an obstacle that must be cleared if you want to migrate our hardware platform to a higher version of the kernel.

I want to learn about device Tree from the following three areas:

1. Why to introduce device Tree, which is the mechanism to solve the problem? (This is the subject of this article)

2, the basic concept of Device tree (please refer to the DT basic concept)

3, ARM Linux and Device tree related code analysis (please refer to DT code analysis)

Reading the Linux kernel code is like appreciating icebergs, having a beautiful view (various kernel mechanisms and their code), and a foundation that is not visible beneath the surface (the source and purpose behind the mechanism). While it's fun to indulge in a variety of kernel-mechanism code, it's more important to inject more thinking, think about the mechanics behind it, and really understand software abstraction. This can be extrapolate and applied in specific work and life.

This article explains why arm Linux introduces device Tree in the following ways:

1. How does arm Linux without device tree work?

2. Confusing ARM architecture code and existing problems

3, the solution of the new kernel

Second, how does arm Linux without device tree function?

I used to porting the kernel to two arm-based platforms. A small chip company's application processor, the company purchased its own CPU core, which uses arm-compatible instruction sets (but not arm) plus a variety of company-designed multimedia peripherals to integrate into the company's products for sale. And my task is to porting the 2.4.18 kernel to the platform. In the black-and-white screen of the mobile era, the AP (application process) supports color display, camera, JPEG hardware acceleration, 2d/3d acceleration, MMC/SD cards, various audio acceleration (built-in DSP) and other features, powerful to not look. Another transplant experience was to let the 2.6.23 kernel run on the unpopular BP (baseband processor) of a big company. The specific porting method is very simple:

1, write a bootloader and pass the appropriate parameters to kernel. In addition to the traditional command line and the tag list, the most important thing is to apply for a machine type, when the machine type ID belongs to their own project, when the mood is jumping, it seems that they are already a part of the open source community (in fact, there is a willingness, Or the goal is to incorporate everyone's code into the Linux kernel main line).

2, in the Arch/arm directory of the kernel to establish the MACH-XXX directory, this directory, put the relevant code of the SOC, such as interrupt controller code, time-related code, memory mapping, sleep-related code and so on. Also, the most important thing is to create a board specific file that defines a machine macro:

Machine_start (project name, XXX hardware platform for XXX company)
. Phys_io = 0x40000000,
. Boot_params = 0xa0000100,
. Io_pg_offst = (IO_P2V (0x40000000) >>) & 0XFFFC,
. Map_io = Xxx_map_io,
. INIT_IRQ = Xxx_init_irq,
. Timer = &xxx_timer,
. Init_machine = Xxx_init,
Machine_end

In the Xxx_init function, a lot of platform device is usually added. Therefore, accompanying this board specific file is a large number of static table, which describes various hardware device information.

3, the system level of driver (timer, interrupt processing, clock, etc.) and the serial terminal, Linux kernel basically can be up, followed by a variety of driver constantly added, until the system software support all the hardware.

In summary, it is very simple to support a SOC platform in Linux kernel, so it is very simple to "run" the Linux kernel on a particular platform, the focus of the question is how to "run" gracefully.

Iii. confusing ARM architecture code and existing problems

Every time the official Linux kernel release has a two-week merge window, during which the maintainers of the various parts of the kernel submit their patches, incorporating their own test-stable code request into kernel main line. At this point, Linus is busier, and he needs to get the latest code from the branches of each kernel maintainer and merge it into his own kernel source tree. Tony Lindgren, the maintainer of the kernel omap development tree, sent a message to Linus, requested to submit a OMAP platform code modification, and gave some details:

1. Brief introduction of this change

2, about how to solve the merge conficts. Some git mergetool can be handled, not handled, given a detailed introduction and solution

Everything is normal and gives enough information, however, it is this pull request that raises a debate about the kernel code for ARM Linux. I believe that Linus must be arm-related code has been uncomfortable, arm of the merge workload is the second, mainly he thinks arm a lot of code is garbage, the code has a number of stupid table, and many people in the maintenance of this table, resulting in the conflict. So, after finishing Omap's pull request (Linus was not targeting the OMAP platform, but Tony Lindgren crashed into the muzzle), he roared:

Gaah. Guys, this whole ARM thing are a f*cking pain in the.

Russell King, who is responsible for the development of Arm Linux, Shing on the face: things are not so serious, this time the merge conficts is OMAP and imx/mxc a little coordination between the problem, can not erase the efforts of the entire ARM Linux team. Other arm platform Maintainers also joined the discussion: how complex the arm platform, how large, for ARM Linux code we have some thinking, is in progress ... For a time, the atmosphere of the discussion was somewhat sharp, but the overall was frank and friendly.

For one thing, different levels of people have different levels of thinking. The people involved in this debate include:

1. Kernel maintainer (CPU architecture Independent Code)

2. The person who maintains the ARM system structure code

3, the person who maintains arm sub architecture (from each arm SOC vendor)

The people who maintain arm sub architecture do not have a strong sense of mission, as a member of the company, their biggest goal is to support their own SOC at the fastest speed, occupy the market as soon as possible. These people's software skills may not be strong, the understanding of Linux kernel is not necessarily deep (some people may be strong, but people in the lakes and rivers involuntarily). In this case, many of the SOC specific code is submitted by copy and paste, and then the code is modified slightly. In addition, each arm vendor Soc family is a long list of CPUs, each CPU is somewhat different, this time #ifdef is flooded with various source code, so that the arm mach-and plat-directory code some can't bear to look straight.

As a person who maintains an arm architecture, its capabilities are beyond doubt. The team, headed by Russell King, is well-maintained with the ARM architecture code. Basically, in addition to the mach-and plat-directories, the Code and directory organization in the other directories is good. As a maintainer of ARM Linux, it is a challenge to maintain a CPU architecture code that constantly has new Soc added. At the time of the Intel X86 Architecture Eminence, any opponent who wanted to attack Intel positively was defeated. If you want to knock down giants (or want to coexist with giants) you have to do something. ARM's strategy is two, one is focus in the embedded application, also means to require low power consumption, but also avoids the positive confrontation with Intel. The other is to take the long of the family, using license IP, so that more manufacturers to join the ecosystem established by arm. There is no doubt that arm is successful, but this model also brings nightmares to the defenders of Arm Linux. More and more chip manufacturers to join the arm camp, more and more arm platform related code is added to the kernel, different manufacturers of the surrounding HW block design is not the same ...

Kernel maintainers are people who really have a deep understanding of the operating system kernel software, and they tend to be able to stand on a higher level to observe problems and find problems. Linus noticed that arm's code changes accounted for about 60% of the entire arch catalog in each merge window, which he thought was an obvious sign, meaning that there might be a problem with the arm Linux code. In fact, the 60% ratio is really exaggerated, because Unicore32 is the first new commit in the 2.6.39 Merge window, its code is brand new, but its code changes about 9.6% of the entire arch directory (it is important to mention that UNICORE32 is a Chinese core). Some people who maintain arm Linux think this is a manifestation of CPU market occupancy, not a problem until the kernel maintainers post the actual code and point to the problem. Kernel maintainers, of course, want Linux kernel to support more hardware platforms, but they prefer to make longer-term plans for Linux kernel. For example: For a variety of arm platforms, with a kernel image to support.

After the argument, the following questions are identified:

1, ARM Linux lacks platform (each arm sub architecture, or each SOC) coordination, resulting in the code of ARM Linux duplication. It is worth mentioning that prior to this debate, arm maintainers have done a lot of related work (such as PM and clock tree) to abstract the same function modules.

2, ARM Linux in a large number of board specific source code should be kicked out of kernel, otherwise these garbage code and table will affect the long-term Linux kernel goals.

3, each sub architecture's maintainer directly to the Linux integration Main line mechanism lacks the level.

Iv. solutions to the new kernel

For the current situation of ARM Linux, the most need to solve is the personnel problem, that is, how to integrate the ARM sub architecture (each arm Vendor) resources. As a result, the kernel community has established a team of ARM sub architecture, which is responsible for coordinating the code of each arm vendor (not arm core part) and Russell King continues to be responsible for the arm core part code. Also, build an arm platform consolidation tree. The ARM sub Architecture team is responsible for review the code submitted by each sub architecture maintainer and is maintained on ARM platform consolidation tree. When the next merge window arrives, Patch is sent to Linus.

For repetitive code problems, if different SoCs use the same IP block (for example, an I²C controller), then this driver code is isolated from each arch/arm/mach-xxx and becomes a generic module for each SOC The specific module is used. Which directory do you move to? For i²c or USB OTG, these HW block drivers should of course be moved to the Kernel/drivers directory. Because, for these peripherals, it may be in-chip, it may be off-chip, but for software they are no different (or the good software abstraction should mask the difference between the underlying hardware). What about the code for the system level? For example, clock control, interrupt control. In fact, these are not arm-specific, should belong to the core code of Linux kernel, should be placed in Linux/kernel directory, belongs to Core-linux-kernel frameworks. Of course, for the arm platform, you also need to save some code that interacts with the framework, which is called arm SoC core Architecture code. OK, summarize:

1, ARM's core code is still stored in the Arch/arm directory

2. ARM SoC Core Architecture code is saved in the Arch/arm directory

3. The driver of peripheral peripheral module of ARM Soc is saved in the drivers directory

4, ARM Soc specific code in the Arch/arm/mach-xxx directory

5. The code of ARM SOC Board specific is removed, and the device tree mechanism is responsible for transmitting hardware topology and hardware resource information.

OK, finally came to the device tree. In essence, Device tree changed the way the HW configuration information was originally embedded in the kernel code in the HardCode way, using bootloader to pass in a DB form instead. For an ARM CPU-based embedded system, we are accustomed to compiling the kernel for each platform. But with the wide application of arm in Consumer electronics (even desktop systems, server systems), we expect arm to support multiple platform with a kernel image like X86. In this case, if we think that kernel is a black box, then its input parameters should include:

1. Identifying Platform Information

2. Runtime configuration Parameters

3, the topology and characteristics of the device

For embedded systems, during the system startup phase, the bootloader loads the kernel and transfers control to the kernel, in addition to passing the above three parameter information to the kernel so that the kernel can have greater flexibility. In Linux kernel, this is the design goal of Device tree.

original articles, forwarded please indicate the source. Snail Nest technology , www.wowotech.net.

Device Tree (i): Background introduction