Transplantation Analysis and Function of U-Boot SD Card Boot Based on S3C6410 Processor

    The Universal Bootloader (U-Boot) is the first code executed after the system is powered on. Its main functions include initializing the hardware environment and loading and executing the operating system kernel. When installing the system, U-Boot usually needs to be burned into FLASH using a special tool, and the kernel and file system are burned through U-Boot commands. This process is cumbersome and prone to errors, and is not suitable for mass installation of systems.

    S3C6410 is a general-purpose embedded processor based on ARM11 architecture produced by Samsung. In addition to the traditional Flash boot mode, it also supports booting the system from an SD card. Based on the S3C6410 processor, this paper analyzes the principle of booting the system from an SD card, and modifies the U-Boot source code to support this boot mode. On this basis, the function of U-Boot is further expanded to support one-click installation of the system without the need for a host machine, simplifying the installation and deployment of embedded systems.

    1 U-Boot Working Principle

    The U-Boot startup process is divided into two stages. The first stage is implemented in assembly language and is related to the specific hardware platform; the second stage is implemented in C language with good readability and portability to complete the main functions of U-Boot. The advantage of this design is that the hardware-based code can be separated from the system's general code, so that the system's transplantation work is mainly modified for the first stage code, without or only requiring a small amount of modification to the second stage code, which simplifies the transplantation process and improves system development efficiency.

    The main functions implemented by the first stage of U-Boot code are:

    (1) Initialization of hardware devices;

    (2) Prepare RAM space for loading the second stage of the bootloader (i.e., initialize SDRAM);

    (3) Copy the bootloader second stage code to RAM space (U-Boot copies all its code to RAM);

    (4) Setting up the stack;

    (5) Jump to the entry of the second stage C code.

    When the system completes the code transfer and sets up the stack and other environments used by the C language, it will jump to the second stage code in the memory and continue to run at the C language entry. The main functions completed by the second stage code are:

    (1) Continue to initialize related hardware devices (such as serial ports, system clocks and timers, etc.);

    (2) Check the system memory map;

    (3) Load the kernel image and the root file system image;

    (4) Set kernel startup parameters;

    (5) Call the kernel.

    The second stage of U-Boot will stop and wait for several seconds after setting up the corresponding terminal device. If there is input in the serial port during this period, U-Boot will enter the interactive download mode, loop reading the serial port commands and executing them; if there is no input in the serial port, U-Boot will execute the boot loading mode code, load the operating system kernel into the memory and start the system.

    2 S3C6410 U-Boot SD card boot mode analysis and transplantation

    2.1 S3C6410 SD card boot principle

    S3C6410 supports multiple boot modes, including NOR FLASH boot, NAND FLASH boot, MODEM boot, iROM boot, etc. Among them, iROM boot mode is booting from internal ROM, which can provide support for SD card. The S3C6410 SD card boot process is shown in Figure 1.     

    When the SD card boot mode is selected, the processor will run the firmware program in the iROM after power-on. This program is called BootLoader0 (BL0). After performing some necessary initialization work, it will read 8 KB of U-Boot code from the specified location in the SD card to the internal Step PIN gStone for execution. This code is called BootLoader1 (BL1).

    BL1 is the first 8 KB of U-Boot code. This code will then load BL2 (the entire U-Boot program) from the SD card into the memory and jump to the corresponding address to run.

    2.2 SD card device space layout

    When booting from the SD card, the BL0 program will load the BL1 code from a specific location on the SD card after the system is powered on, so the BL1 code must be placed in a pre-agreed location.

    The spatial layout of the SD card boot partition is shown in Figure 2.     

    As can be seen from the figure, if we want to use the SD card to boot the system, we must burn the 8K code of BL1 to the starting address of the 18th block from the end of the SD card. It is also recommended to place BL2 next to BL1 in the data block in front of it.

    2.3 Add U-Boot support for SD card boot mode From the above analysis, we can see that the key to system transplantation is to copy the code in BL2 from the SD card to the memory for running. Since U-Boot does not support SD card boot by default, it is necessary to modify bnand_boot in the arch/arm/cpu/arm1176/start.S file to b mmc_boot_copy and define the mmc_boot_copy function as:     

    This code uses the firmware function provided by S3C6410 to copy the entire U-Boot in BL2 to the memory and jump to the corresponding entry in the memory to continue running.

    3 Offline one-key installation system function implementation

    The U-Boot version ported in this article is U-Boot-2011.06. This version of U-Boot supports FAT file system file loading commands, and its command format is:

    fatload

    This command can load the file filename in the dev device using the interface into the memory address addr in binary form. Using this command, the kernel and other image files can be loaded from the SD card into the memory first, and then the system can be burned and installed through the FLASH command.

    However, the use of the above commands is based on the interactive terminal. To realize the automatic operation of the commands, the U-Boot source code needs to be analyzed and modified. Reading the U-Boot source code, we can see that the second stage code will eventually enter the main_loop function in the common/main.c file. In the download mode, U-Boot will loop to read the commands entered by the user and call the run_command function to execute. Its function prototype is:

    int run_command(const char *cmd,int flag);

    Among them, cmd is the command string, flag indicates whether the command is executed repeatedly, and the return value indicates whether the command is executed successfully or not. Therefore, calling the run_command function with the installation command string to be executed as a parameter can automatically execute the command and realize the offline installation of the system. In addition, in order to make the system installation more flexible and convenient, a configuration file is added in this implementation to set the relevant parameters in the installation. The path and name of the configuration file are fixed as /images/chd_cfg.ini, and its content is as follows:     

    All lines starting with "#" are comment lines. The OS variable indicates the type of operating system to be installed. The following OS-BootLoader, OS-Kernel, and OS-RootFs variables respectively indicate the paths of the Bootloader, kernel, and file system to be installed in the Flash in the SD card. By first parsing the configuration file and then loading and installing the relevant image from the SD card, the system can be easily replaced. You only need to modify the configuration parameters in the file. The implementation process is shown in Figure 3.     

    4 Experimental Results

    Compile the modified U-Boot and burn it to the corresponding location in the SD card. Set S3C6410 to SD card boot mode. The serial port output information after power-on is shown in Figure 4.

    Figure (1) is the output information of reading the configuration file chd_cfg.ini. It can be seen that the file has a total of 314 characters. (2) is the output display of the parameters after the file is parsed. (3) and (4) respectively show the loading and burning process of U-Boot and the kernel. After successful burning, it enters (5), where the program enters an infinite loop and prompts to restart the system. Figure 5 shows the output when the system is subsequently started in NAND mode.     

    In the figure, (1) is the terminal output after the U-Boot is started and burned into the Nand Flash, and (2) is the print information when the boot kernel is loaded. From this result, it can be seen that the offline burning of the system has been successfully performed.

    5 Conclusion

    This paper modifies and transplants U-Boot-2011.06 to support the SD card boot mode of the S3C6410 processor, analyzes its principle, and expands U-Boot, adding the function of installing the entire system using only an SD card, and verifies it experimentally. The results show that this method is feasible, can simplify the installation of embedded systems, and enhances the functions of U-Boot. It has a certain reference value for the transplantation and improvement of U-Boot on other platforms.