one, foreword
As a years of cultivation in the 2.6.23 kernel paves the developer, different project in different surrounding peripherals driven development and various trivial, wrangling mundane occupies most of the time, when have the opportunity to download the 3.14 kernel and ready to learn, suddenly found the Linux kernel seems to have become very strange for me, all sorts of new mechanism, various kinds of framework, I am reading all kinds of new concepts, making it difficult for the kernel code is good, the enthusiasm of the anatomy of the kernel is still there, give the rest of the time, first into the line of sight is a Device Tree mechanism, this is the related mechanism and porting kernel very, if you want to our hardware platform migration to the high version of the kernel, Device Tree is a must to eliminate obstacles,
I want to know the Device from the following three aspects: the Tree:
1, why the introduction of the Device Tree, this mechanism is used to solve the problem of what? (this is the topic of this article)
2, the basic concept of the Device Tree (please refer to the basic concept for DT)
3, ARM Linux and Device Tree code analysis code analysis (please refer to the DT)
Reading like appreciate the iceberg, the Linux kernel code to see the beauty of the (various kernel mechanism and its code), there are also buried beneath the surface of the water to see the basis of the source and destination behind (mechanism), indulge in all sorts of mechanism of the kernel code is unlimited fun, but more important is to inject more thinking, mechanism of thinking behind it, really understand the software abstraction, in this way can extrapolate, and apply in the concrete work and in life,
This article mainly from the following several aspects: why the ARM Linux will introduce Device Tree:
1, there is no Device Tree ARM Linux is how to work?
2, the chaos of the ARM architecture code and the problems existing in the
3, the new kernel solution
Second, there is no Device Tree ARM Linux is how to work?
I once porting kernel to two ARM - -based platform, is a small application processor chip companies, companies buy their own CPU core, the CPU core using the ARM instruction set compatible (but not ARM) combined with its own design of multimedia peripherals to integrate into the company's products for sale, and my task is to porting 2.4.18 kernel on the platform, in the era of black and white screen mobile phone, that AP (application process) to support the color screen, camera, JPEG hardware acceleration, 2 d/3 d acceleration, MMC/SD card, all kinds of audio acceleration (built-in DSP), and so on characteristics, too powerful to look straight, the other a transplant experience is to make the 2.6.23 kernel runs in a big company of unpopular BP (baseband processor), the method of the porting, it is very simple:
1, oneself write a bootloader and pass the appropriate parameters to the kernel, in addition to the traditional command line and the tag list, such as the most important thing is to apply for a machine type, when to project their own machine type ID, mood at that time, it seems is a part of the open source community (actually that was willing, or goal is wants to our code into the Linux kernel main line),
2, Mach in the kernel of the arch/arm - XXX directory, the directory and add the code for the SOC, interrupt controller code, for example, time related code, the memory mapping, sleep related code, etc., in addition, the most important thing is to create a board specific file, to define a macro machine:
MACHINE_START (project name, "XXX of XXX company hardware platform")
. Phys_io=0 x40000000,
Xa0000100 boot_params=0,
Io_pg_offst=(io_p2v (0 x40000000) & gt;> 18) & amp; 0 XFFFC,
Map_io=xxx_map_io,
Init_irq=xxx_init_irq,
The timer=& amp; Xxx_timer,
Init_machine=xxx_init,
MACHINE_END
In xxx_init function, general meeting to join many platform device, therefore, with the board, specific file is a lot of static table, describes the various hardware information,
3, through the system level driver (timer, interrupt handling, clock, etc.) and a serial port terminal, basic can be up to the Linux kernel, following a variety of driver constantly add, until all the hardware, system software support
To sum up, in the Linux kernel supports a SOC platform is actually very simple, let the Linux kernel on a specific platform into "run" is also very simple, the key problem is how elegant "run",
Three, the confusion of the ARM architecture code and the problems existing in the
Each official Linux kernel release there will be two weeks after the merge window, during this window, the maintainers of each part of the kernel will submit their own patch, request to test the stability of the code into the kernel the main line, each to this time, Linus will be more busy, he needs to obtain the latest code from the branch of each kernel maintainers and merge into your kernel source tree, Tony Lindgren, kernel OMAP development defenders of the tree, send an E-mail to Linus, request submission OMAP platform code changes, and gives some detailed description:
1, introduce the change
2, on how to solve the merge conficts, some git mergetool can deal with, can't processing, gives a detailed introduction and solutions
Everything is normal, also is given enough information, however, it is the pull request has sparked a debate against ARM Linux kernel code, I'm sure Linus is related to the ARM code would have upset, ARM the merge of the larger workload fell in the second, mainly he thinks many ARM code are rubbish, code table, with some stupid inside and more people in the maintenance of this table, resulting in the conflict, therefore, in dealing with the pull of OMAP request after (Linus is not aimed at OMAP platform, only Tony Lindgren, hit on the muzzle), he sent out a roars:
Gaah. Guys, this whole ARM thing is a f * cking pain in the along.
Would responsible for the development of the ARM Linux Russell King face, the retort: things not so serious, the merge between the OMAP and took IMX/MXC conficts coordination problem, cannot erase the whole ARM Linux the efforts of the team, each other ARM platform maintainers also join the discussion: ARM platform how complex, how large, for ARM Linux code we have some thought, is in progress... For a moment, the atmosphere of the discussion some sharp, but overall is honest and friendly,
For one thing, people have different levels of thinking of different levels, this dispute involving people include:
1, the kernel maintainers (CPU architecture independent code)
2, the maintenance of ARM system structure code
3, maintain the ARM sub architecture (from each ARM SOC vendor)
Maintenance ARM sub architecture is not strong sense of mission, as a member of the company, their biggest target support their company SOC at the fastest speed, the occupation of the market as soon as possible, these people's software capability is not strong, the understanding of Linux kernel may not deep (some people may be strong, but in the river's lake tracks), in this case, a lot of SOC specific code by copy and paste, then slightly modified code is submitted, in addition, each ARM vendor's family is a long list of SOC CPU list, each CPU, somewhat # ifdef is filled with all the source code at this time, let the ARM Mach - and platt - directory of the code to look straight, some
As the maintenance of the ARM architecture, its ability, no doubt to Russell King the team headed by a good maintenance of the ARM architecture code, basically, in addition to the Mach - and platt - directory, other directories of the code and directory organization is very good, as defenders of the ARM Linux, maintaining a constant have new SOC to join the CPU architecture of code is really a challenge, and at the time of Intel X86 architecture of unify the whole country, any opponent think positive against Intel, want to knock down the giant and giant coexist (or want) must be a different approach, ARM's strategy has two, one is to focus on the embedded application, also means that require low power consumption, but also avoid the positive confrontation, and Intel is another use of the advantages, with the method of IP license, let more manufacturers to join the ARM of the ecological system, there is no doubt that the ARM was successful, but this pattern also brought a nightmare to ARM supporter of Linux, more and more manufacturers to join the ARM chip, a growing number of ARM platform related code was added to the kernel, a different vendor's peripheral HW block design and different...
Kernel maintainers are real to the operating system kernel software have a deep understanding of people, they often can stand on a higher level go up observation, found the problem, Linus noticed that every time the merge window, the ARM code change about 60% of the whole ARCH directory, he thinks this is an obvious symbol, means that the ARM Linux code there may be a problem, in fact, 60% of this ratio is exaggerated, because unicore32 is in 2.6.39 merge window for the first time in a new submission, its code is new, but its code change about 9.6% of the whole ARCH directory (need to mention is unicore32) is a Chinese core, some maintenance ARM Linux people think it is a reflection of the CPU market occupancy rate, not a problem, until the kernel maintainers posted the actual code and pointed out the problem, the kernel maintainers to Linux kernel support more hardware platform, of course, but they are more willing to Linux kernel of instituting a long-term planning, for example, for all sorts of multifarious ARM platform, with a kernel image to support,
After argument, certain problems are as follows:
1, lack the ARM Linux platform (each ARM sub architecture, or the SOC) coordination between, have lead to ARM Linux code, repeat, it is worth mentioning before the debate, the ARM maintainer has conducted a number of related work (such as PM and clock tree) to abstract the same function module,
2, a great deal of the board in the ARM Linux specific source code should be kicked out of the kernel and otherwise these junk code and the table will affect the Linux kernel long-term goals,
3, each sub supporter of architecture directly submitted to Linux are merged into the main line of mechanism is lack of hierarchy,
Four, the new kernel solution
nullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnull