Universal Bootloader (U-Boot) is the first piece of code executed after the system is powered on. Its functions mainly include initializing the hardware environment and loading and executing the operating system kernel. When installing the system, U-Boot usually needs to be programmed into FLASH using special tools, and the kernel and file system are programmed through U-Boot commands. This process is cumbersome and error-prone, and is not suitable for large-scale installation of the system.
S3C6410 is a general-purpose embedded processor based on ARM11 architecture produced by Samsung. In addition to the traditional Flash startup mode, its startup method also supports booting the system from the SD card. Based on the S3C6410 processor, this article analyzes the principle of booting the system from the SD card, and modifies the U-Boot source code to support this boot method. On this basis, it further expands the functions of U-Boot to support systems that do not require a host. In the case of a host, the system can be installed with one click, simplifying the installation and deployment of embedded systems.
1 U-Boot working principle
The startup process of U-Boot is divided into two stages. The first stage is implemented by assembly language and is related to the specific hardware platform; the second stage is implemented by C language with better readability and portability to complete the main functions of U-Boot. The advantage of this design is that it can separate the hardware-based code from the general code of the system, so that the system transplantation work mainly modifies the first-stage code without requiring or only requiring a small amount of modifications to the second-stage code, which simplifies the transplantation process. Improved system development efficiency.
The main functions implemented by U-Boot's first phase code are:
(1) Initialization of hardware devices;
(2) Prepare RAM space for the second stage of loading bootloader (i.e. initialize SDRAM);
(3) Copy the second stage code of bootloader to RAM space (U-Boot copies all its code to RAM);
(4) Set up the stack;
(5) Jump to the entrance 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 C language entrance of the second-stage code in the memory to continue running. 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) Detect system memory mapping;
(3) Load the kernel image and root file system image;
(4) Set kernel startup parameters;
(5) Call the kernel.
In the second stage, U-Boot will stop waiting for a few seconds after setting up the corresponding terminal device. If there is input to the serial port during this time period, U-Boot will enter the interactive download mode, read the serial port commands in a loop and execute them; if the serial port If there is no input, U-Boot executes the boot load mode code, loads the operating system kernel into memory and starts the system.
2 S3C6410 U-Boot SD card boot mode analysis and transplantation
2.1 S3C6410 SD card startup principle
S3C6410 supports multiple startup methods, including NOR FLASH startup, NAND FLASH startup, MODEM startup, iROM startup, etc. The iROM boot mode is booting from internal ROM. This mode can provide support for SD cards. The S3C6410 SD card startup process is shown in Figure 1.
When the SD card boot mode is selected, after the processor is powered on, it will run the firmware program in the iROM. This program is called BootLoader0 (BL0). It will read from the specified location in the SD card after performing some necessary initialization work. Take 8 KB of U-Boot code and run it in the internal StepPINgStone. This code is called BootLoader1 (BL1).
BL1 is the first 8 KB code of U-Boot. 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 space layout of the SD card boot partition is shown in Figure 2.
As can be seen from the picture, if we want to use the SD card to start 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 immediately next to BL1 in front of it. in the data block.
2.3 Add U-Boot support for SD card startup mode. From the above analysis, it can be seen 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 startup by default, you need 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 realize the function of copying the entire U-Boot in BL2 to the memory, and jumping to the corresponding entry of the memory to continue running.
3 Implementation of offline one-click installation system function
The U-Boot version transplanted in this article is U-Boot-2011.06. This version of U-Boot supports the FAT file system file loading command, and its command format is:
fatload
This command can load the file filename in the dev device using the interface interface into the memory address addr in binary form. Using this command, you can first load image files such as the kernel into the memory from the SD card, and then use the FLASH command to program and install the system.
However, the use of the above commands is based on the interactive terminal. If you want to realize the automatic running of the commands, you need to analyze and modify the U-Boot source code. Reading the U-Boot source code shows that the second stage code will eventually enter the main_loop function in the common/main.c file. In download mode, U-Boot will loop through the commands entered by the user and call the run_command function for execution. The function prototype is:
int run_command(const char *cmd,int flag);
cmd is the command string, flag indicates whether the command is executed repeatedly, and the return value indicates whether the command execution is successful or not. Therefore, calling the run_command function with the installation command string that needs to be executed as a parameter can automatically execute the command and implement offline installation of the system. In addition, in order to make system installation more flexible and convenient, a configuration file is added to this implementation to set relevant parameters during installation. The path and name of the configuration file are fixed at /images/chd_cfg.ini, and its content is as follows:
Among them, all the behavior comment lines starting with "#", the OS variable indicates the type of operating system that needs to be installed, the following OS-BootLoader, OS-Kernel, and OS-RootFs variables respectively indicate the Bootloader and kernel that need to be installed in Flash. , the path of the file system 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 by simply modifying 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 the S3C6410 to the SD card startup mode. The serial port output information after power-on is shown in Figure 4.
In the 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 parsing the file. (3) and (4) respectively What is shown is the loading and programming process of U-Boot and kernel. After successful programming, enter (5), where the program enters an infinite loop and prompts to restart the system. Figure 5 shows the output when the system is subsequently booted using NAND mode.
In the figure (1) is the terminal output after the U-Boot programmed into the Nand Flash is started, (2) is the printed information when the boot kernel is loaded. From this result, it can be seen that the system has been successfully programmed offline.
5 Conclusion
This article has modified and transplanted U-Boot-2011.06 to support the SD card boot mode of the S3C6410 processor, analyzed its principles, and expanded U-Boot to add the function of installing the entire system using only the SD card. and carried out experimental verification. The results show that this method is feasible, can simplify the installation of embedded systems, enhance the functions of U-Boot, and has certain reference value for the transplantation and improvement of U-Boot on other platforms.
Previous article:Home monitoring moving target detection system based on S3C6410 processor and Linux
Next article:FFMPEG video encoding and decoding process H.264 hardware encoding and decoding implementation
Recommended ReadingLatest update time:2024-11-15 15:38
Professor at Beihang University, dedicated to promoting microcontrollers and embedded systems for over 20 years.
- LED chemical incompatibility test to see which chemicals LEDs can be used with
- Application of ARM9 hardware coprocessor on WinCE embedded motherboard
- What are the key points for selecting rotor flowmeter?
- LM317 high power charger circuit
- A brief analysis of Embest's application and development of embedded medical devices
- Single-phase RC protection circuit
- stm32 PVD programmable voltage monitor
- Introduction and measurement of edge trigger and level trigger of 51 single chip microcomputer
- Improved design of Linux system software shell protection technology
- What to do if the ABB robot protection device stops
- Download from the Internet--ARM Getting Started Notes
- Learn ARM development(22)
- Learn ARM development(21)
- Learn ARM development(20)
- Learn ARM development(19)
- Learn ARM development(14)
- Learn ARM development(15)
- Analysis of the application of several common contact parts in high-voltage connectors of new energy vehicles
- Wiring harness durability test and contact voltage drop test method
- From probes to power supplies, Tektronix is leading the way in comprehensive innovation in power electronics testing
- [NUCLEO-L552ZE review] +Serial communication test
- Please help me look at the circuit diagram of this electric pen. How should I choose between the two SOT23 devices?
- Raspberry Pi 4B and other information sharing
- Design of temperature measurement system based on msp430 single chip microcomputer
- 【VOFA+】 Makes graphical debugging as simple as a serial port assistant
- Single power supply single op amp second order filter plus DC bias (cannot be isolated)
- What is the difference between power inlet power filtering and common mode inductance?
- Book now to get a gift: 2019 Keysight Electronic Measurement Basics Online Lecture Series
- Embedded Systems: Composition, Principles and Design Programming
- Compile and run the SRTC capacitive touch experiment on the IMX6ULL development board