Implementation of booting embedded system based on ARM-μCLinux

32-bit ARM embedded processors have the characteristics of high performance and low power consumption, and have been widely used in consumer electronics, wireless communications, network communications and other fields. ΜCLinux is an embedded operating system designed specifically for MMU-less processors, supporting ARM, Motorola and other microprocessors. At present, it is very common to use ARM-μCLinux as an embedded system at home and abroad. The boot technology of embedded systems is a difficult point in the development of embedded systems. The success or failure of system boot determines whether the operating environment of the application can be correctly built, that is, the successful system boot is the prerequisite for the correct operation of the application.

The commonly used method for starting an embedded system is to first use JTAG to insert the kernel of the embedded operating system into Flash, and then use the bootloader to complete the booting of the embedded system. This method requires the help of expensive JTAG equipment to complete the burning of the operating system kernel, and it is not convenient to update the software platform in the embedded system. This paper proposes a booting solution based on the ARM-μCLinux embedded system, which can not only conveniently update the software platform in the embedded system through a simple serial port, but also successfully solve the problems of starting, initializing, solidifying and booting the kernel of the operating system of this architecture. This paper briefly describes the hardware platform and software platform of the ARM-μCLinux embedded system; describes the design of the system bootloader, explains the factors to be considered in the design and the technical difficulties to be solved, and gives a set of feasible boot program processes; for the boot program of the μCLinux kernel, it explains the loading and initialization process of the μCLinux kernel.

1 System composition

A typical ARM embedded system hardware platform generally includes a processor with ARM as the core, memory and necessary external interfaces and devices. In this system, Samsung's S3C4510 processor with embedded ARM7TDMI is used, and the memory uses 2MB Flash and 16MB SDRAM. In addition to the serial port for downloading and communication, the external interface is also equipped with an Ethernet interface to support the network function of S3C4510.

The software platform consists of the following parts: system boot program, embedded operating system kernel, and file system. The system boot program is also commonly called bootloader. Although the code volume is small, it plays a very important role. It is equivalent to the BIOS on the PC. It is responsible for solidifying the operating system kernel into the Flash and initializing the system, and then handing over the system control to the operating system. The embedded operating system kernel is the management platform after the embedded system is powered on and running, responsible for the management of real-time tasks and multi-tasks. ARM7TDMI is a processor without MMU, so μCLinux is used as the operating system kernel of this system. ΜCLinux is a branch of Linux, designed for processors without MMU. It inherits the powerful network function and multi-task management function of Linux, and rewrites the memory management and process management to meet the development requirements of processors without MMU. The file system is the part of the embedded system software platform that occupies the largest storage space, and it is also the part most related to user development. It stores system configuration files, system programs, user applications, and necessary drivers.

The software platform is solidified in Flash. The address space of Flash is usually partitioned according to the content of the software platform, generally divided into three areas, respectively storing the bootloader, μCLinux kernel and file system. There are generally two ways of partitioning: one is to allow the bootloader, kernel and file system to have their own fixed partitions and first addresses based on the predetermined storage space of the three parts; the other is to store one part immediately after another according to the actual allocation interval of the three parts, without fixed partitions and first addresses. The first method is usually used. Although it may waste part of the Flash space, it is convenient for loading the kernel and mounting the file system, and it is also conducive to system debugging and development. If you want to make full use of the storage interval of Flash and save costs, then the second method can be used.

2 Design of system boot program

The system bootloader is the first program executed after the embedded system is powered on. When designing its function, the following issues must be considered first:

(1) Solidify the μCLinux kernel and file system in Flash

There are many ways to solidify the μCLinux kernel and file system in Flash. The host can burn the kernel and file system image files to the specified Flash location through the JTAG port; it can also download the image file to Flash through the Ethernet interface; it can also be burned to Flash through the serial port. The download speed of the first two methods is much faster than the latter method. In this system, the serial port is used to burn Flash. This is because on the one hand, it is convenient and cheap to configure a serial port, while JTAG burning also requires the configuration of expensive JTAG emulators and related drivers and protocol conversion programs, and network port downloads also require Ethernet support; on the other hand, μCLinux prints its running information through the serial port by default, so the serial port can not only provide the function of burning Flash, but also serve as a channel for debugging the μCLinux kernel.

In this system, Flash only stores the bootloader at the beginning, and has not yet stored the μCLinux kernel and file system. Therefore, after the system is powered on and the bootloader completes the initialization work, it must initialize a serial port channel connecting the host and the target machine and provide a serial port download function. [page]

(2) System initialization

Because the operating system kernel has not been loaded when the system is just powered on, the system initialization work is completed by the bootloader. It mainly initializes the system, initializes the storage system, configures the data stack in various modes of ARM, enables the screen interrupt, and switches the processor mode and state as needed.

(3) μCLinux kernel loading method

There are two ways to run the μCLinux kernel solidified in Flash: one is to run the μCLinux built-in boot program directly in Flash; the other is to copy the kernel solidified in Flash to a certain address range of SDRAM, and then run the uCLinux kernel from the first address of this address range.

The first method is that after the bootloader performs system initialization, it jumps to the first address of the kernel fixed in Flash, hands over control to μCLinux, and starts to execute the kernel's own boot program in Flash sentence by sentence, and the boot program completes the kernel loading work. This method is currently used by many embedded systems to start the kernel, and it is also the kernel loading method used by this system.

The second method is that after the bootloader completes the system initialization work, it copies the kernel image file from Flash to SDRAM, and then executes the μCLinux kernel boot program from SDRAM to load the μCLinux kernel.

The second loading method runs the program in SDRAM, so the execution speed is faster than the first method, and this loading method can be achieved through RAM fast boot technology. It is mainly for NAND Flash. The biggest difference from NOR Flash is that NOR Flash uses memory random read technology, and like SDRAM, it can directly execute the program stored in Flash; while NAND can directly use memory random read technology, which reads a whole block of memory at a time, so it cannot directly execute the program stored in NAND Flash. The program in NAND Flash must be copied to SDRAM first, and then executed in SDRAM. However, NAND Flash is cheaper than NOR Flash, so many embedded systems still use NOR Flash (hundreds of K bytes) + NAND Flash (several megabytes) storage mode. Among them, NOR Flash stores executable bootloaders with small code volume and some necessary data, while NAND Flash stores kernels and file systems with large storage volume.

In this system, since NOR Flash is used to store the bootloader, kernel and file system, the first address of the kernel address range can be directly accessed to execute the kernel's own boot program. The kernel's own boot program is powerful and can easily load the kernel and pass relevant hardware parameters to the kernel. This system uses the first loading method.

(4) Switching between boot mode and kernel boot mode

Bootloader generally implements two startup modes: self-boot mode and kernel startup mode. Self-boot mode is also called bootstrap mode. The main function of this mode is that the target machine communicates with the host through the serial port. It can receive image files sent by the host, such as kernel, file system and application, and solidify them in Flash. It can also upload image files in Flash to the host. Kernel startup mode allows the embedded system to load the μCLinux kernel after power-on and hand over the system to the μCLinux operating system for management.

In this system, a switch is used to implement the abstraction of switching between the two modes. When there is only a bootloader in the system's Flash, first pull up the switch to prompt the system to enter the bootstrap mode. After power-on, the bootloader enters the bootstrap mode according to the state of the switch and receives the kernel and file system image files sent by the host. Then pull down the switch to prompt the system to enter the kernel boot mode. Press the button again, and the bootloader enters the kernel boot mode according to the switch state at this time, loads the kernel and file system, and the operating system takes over the system. In the future, you can also set the state of the switch as needed to prompt the system to enter different boot modes.

(5) Configuration and remapping of address mapping table

The configuration of the address mapping table includes setting the Flash address space, SDRAM address space, external I/O address range and processor register address range. After the ARM processor is powered on, it executes the code at address 0x0. Therefore, when powered on, the Flash address space storing the bootlader is first set to 0x0-0x200000, and the SDRAM address space is set to 0x1000000-0x2000000. After the kernel boot program copies the kernel to SDRAM, the SDRAM address space is set to 0x00x1000000, and the Flash address space is set to 0x1800000-0x1A00000. This requires remapping the address space of Flash and SDRAM in the kernel boot program.

3 Loading and initialization of the μCLinux kernel

In this startup scheme, the boot program that comes with μCLinux is used to load the kernel. The boot program code is in the linux/arch/armnommu/boot/compressed directory, among which Head.s plays the most critical role, and it completes most of the work of loading the kernel; Misc.c provides the subroutines required to load the kernel, among which the subroutine for decompressing the kernel is an important program called by Head.s. In addition, the kernel loading must also know the necessary hardware information of the system, which is in hardware.h and referenced by Head.s.

When the bootloader hands over the control to the kernel's boot program, the first program executed is Head.s. The following is an introduction to the main process of Head.s loading the kernel based on this system. Head.s first configures the system registers of S3C4510; then initializes the ROM, RAM, and bus control registers of S3C4510, and sets the address ranges of Flash and SDRAM to 0x0-0x200000 and 0x1000000-0x2000000 respectively; then copies the kernel image file from Flash to SDRAM, and remaps the address ranges of Flash and SDRAM to 0x1800000-0x1A00000 and 0x0-0x1000000 respectively; then calls the decompression kernel function (decompress_kernel) in Misc.c to decompress the kernel image file copied to SDRAM; finally jumps to the execution call kernel function (call_kernel) to hand over the control to the decompressed μCLinux system.

Executing the Call_kernel function actually executes the start_kernel function in linux/init/main.c, which includes important tasks such as processor structure initialization, interrupt initialization, process-related initialization, and memory initialization.

This boot boot solution realizes the boot mode and kernel boot mode and the switching between the two modes, so that developers can use the boot mode to conveniently burn Flash and update the software platform in the embedded system, and can also switch to the kernel boot mode to automatically and safely start the system; secondly, this solution uses a simple serial port channel as the communication channel between the host and the target system, which can not only conveniently download the operating system kernel, file system and other applications to the target system, but also serve as a channel for debugging the μCLinux kernel and application programs; in addition, in view of the MMU-free characteristics of ARM7TDMI, the modified μCLinux kernel boot program is used to load the operating system and initialize the operating system environment, solving the address remapping problem of kernel loading and the memory management problem of the operating system.