Analysis of a Boot Loader used on a microcontroller

Concept and function of Boot Loader

In embedded systems represented by ARM, hardware initialization and kernel image creation before the operating system kernel runs are all completed by Boot Loader. On a PC, the first thing to start is the BIOS on the motherboard. BIOS is responsible for hardware initialization, providing hardware interface functions to the operating system, etc., but there is no BIOS in the embedded operating system, so the entire embedded operating system loading and startup task is completely completed by Boot Loader.




Figure 1 Boot Loader Flowchart

Boot Loader is usually stored in the non-volatile storage medium of the target platform. It is mainly used to complete the transition from hardware startup to operating system startup. It can detect hardware parts such as SDRAM, CACHE, FLASH after power-on, establish a memory space mapping map and kernel image, establish communication channels and debugging channels, etc. It can also provide Shell Menu detection setting menus and corresponding detection programs to guide the operating system and application programs, thereby preparing the correct environment for the final call to the operating system kernel.

At present, Boot Loaders such as UBoot, vivi, blob, armboot, etc., which are widely used in embedded systems, have added more functions and greatly enhanced portability based on their original functions. There are many types of hardware in embedded systems, and the differences are large. Boot Loader is heavily dependent on hardware. Different CPU systems require different Boot Loaders. Even if the same architecture is used, due to the different configurations of other hardware devices, such as the allocation of board hardware addresses and the model of RAM chips, the Boot Loader needs to be modified to be used. Therefore, developers need to customize the Boot Loader for different processors and development boards to achieve different functions.

Boot Loader Operation Mode

Boot Loader usually includes two modes: "Boot loading" and "Downloading". These two operation modes are only meaningful to developers.

Boot Loading Mode: The Boot Loader loads the operating system from the solid-state storage device on the target machine into the RAM to run without user intervention. This mode is the normal working mode of the Boot Loader. Downloading Mode

: In this mode, the Boot Loader on the target machine downloads files from the host to the RAM of the target machine through serial port connection or network connection, and then burns them into the solid-state storage device on the target machine. This mode is usually used when installing the kernel and root file system for the first time and when updating the system.

Specific implementation of Boot Loader

Hardware configuration

This article takes UP-NetARM3000 as an example to introduce the working mechanism and operation process of Boot Loader. UP-NetARM3000 uses the S3C44B0X chip produced by Samsung, which is a cost-effective and high-performance microcontroller launched by Samsung. It has a 32-bit ARM7TDMI core, an external clock of 8MHz, an internal multiplier of up to 72MHz, and an operating frequency of 64MHz. S3C44B0X greatly reduces the configuration of components other than the processor in the system by providing comprehensive and general on-chip peripherals, thereby greatly reducing the cost of the system. It integrates various on-chip functions including: 8KB Cache, extended memory controller, 2-channel UART with handshake protocol, 1-channel SIO, 2 general DMA, 2 peripheral DMA, external storage controller, LCD controller, IIC/IIS bus interface, 5-channel PWM timer and an internal timer, watchdog timer, 71 general I/O ports, 8 external interrupt sources, 8-channel 10-bit ADC, on-chip PLL clock generator, etc.

Boot Loader startup process

Most Boot Loaders are usually divided into two parts: Stage 1 and Stage 2. Stage 1 is usually written in assembly language, that is, the startup code of the Boot Loader, which is intended to initialize some hardware devices. Stage 2 is the main code of the Boot Loader. In order to achieve more complex functions and make the code more readable and portable, it is usually implemented in C language and is mainly used to load the operating system kernel. The specific startup process is shown in Figure 1.

· Stage 1 part

Setting the CPU speed, clock frequency and interrupt control register

The startup code of the Boot Loader first defines a global entry and then sets the exception vector. Since the Boot Loader is heavily dependent on hardware for implementation, the CPU speed, clock frequency and interrupt control register are set according to the CPU architecture and specific hardware configuration. In addition to completing the above functions, the startup code also needs to implement functions such as disabling the watchdog timer, setting the clock control register, setting the phase-locked loop control register, and enabling the clock of all functional units. In addition, the setting of system interrupts is also implemented in this part, mainly the setting of the interrupt vector table and the IRQ interrupt entry address.

Memory allocation

The memory system of S3C44B0X has some main features, such as: supporting big-endian and little-endian selection of data storage; the address space has 8 memory banks, each of which can reach 32MB; the access size of all memory banks can be changed; the starting address of 7 memories is fixed, and the starting address of 1 memory bank is variable. In the Boot Loader introduced in this article, the startup code enables each memory by assigning a value to BUSWIDTH. The specific corresponding situation is shown on the right:

The startup code also has an important task - initializing the memory control register, which is mainly achieved by setting 13 registers starting from 0x01c80000, including the BWSCON bus width and wait state control register and the BANKCONn block control register. The specific value to be assigned to the memory control register is at the label SMRDATA. With the ResetHandler label address as a reference, the actual position of the SMRDATA label address is calculated according to its offset address, and then the data there is read to assign a value to the memory control register.






Figure 2 Image file address mapping

Forming an executable file

In embedded system applications, executable files usually include RO (Read_Only) segments, RW (Read_Write) segments, and BSS segments. When the image file in the memory needs to be burned into the FLASH, the Boot Loader code is usually moved to the high address space of the FLASH first, because the address of RO is usually 0x0, to prevent the Boot Loader code already in the FLASH from being overwritten during burning. When compiling and linking the program, the Read_Only address set by the compiler must be the same as the address of the final code download, as shown in Figure 2.

The address space where the Boot Loader image file finally runs is 0Bank, so the RO Base is set to 0x0, and the RW Base is set to 0x0c60000. After compilation, the executable file in bin format is generated and burned to the FLASH0 address. Before the program runs, the RO segment and the RW segment are all placed in FLASH. The RO segment can run directly in FLASH, while the RW segment must be transferred to SDRAM before it can run. Therefore, during the program running, the RO segment keeps the set 0x0 address unchanged, and the RW segment must be copied to the RW Base, which is the address 0x0c60000, and the ZI segment is initialized to zero.



·Stage 2 Part

Initialize the hardware

Boot Loader After the main program debugs the serial port and detects the hardware involved in this stage, it downloads the image to the target machine through the serial port. The main code defines functions such as LCD_Test(), LED_Test(), ADTest(), KeyTest(), and BootSystem() to test the functions of some hardware. Taking the AD detection function as an example, the specific implementation of the detection function is briefly introduced. ADTest_Loop() is an operation function for AD hardware, while Set_UartLoopFunc() sets ADTest_Loop() to the serial port polling function array (the serial port polling function array also includes other detection functions). The AD detection function queries whether there is a stop command while operating the target. If the Uart_Getch() function does not query the serial port for an input stop command, it calls other functions in the serial port polling array, otherwise it returns immediately.



Detecting memory and booting the system

In the main program of the Boot Loader, it is necessary to detect important hardware-memory. After the detection is completed, prompt information will be output through the serial port and LCD respectively. Next, it will wait to query whether there is a key pressed. When no key is pressed, the operating system is booted normally, otherwise the Shell Menu will be displayed. After

the Boot Loader program obtains control of the system, it detects key hardware and finds no fault. If the console does not issue an activation of the Shell Menu detection menu, it reads the code of the operating system or application from the NAND FLASH to the specified location of the SDRAM according to the management and support of the file system, and then transfers the program pointer to this location, so that the operating system obtains control and completes the boot process.

static void(*run)(void)=(void(*)(void))DOWNLOAD _ADDRESS, this function pointer defined in the program can force the address of the specified location to be converted into a function pointer type, and then use the run() function to run the instruction at the address. In the code that implements the boot function, the loading is completed by opening and reading the specified system file to the specified location DOWNLOAD_ADDRESS(0xc080000), pointing the program pointer to the specified location, and using the run() function to run the instruction at the address to achieve the transfer of control. When you see the startup information of the operating system displayed on the screen, the Boot Loader completes the task and successfully boots the operating system.

Conclusion

This article introduces the transplantation of the Boot Loader of the uCOS system on the UP-NETARM3000 experimental board based on S3C44B0X. Different development boards have different CPU architectures and peripheral hardware devices, but the working mechanism of the Boot Loader is similar. After clarifying the hardware resources of the development board and the specific operating system to be transplanted, the Boot Loader is specifically tailored and modified.