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

This article introduces the relevant knowledge of "detailed introduction of Linux system transplantation". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Compared with other operating systems, the biggest feature of Linux is that it is an operating system that follows GPL, and we are free to use, modify, and extend it. It is because of this feature that Linux is favored by more and more people. As a result, a problem that is often discussed arises, that is, the migration of Linux systems. For the operating system, this migration is usually cross-platform and hardware-related, that is, the hardware system structure or even CPU is different. Let's take a look at what we need to do in terms of Linux system migration.

First, the two main parts of Linux system transplantation

For system porting, the Linux system actually consists of two relatively independent parts, namely, the kernel part and the system part. Usually the process of starting a Linux system is like this: a loader that is not part of any operating system calls part of the Linux kernel into memory and gives control to the first line of code of the Linux kernel in memory. The loading program is done, and after that Linux loads the rest of itself into memory (if any, depending on the hardware platform), initializes all devices, and establishes the required data structures in memory (about processes, devices, memory, etc.). So far, the work of the Linux kernel has come to an end, and the kernel has controlled all the hardware devices. As for the operation and use of these hardware devices, it is the turn of the system to play. The kernel loads the root device and starts the init daemon, which loads the file system, configures the network, service processes, terminals, and so on, according to the configuration file. Once the terminal is initialized, we will see the welcome interface of the system. A brief summary:

(1) the kernel initializes and controls all hardware devices (strictly speaking, not all, but most of them), making all preparations for memory management, process management, device reading and writing, etc.

(2) the system part loads the necessary equipment and configures various environments so that users can use the whole system.

2. The necessary environment for system transplantation

Before going any further, it is necessary to mention the environment necessary for system migration.

First, you need a new version of gcc. For a programmer preparing for a system migration, it should be clear how "new" it is. Gcc may be the best choice for cross-platform compilation. In addition, the Linux kernel relies on many gcc-specific features that it must. If you already know how to use gcc and practice it many times in the field, you only need to further consolidate the cross-platform compilation operation. Two compilation environments are available: Linux on non-target platforms or non-Linux systems on target platforms. Unless your development platform is too special, you will be able to find the gcc you can use.

Second, compiling the link library is necessary and must be the compiled link library of the target platform. This is usually a boring, tedious process with no sense of achievement. If you are lucky, there will be a ready-made link library. Otherwise, you need to build it yourself with gcc.

Finally, you need all the documents for the target platform, as many as possible. If there is a certain development support / simulation environment, Loader (loader) is the best, which can help you reduce the time wasted on trivialities during the migration process.

III. Transplantation of Linux system

Next, we describe the key points in the migration from both the kernel and the system aspects.

(1) Kernel transplantation

The Linux system uses a single kernel mechanism that is relatively not very flexible, but this does not affect the platform independence and scalability of the Linux system at all. Linux uses two approaches to solve these problems, neatly, without any hassle, and very clear and easy to understand. Separate the hardware-related code from the hardware-independent code, so that the upper code never has to care about what code the lower layer switched to and how to complete the operation. Whether a piece of memory is allocated on x86 or on the Alpha platform, it makes no difference to the upper code. The hardware-related part of the code is not much, accounting for a small part of the total code. So there is no real burden on replacing hardware platforms. On the other hand, Linux uses kernel mechanisms to solve the problem of extension, and a pile of code can be easily loaded or unloaded when needed, like a Walkman, brought when needed, and locked in a drawer when not needed.

The Linux kernel can be regarded as composed of five functional parts: process management (including scheduling and communication), memory management, device management, virtual file system, and network. There is a complex invocation relationship between them, but fortunately, not much will be touched in the migration, because the good hierarchical structure of the Linux kernel separates the hardware-related code. What is hardware related and what is irrelevant? Take process management as an example, the time slice round robin scheduling algorithm for processes is the same in Linux of all platforms, it is platform-independent; and the implementation used to switch between processes is different on different CPU, so you need to write code for this platform, which is platform-related. The order of the five parts mentioned above is not random, but represents the degree of correlation between them and hardware devices from front to back. As the front gets higher and higher, the latter two virtual file systems and networks are almost platform-independent and are underneath supported by drivers supported in device management. Therefore, when doing system migration, what needs to be changed is the independent part of process management, memory management and device management, that is, the hardware-related part of the code. Under the Linux code tree, all of this code is in the arch directory.

If your target platform is already supported by the Linux core, you are lucky because there is not much work left for you to do. As long as your cross-compilation environment is correct, you only need to simply configure and compile to get the object code. Otherwise, you need to write or modify some code. You only need to modify the code in the relevant parts of the platform. But it requires a thorough understanding of the target platform, mainly CPU. Under the Linux code tree, you can see that the typical amount of code in this part is about 20,000 lines of C code and about 2,000 lines of assembly (C code usually contains many pseudo assembly instructions, so in fact pure C code is much less), this part of the work can not be underestimated. It includes low-level operations on most of the hardware, including IRQ, memory page tables, fast tables, floating-point processing, clocks, multiprocessor synchronization and so on. Frequent port programming means that you need to rewrite the documents of the target platform in C language. This is why the documentation for the target platform is extremely important.

The largest amount of code is the underlying support part that is directly called by the core, which is under arch/xxx/kernel (xxx is the name of the platform). This code rewrites all the functions that the kernel needs to call. Because the interface functions are fixed, it's more like writing API for hardware platforms. Different system platforms are different in the following aspects:

* process management underlying code: from a hardware system point of view, process management is the management of CPU. This is very different on different hardware platforms. The register structure used in CPU is different, the way of context switching, on-site preservation and recovery, and stack processing are all different, which are mainly described by the CPU development manual. Generally speaking, all the functions and states of CPU do not necessarily make sense to Linux. In implementation, there is a tradeoff between the minimum development cost and the best system performance.

* BIOS interface code: this name does not seem to be accurate because it follows the usual name of PC. But that's what we call it without causing confusion. On general-purpose platforms, there is usually a basic input-output system for the operating system, BIOS on PC, PROM on SPARC, and there is no such thing on many non-general-purpose systems. In most cases, Linux does not rely on the basic input-output system, but in some systems, Linux needs to obtain important device parameters from the basic input-output system. In migration, this part of the code usually needs to be completely rewritten.

* clock, interrupt and other on-board devices support codes: even on the same CPU platform, there will be different on-board peripherals, especially on heterogeneous CPU platforms. Different system configurations require different initialization codes. A typical example is the MIPS platform. Look at the arc/mips/ code and compare it with other systems. Because the MIPS platform is the most widely used by OEM, it is most widely used in the embedded field (compared to other CPU). Even the same MIPS chip is packaged by different manufacturers and equipped with different chipsets. So you need to write different code for these different MIPS platforms.

* Special structure code: such as multiprocessor support, etc. In fact, every kind of CPU is very special, and anyone familiar with the x86 platform knows the difference between the famous real mode and virtual mode of the x86 series CPU, but there is no such concept on the SPARC platform. This makes a big difference: Linux on the PC starts switching to virtual mode shortly after gaining control, while this code is not available on the SPARC machine. For example, the support of power management is more varied, and different CPU has different implementation methods (special power management methods are even touted by manufacturers). In this case, the code must be rewritten unless support for power management is abandoned.

There is also a small amount of code, but the part that can not be ignored is the memory management part under arch/xxx/mm/. All the platform-related memory management code is here. This part of the code completes the initialization of memory and the establishment of various data structures related to memory management. Linux uses virtual storage technology based on page management, while the development trend of CPU is that all the functional units of memory management are integrated into CPU in order to improve performance. Therefore, memory management has become a very related work with CPU. At the same time, the efficiency of memory management is also one of the factors that affect the performance of the system. Memory can be said to be the most frequently accessed device in a computer system. If an extra clock cycle is used for each memory access, it is possible to degrade the system performance to an unbearable level. In Linux systems, the degree of difference in memory management code on different platforms is surprising, and it can be said to be the biggest. Different CPU has different ways of memory management, and the same CPU will have different memory management modes. Linux is an operating system developed from 32-bit hardware platforms, but several 64-bit platforms have emerged. On 64-bit platforms, the range of available memory has increased to 232 times, and you can see the difference. Given the importance and complexity of this part of the code, the migration has become quite cautious here. Even the most conservative memory management model is used on some platforms. For example, the page size on the SPARC platform can be multiple sizes, for simplicity and reliability, the SPARC version of Linux only uses the 8K page mode. This situation did not improve until version 2.4.

In addition to what has been said above, there is some code to consider, but relatively minor. Such as floating-point operation support. A more perfect way is to program FPU and perform floating-point operations by hardware. But at some point, floating points don't matter, and even CPU doesn't support floating points at all. At this time, the choice can be made according to the demand.

This is the end of the discussion of kernel migration. In fact, there are still some porting tasks that need to be considered at the same time, but it is difficult to say whether this belongs to the kernel or the driver category. For example, the support of display devices is very related to the kernel, but logically it does not belong to the kernel. And porting is more like driver development. So I won't discuss it here.

(2) system transplantation

When the kernel migration is completed, it can be said that most of the migration work has been completed. That is, when the kernel is successfully cross-compiled, loaded and started normally on the target platform, and a prompt like VFS: Can't mount root file system appears, it means that the work on system migration can begin. System migration is actually a reconstruction process of a minimum system. Unlike many Linux enthusiasts who have experience in building an Linux system emergency disk, you need to generate this minimum system using the binaries on the target platform. Includes: init, libc libraries, driver modules, required applications and system configuration scripts. Once these tasks are completed, the transplant work will enter the joint adjustment stage.

A relatively easy way to transplant the system is to first establish the minimum system on the development platform to ensure that the minimum system runs correctly on the development platform. In this way, the trouble caused by the logic error of the minimum system itself can be avoided. Because multiple applications work together in the minimum system, sometimes the problem lies not in the code itself but in the logical structure of the system.

Linux system porting work should at least include the above contents, in addition, there are some invisible development work can not be ignored, such as the driver of a special device, remote debugging work done to debug the kernel and so on. In addition, for the same migration work, it is obvious that the migration that meets the minimum feature set is not the same as the perfect migration, and the migration to 16-bit is not the same as that to 64-bit.

The common problem encountered in migration is locking or crashing during trial run, which is easier to do when part of the system is migrated, because it is easy to locate the root cause of the error, and it is really a headache in core migration. Although the running kernel can be debugged through the serial port, there are many phenomena that can not be reproduced in the case of multitasking. For example, at the beginning of initialization, many devices are unable to determine the state, and even the serial port has not been initialized. There is no good solution to this situation, a good development / simulation platform is very important, in addition, we should add more debugging code that reflects the running state of the system; moreover, we should eat through the documentation of the hardware platform. The professional support of hardware platform manufacturers is also very important.

Another point is very important: Linux itself is an operating system based on GPL. When porting, it can give full play to the advantages of GPL and allow more enthusiasts to participate and move forward towards a common goal.

This is the end of the detailed introduction to the porting of Linux system. Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

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.