Embedded system migration steps Time: 2018-01-25 Source: Unknown
An important part of the embedded system migration is the operating system of the transplant, compared to other operating systems, Linux major characteristics: it is an operating system to follow the GPL, we are free to use, modify, and extend it. It is because of this feature, the embedded Linux system migration process systems favored by more and more people. As a result, there has been a frequently discussed issue is that the transplant on Linux systems. For operating systems, such transplants are generally cross-platform, hardware-related, that is, hardware architecture, and even different CPU. Let's take a look at the transplantation of embedded Linux system, we all need to do something.
A, Linux system migration of two parts
The system for transplant purposes, Linux system actually consists of two separate parts comparison, i.e., the core part and the systems part. Typically a Linux system start process is such that: a is not affiliated with any operating system loader portion Linux kernel into memory, and passes control to the first line memory Linux kernel. Loader work would be finished, after which the remainder of Linux you want to own all loaded into memory (if any, depending on the hardware platform vary), initialize all the devices required to establish a good data structure in memory ( related processes, equipment, memory, etc.). So far Linux kernel work come to an end, the kernel has taken control of all the hardware devices. As regards operation and use of these hardware devices, the system turn to play a part. Kernel root device to load and start the init daemon, init daemon will load the file system based on the profile, configure the network, service process and terminals. Once the terminal initialization is complete, we will see the welcome screen of the system. Summary about:
(1) the core part of the initialization and control of all hardware devices (strictly speaking, not all, but the vast majority), memory management, process management, reading and writing and other work equipment ready for anything.
(2) partial loading system necessary equipment, so that users can configure various environment used throughout the system.
Second, the system environment necessary for transplantation
Before further description, it is necessary to mention that we do transplant system environment necessary.
First, we need a new version of gcc. Prepare the system for a portable programmer, the "new" to what extent should know the answer. Do cross-platform compiler, gcc might be a good choice. In addition, Linux kernel dependent on many gcc-specific features, it can not be non. If you already use gcc and field practice too much back, you just have to look further consolidate cross-platform operation can be compiled. Both compilers environment are available: non-Linux systems on the Linux target platform or on non-target platform, development platform unless you are too special, otherwise you will be able to find your use of gcc.
Secondly, compile-link library is required and must be the target platform compiler libraries. This is usually a boring, tedious, and did not process a sense of accomplishment. With luck, there will be a ready-made libraries. Otherwise, you need to build it yourself using gcc.
After all the documents required target platform, the better. If there is some support for the development / simulation environment, Loader (Loader) is good, these can help you reduce the migration process waste time on trifles.
Three, Linux System Migration
The next key transplantation we describe the kernel and system from two aspects.
(1) kernel transplantation
Linux system uses a relatively not very flexible single core mechanism, but this did not affect Linux systems platform independence and scalability. Linux used two ways to solve these problems separately, very neat, did not dragging its feet, and very clear and easy to understand. Isolated hardware-related code and hardware-independent code, the upper low-level code that never have to be concerned about switching to what code, how to complete the operation. Regardless of the x86 or allocate a block of memory on the Alpha platform, the code is no different in terms of the upper layer. Hardware-related part of the code small, small part of the total amount of code. So the replacement of hardware platforms, there is no real burden. On the other hand, Linux using the kernel extension mechanism solves the problem, a bunch of code that can be easily loaded or removed when needed, like the Walkman, the time needed to bring, then locked in a drawer when not needed .
Linux kernel can be considered by the five functional components: process management (including scheduling and communication), memory management, device management, virtual file system, network. Between them they have a complex relationship calls, but fortunately, the transplant will not touch too much, because good hierarchical structure of the Linux kernel code related hardware independent. What is hardware-related, unrelated to what process management, for example, to the process of round-robin scheduling algorithm on all platforms on Linux are the same, it is platform-independent;? And in the process of switching to be implemented in different the CPU is different, so you need to write the code for the platform, which is platform-dependent. The above stated sequence is not just a portion of the five rows, from front to back, respectively representing the relevance thereof with the hardware device. The higher the ranking, the latter two virtual file system and network is almost independent of the platform, they are supported by the device manager in the driver provides low-level support. Therefore, when doing system migration, needs to be changed is the code process management, memory management and device management to be independent of that part of that is hardware-related parts. In the Linux code that tree, all this part of the code in arch directory.
If your target platform has been supported by the Linux kernel, then you are in luck, because there is not much work to let you do it. As long as your cross-compiler environment is right, you need only a simple configuration, you can get the compiler object code. Otherwise, you need to write or modify some code. Just modify the code to the relevant part of the platform. But the need for the target platform, mainly thorough understanding of the CPU. In the Linux code under the tree, you can see, the typical amount of code in this section are: about 20,000 lines of C code and about 2,000 lines of assembly (C code usually contains a lot of pseudo-assembly instructions, so in fact pure C code to be much less), those efforts can not be underestimated. It contains the vast majority of the underlying hardware operations, involving issues IRQ, memory page table, fast table, floating-point processing, clock, multiprocessor synchronization, frequent port programming means that you will need to target platform document with a C language rewrite. That is why the document target platform is extremely important.
Large part of the code is the underlying support section called directly the core of this part of the code in arch / xxx / kernel (xxx is the platform name). This code rewrite all the functions required kernel calls. Because the interface function is fixed, so here it is written more like API for the hardware platform. Different platforms, there are different following aspects:
* Process Management underlying code: From the hardware perspective, process management is the CPU management. On different hardware platforms, which are very different. Different structures used in the CPU registers, context switching manner, the save and restore the site, processing stack are different, these are mainly described manual developed by the CPU. Generally speaking, all the features and state of the CPU for Linux is not necessarily meaningful. When implementing need to be a trade-off between small development costs and good performance.
* BIOS interface code: The name seems not accurate, since it follows the usual name for PC. But in the case not to cause confusion so we call it. On a common platform, usually a basic input output system for Caozuoxitong use on a PC is BIOS, is on the SPARC PROM, in many non-generic system even no such thing. In most cases, Linux does not depend on the BIOS, in some systems, Linux device needs to be important parameters in the Basic Input Output System. Transplantation, this code typically requires completely rewritten.
* Clock and interrupt panel of the device support code: even on the same CPU platform, there will still be different on-board peripherals, especially on heterogeneous CPU platform. Different system configurations require different initialization code. Very typical example is the MIPS platform to see arc / mips / code comparison with other systems, we know. Because the OEM MIPS platform is too wide, embedded applications and more (relatively speaking several other CPU). Even the same MIPS chips are then packaged by different manufacturers matched with different chipsets. So you want to write different code for these different MIPS platforms, respectively.
* Code special structure: multiprocessor support. In fact, each CPU is very special, familiar x86 platform, people know the difference between x86 series CPU famous real mode and virtual mode, and on the SPARC platform is simply not the concept. This has led to very different: Linux on a PC soon began to switch to virtual mode after obtaining control, there is no code on SPARC machines. Another example is power management support is even more diverse, with different CPU different implementations (special power management modes and even advertised manufacturer). In this case, unless drop support for power management, or you must rewrite the code.
A little part of the amount of code, but can not be ignored in the memory management portion is arch / xxx / mm / in. All the memory management code associated with the platform at all here. This code and various initialization complete the establishment of memory management and data structures associated memory. Linux uses virtual memory page management technology based, and the CPU is the trend: In order to improve performance and functional units of all memory management is integrated into the CPU. Therefore, memory management becomes a very work-related CPU. At the same time the efficiency of memory management is also one of the factors affecting system performance. Memory device can be said that the computer system frequently accessed, if more than one clock cycle each time you take up memory access, it is possible to reduce the system performance to intolerable. In the Linux system, the degree of difference in memory management code on different platforms was surprising, to say a big difference. There are various different CPU memory management, the same CPU will have different memory management. Linux is developed from the 32-bit hardware platform, operating system up, but now there are several 64-bit platforms appear. On the platform 64, the range of available memory is increased to 232 times the original, the difference therebetween may be a glimpse. Given the importance and complexity of this part of the code, porting work here become very cautious. On some platforms even just with conservative memory management. Such as page size on the SPARC platform can be a variety of sizes, for the sake of simplicity and reliability, SPARC version of Linux but with the 8K page this mode. This situation until version 2.4 was able to improve.
In addition to the above stated, there are some code need to be considered, but a number of relatively minor. Such as support for floating-point operations. The practice is more perfect FPU programming, done in hardware floating-point operations. But at some point, floating point does not matter, even the CPU simply does not support floating point. This time you can choose according to demand.
For a discussion of kernel porting far. In fact, there are some porting work need to be considered, but it is difficult to say that this is part of the kernel drivers belong to the category or categories, such as the display device support, and kernel is very relevant, but logically not part of the kernel, and transplant on more like a driver development. Therefore not be discussed here.
(2) system migration
When the kernel porting is complete, it can be said that all the porting work has been completed more than half. That is, when cross-compiling the kernel after successfully loaded to the target platform normal start, and a similar VFS: Can not mount root file when the system prompt, then you can start working aspects of the system migration. System migration process is actually a reconstruction of a small system. Many Linux enthusiasts have had the experience of establishing an emergency Linux system disk, and its difference is that you need to use a binary code on the target platform to generate this small system. Comprising: init, libc libraries, the drive module, the required application and system configuration script. Once the work is completed transplantation into the FBI work on the stage.
A relatively easy way to transplant parts of the system are: to set about establishing a small system development platform, to ensure that this system is running correctly on small development platform. This avoids trouble due to the small logic error system itself brought. Since a plurality of small systems applications cooperate with each other, sometimes the problem is not the code itself and the logical structure of the system.
At least porting Linux system to include the above-mentioned content, in addition, there are some unseen development work can not be ignored, such as the driver of a special device for debugging kernel and do remote debugging work. In addition, porting the same time, clearly in a perfect transplant and transplant small feature set is not the same; and migration to 16-bit to 64-bit migration is not the same.
In transplantation often encountered problem is deadlock or crash test run when the system is easier to transplant some part, because you can easily locate the source of the error, and in the heart transplant really a headache. Although you can debug a running kernel via the serial port, but in multitasking situations, there are many things that can not be reproduced. As another example, at the start of initialization, the method determines the state of many devices not even serial not initialized. In this case what is not a good solution, a good development / simulation platform is very important, in addition to more than the increase reflects the state of debugging code running system; furthermore to find out exactly what documents the hardware platform. Hardware platform vendors professional support is also very important.
It is also important: Linux itself is GPL-based operating system, when transplanted, can give full play to the advantages of the GPL, so that more fans involved to move towards a common goal.