Linux porting Overview

Compared with other operating systems, Linux has the biggest feature: it is a GPL-compliant operating system, and we can freely use, modify, and expand it. Thanks to this feature, Linux is favored by more and more people. As a result, a frequently discussed problem arises, that isLinux porting. For operating systems, such porting is usually cross-platform and hardware-related, that is, the hardware system structure, or even the CPU is different. Next let's take a look at what we need to do in Linux porting.

I,Linux portingTwo major parts

For system transplantation, the Linux system is actually composed of two relatively independent parts, namely the kernel part and the system part. Generally, the process of starting a Linux system is as follows: a loader that is not affiliated with any operating system transfers some linux kernels to the memory and gives control to the first line of code of the Linux kernel in the memory. After loading the program, Linux will load all its remaining parts to the memory (if any, depending on the hardware platform) and initialize all devices, establish the required data structure (related processes, devices, memory, etc.) in the memory ). So far, the Linux kernel has been operating on all hardware devices. As for operating and using these hardware devices, it is the turn of the system to play. The kernel loads the root device and starts the init daemon. The init daemon loads the file system, network, service process, and terminal according to the configuration file. Once the terminal Initialization is complete, we will see the welcome page of the system. Summary: (1) the kernel initializes and controls all hardware devices (not all, but the vast majority), and prepares for memory management, process management, device read/write, and other work. (2) The system part loads necessary devices and configures various environments so that users can use the entire system.

Ii. environment required for system migration

Before proceeding, we need to mention the environment necessary for system migration. First, a new version of GCC is required. To what extent should a programmer prepare for system porting be "new. For cross-platform compilation, GCC may be the best choice. In addition, the Linux kernel depends on many features unique to GCC, rather than it. If you have already used GCC and practiced too many times in the field, you only need to further consolidate the cross-platform compilation operations. Two compiling environments are available: Linux on non-target platforms or non-Linux systems on the target platforms, unless your development platform is too special, otherwise, you will be able to find the GCC you can use. Second, compiling the Link Library is required and must be the compilation Link Library of the target platform. This is usually a boring, tedious process with no sense of accomplishment. Fortunately, there will be ready-made link libraries available for use. Otherwise, you need to build it with GCC. Finally, all the documents on the target platform are required. The more documents, the better. If there is a certain development support/simulation environment, loader (loading program) is the best, which can help you reduce the time wasted on trivial matters during the porting process.

Iii. Linux system migration

Next, we will describe the key points in Porting from the kernel and system. (1) kernel portingLinux uses a single kernel mechanism that is not flexible, but does not affect the platform independence and scalability of Linux. Linux uses two methods to solve these problems, which are clean and easy to understand. The separation of hardware-related code and hardware-independent code makes the upper-Layer Code never have to worry about what code is exchanged at the lower layer and how to complete the operation. Allocating a piece of memory on both x86 and Alpha platforms is no different for upper-layer code. There are not many hardware-related codes, which are a small part of the total code volume. Therefore, there is no real burden for replacing the hardware platform. On the other hand, Linux uses the kernel mechanism to solve the expansion problem. A bunch of code can be easily loaded or detached as needed, like Walkman, if not needed, it is locked in the drawer. The Linux kernel consists of five functional components: process management (including scheduling and communication), memory management, device management, Virtual File System, and network. There is a complex call relationship between them, but fortunately, it won't touch too much in Porting, because the good hierarchical structure of Linux kernel isolates hardware-related code. What is hardware-related and irrelevant? Taking process management as an example, the time slice rotation scheduling algorithm for processes is the same in Linux on all platforms and is irrelevant to the platform; the implementation of switching in the process varies with the CPU. Therefore, you need to write code for the platform, which is platform-related. The order of the five parts mentioned above is not arranged randomly. from the beginning to the end, they represent the degree to which they are related to hardware devices. The higher the front, the two virtual file systems and networks are almost irrelevant to the platform. They are supported by the drivers supported by device management. Therefore, when porting the system, you need to modify the code of the hardware-related part, which is independent from process management, memory management, and device management. Under the Linux code tree, all the code is under the arch directory. If your target platform has been supported by the Linux core, you are lucky because you do not have much work to do. As long as your cross-compilation environment is correct, you only need simple configuration and compilation to get the target code. Otherwise, you need to write or modify some code. You only need to modify the code of the platform. However, it is necessary to have a thorough understanding of the target platform, mainly the CPU. Under the Linux code tree, we can see that the typical code volume is about 20 thousand lines of C code and about 2 thousand lines of assembly (C code usually contains many pseudo Assembly commands, therefore, the pure C code is actually much less), and this part of the workload cannot be underestimated. It includes underlying operations on the vast majority of hardware, involving IRQ, Memory Page tables, express tables, floating point processing, clock, multi-processor synchronization, and other issues, frequent port programming means you need to rewrite the documentation of the Target Platform in C language. This is why the documentation for the target platform is extremely important. The largest part of the code is the underlying support part directly called by the core. This part of the Code is under ARCH/XXX/kernel (XXX is the platform name ). The Code overwrites all the functions that the kernel needs to call. Because the interface functions are fixed, it is more like writing APIs for the hardware platform. Different system platforms have the following differences: * Process Management underlying code: From the Perspective of hardware systems, process management is the management of CPU. This is quite different on different hardware platforms. The register structure in the CPU is different. The context switching mode, on-site storage and recovery, and stack processing are all different. These contents are described in the CPU development manual. Generally, all CPU functions and statuses are not necessarily meaningful for Linux. During implementation, You need to weigh 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 PC name. This is what we call it without confusion. On a general platform, there are usually Basic Input and Output Systems for the operating system, bios on the PC, and prom on the Linux server. This is not even true for many non-General 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 through the Basic Input/Output System. During porting, this part of code usually needs to be completely rewritten. * Code supported by clock and interrupt devices on the same CPU platform: Different on-board peripherals exist even on the same CPU platform, especially on Heterogeneous CPU platforms. Different system configurations require different initialization codes. A typical example is the MIPs platform. Check the code of ARC/MIPS/and compare it with other systems. Because the MIPs platform is the most widely used by OEMs, it has the most applications in the embedded field (compared with several other CPUs ). Even the same MIPS chip is encapsulated by different manufacturers and coupled with different chipset. Therefore, we need to write different codes for these different MIPS platforms. * Special Structure Code: such as multi-processor support. In fact, each type of CPU is very special. People familiar with the X86 platform all know the differences between the famous real mode and virtual mode of the x86 series CPU. This concept is not available on the Linux platform. This leads to a big difference: Linux on a PC started to switch to the virtual mode shortly after obtaining control, while there was no such code on the Linux machine. For example, power management supports a variety of methods, and different CPUs have different implementation methods (special power management methods are even advertised by vendors ). In this case, the Code must be rewritten unless the power management support is abandoned. There is still a small amount of code, but the part that cannot be ignored is the memory management part under ARCH/XXX/MM. All the Memory Management Code related to the platform is here. This part of code initializes the memory and establishes various data structures related to memory management. Linux uses virtual storage technology based on Page Management, and the trend of CPU development is: to improve performance, all functional units that implement memory management are integrated into the CPU. Therefore, memory management becomes a very CPU-related task. At the same time, the efficiency of memory management is also one of the factors that affect the system performance. Memory can be said to be the most frequently accessed device in the computer system. If the memory occupies an additional clock cycle each time, the system performance may be reduced to an intolerable level. In Linux systems, the degree of differences in Memory Management Code on different platforms is surprising. Different CPUs have different memory management modes, and the same CPU has different memory management modes. Linux is an operating system developed from a 32-bit hardware platform, but there are already several 64-bit platforms. On the 64-bit platform, the available memory range is increased to 232 times, which is slightly different. Given the importance and complexity of this part of the code, the porting work has become very cautious here. Some platforms even use the most conservative memory management mode. For example, the page size on the iSCSI platform can be multiple sizes. For simplicity and reliability, the 8 K page mode is only used in Linux. This situation has not been improved until version 2.4. In addition to the above, some code needs to be considered, but it is relatively less important. For example, floating point operations are supported. The perfect practice is to program FPU and complete floating point operations by hardware. But in some cases, floating point is not important, and even the CPU does not support floating point at all. At this time, you can choose based on your needs. So far, we have discussed kernel porting. In fact, some porting work needs to be considered at the same time, but it is hard to say that this is a kernel or a driver. For example, the support for display devices is very related to the kernel, but it does not belong to the kernel logically, and it is also more like the development of the driver during transplantation. Therefore, it is not discussed here. (2) system migrationAfter the kernel is transplanted, it can be said that all the porting work has been completed. That is to say, when the kernel is loaded to the target platform after successful cross-compilation, and a prompt similar to VFS: Can't mount root file system appears, it indicates that you can start the system migration. System transplantation is actually a reconstruction process of the smallest system. Many Linux enthusiasts have experience in creating a Linux system emergency disk. In contrast, you need to use the binary code on the target platform to generate the minimum system. Including: init, libc library, driver module, necessary applications and system configuration scripts. Once these tasks are completed, the migration will enter the joint debugging stage. A relatively easy part of 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. This avoids the trouble caused by logical errors of the smallest system. Because multiple applications work together in the smallest system, sometimes the problem occurs not in the Code itself but in the logic structure of the system. Linux porting should at least include the above content. In addition, some invisible development work, such as the driver of a special device, should not be ignored, remote debugging for kernel debugging. In addition, for the same porting job, it is obvious that the transplantation that conforms to the minimum function set is different from the perfect transplantation. The transplantation to 16 bits is also different from the transplantation to 64 bits. The common problems encountered during transplantation are locking or crashing during the trial run. It is easier to do this during system transplantation because it is easy to locate the root cause of the error, but it is really a headache for core transplantation. Although the running kernel can be debugged through the serial port, many phenomena cannot be reproduced in the case of multiple tasks. Another example is that at the beginning of initialization, many devices cannot determine the status, or 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, you need to add debugging code that reflects the system running status. In addition, you need to thoroughly understand 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 a GPL-based operating system. During transplantation, we can give full play to the advantages of GPL, so that more fans can participate and move forward to a common goal.