Research on a New BootLoader Boot Method

BootLoader is usually called "system boot loader" and is the first program code executed after the system is powered on or reset [1]. The main task of this program is to initialize the hardware devices and establish a memory space mapping map, so as to bring the system's hardware and software environment to a suitable state, so as to prepare the correct environment for the final call to the operating system kernel or user application. Generally, BootLoader includes two different loading and booting modes, namely, boot loading mode and download mode.

① Boot loading mode. This boot mode is also called "autonomous boot mode", that is, BootLoader loads the operating system from a solid-state storage device on the target machine into RAM and boots it to run. There is no user intervention in the whole process. This boot mode is a boot mode commonly used in the normal working mode of BootLoader. Therefore, when embedded products are released, BootLoader generally boots the kernel code in this boot mode.
② Download (down loading) mode. In this boot mode, the BootLoader on the target machine will download files from the host through communication means such as serial port connection or network connection, such as downloading applications, data files, kernel images, etc. The files downloaded from the host are usually first saved by BootLoader to the RAM of the target machine, and then written by BootLoader to the solid-state storage device on the target machine, and then the kernel boot operation is completed. This boot mode of BootLoader is usually used in system development and update.

In the embedded system development stage, the existing BootLoader download boot methods can be divided into the following types according to different loading paths:

① Download the kernel from the host machine to the target board through the Ethernet port to start the software system;
② Download the kernel from the host machine to the target board through the serial port to start the software system;
③ Directly extract the stored kernel from the Flash to start the software system.

Summarizing the above boot methods, we can find that they have some common disadvantages; when debugging the system, it is necessary to actually connect the hardware lines between the host and the target board, which is not convenient to use, and the speed of burning the chip is relatively slow, and the debugging efficiency is not high; the hardware needs the support of large-capacity Flash, which increases the R&D cost; it is not flexible enough when updating the kernel. For this reason, a removable storage medium is used to store the system kernel (such as SD card, CF card, etc.), so as to achieve flexible debugging and booting of the system kernel. The advantage of this boot method is that there is no need to connect the host and the target board by hardware during debugging, which improves the debugging efficiency and is more convenient and flexible to use; it is more flexible when updating the kernel, and only needs to transfer the updated kernel to the specified directory, and its implementation is also relatively simple. To make this improvement, you only need to do the following: In terms of hardware, add hardware circuits for specific mobile storage media. In medium and large systems, the hardware circuits for mobile storage media (such as SD cards, CF cards, etc.) are ready-made, so the hardware part can also be ignored; inside the BootLoader program, you only need to add instructions for storage access based on the file system for mobile storage media (such as CF cards, SD cards, etc.). According to this idea, the original BootLoader was improved for the SD card of mobile devices based on the existing hardware platform. The implementation process is introduced below.

1 Hardware Platform

The hardware platform for this improvement test is the LPC22EB06I experimental platform based on the LPC2294 ARM controller developed by Embest. Its main functional modules are:

① 2 MB Flash, 1 MB SRAM (expandable to 4 MB), 256B E2PROM with I2C interface and other memories;
② 2 RS232 (one of which can be connected to Modem), RS485, CAN and other communication bus interfaces;
③ 2 debug interfaces: LPT and JTAG debug interfaces;
④ Support CF card, SD/MMC and other mobile storage media;
⑤ Support 128×128 true color display.

Figure 1 is its hardware functional block diagram.

Figure 1 Functional block diagram of LPC22EB06I development platform

2 Improved Design of BootLoader

2.1 Original BootLoader Function

The original BootLoader has the following functions:

① Serial port download function, download the kernel to the specified RAM area through the serial port;
② Flash burning function, burn data from the RAM area to the Flash;
③ Block movement function in the data area;
④ Other functions. Its instruction encapsulation structure is as follows:

struct _CMD_TBL ​​{
char *cmd; //command word
bool(*run)(struct _CMD_TBL*cptr,int argc,char**argv); //point to the specific function processing function
char*usage; //command usage information
char*help; //help information
char*helpMore;
};

For example, the Flash programming command is encapsulated as follows:

CMD_TBL_FLASH
{"flash",DoWriteToFlashBlocks,
"flash {loader/kernel/root} {block1/.../block16}\n"
" Copy to Flash from SDRAM of Area.\n"
"flash [dest] [src] [ len]\n" \
" Copy to Flash from src to dest.\n",
"flash {loader/kernel/root} {block1/.../block16}\n"
" Copy to Flash from SDRAM.\n" ,
"flash {loader/kernel/root} {block1/.../block16}\n"
" Copy to Flash from SDRAM of Area.\n"
"flash [dest] [src] [len]\n"
" Copy to Flash from src to dest.\n"
}[page]

Among them, flash is the command word; DoWriteToFlashBlocks is the method name of its processing method; flash {loader/kernel/root} {block1/.../block16} and flash [dest] [src] [len] are the usage formats of its commands (options in “{}” are optional, and options in “[]” are required).

2.2 BootLoader Improvement Experiment

This improvement is based on the original BootLoader by adding instructions to read data from the mobile storage medium SD card in FAT format. The command package is as follows:
CMD_TBL_SD_READ
{"readSD", DoReadFromSDBlocks,
"readSD [filename] [addr] Read data from SD to SDRAM for startup.\n",
"readSD [filename] [addr] Read data from SD to SDRAM for startup.\n",
"readSD [filename] [addr] Read data from SD to SDRAM for startup.\n"
}
Its function is to extract the kernel file in the specified directory in the SD card to the SDRAM area, thereby completing the loading of the kernel.

Three additional auxiliary instructions are added, one to complete the formatting of the SD card, another to complete the saving of the system kernel, and the last to complete the startup loading of the system kernel. The command is encapsulated as follows:
CMD_TBL_SD_FORMAT{
"formatSD",DoFormatSDCard,
"formatSDformat SD card with FAT\n",
"formatSDformat SD card with FAT\n",
"formatSDformat SD card with FAT\n"
}
CMD_TBL_SD_STORE{
"SDstore", DoStoreToSDBlocks,
"SDstore \[addr] {kernel/rootfs}\n"
kernel/rootfs fromSDRAMto SD card.\n",
"SDstore [addr] {kernel/rootfs}\n"
"Store kernel/rootfs fromSDRAM to SD card.\n",
"SDstore [addr] {kernel/rootfs}\n"
"Store kernel/rootfs fromSDRAM to SD card.\n"
}
CMD_TBL_SD_LOAD{
"SDload", DoLoadFromSDBlocks,
"SDload [addr] {kernel/rootfs}\n"
"Load kernel/rootfs from SD card toSDRAM.\n",
"SDstore [addr] {kernel/rootfs}\n"
"Load kernel/rootfs from SD card toSDRAM.\n",
"SDstore [addr] {kernel/rootfs}\n"
"Load kernel/rootfs from SD card toSDRAM.\n"
}

Among them, the function of CMD_TBL_SD_FORMAT is to complete the formatting of the SD card, the function of CMD_TBL_SD_STORE is to back up the kernel code in the SDRAM area to the fixed storage area of ​​the SD card, and the function of CMD_TBL_SD_LOAD is to load the kernel code in the fixed storage area of ​​the SD card into the specified SDRAM area.

The following is an analysis of the specific reading and backup methods based on the FAT file system. First, let's take a look at the basic structure of the FAT file system. The overall structure of the FAT file system is roughly composed of four parts: MBR area (master boot record area), DBR area (DOS boot record area), FAT area (file allocation table area, FAT1 is the main file allocation table area, FAT2 is the backup file allocation table area) and DATA area (data area, including FDT area - file directory table area). The FAT file system structure is as follows:

The base sector addresses of each area (taking the base sector address of the MBR area as 0) are calculated as follows:

Base sector address of DBR area = Base sector address of MBR + 63
Base sector address of FAT table = Base sector address of DBR + Number of reserved sectors
Base sector address of FDT area = Number of sectors per FAT table × Number of FAT tables + (Starting cluster number 2 of FDT area) × Number of sectors per cluster + Base sector address of FAT table. (Cluster is the unit for file management in the system. Each item in the FAT table corresponds to a cluster. File access is performed by cluster. One cluster contains several sectors.)

From the organizational structure of the FAT file system, it can be seen that it is relatively easy to read the system kernel code data from the SD card to the specified RAM area, that is, to search and locate the system kernel file name in the file system, and then complete the reading. For the backup and loading of the kernel code, it is necessary to do some processing on the SD card formatting based on the in-depth analysis of the organizational structure of the FAT file system. During formatting, the purpose of not formatting the last 8 MB area of ​​the SD card storage area (which can be increased or decreased according to actual needs) is achieved by setting the data in the MBR area and the DBR area, that is, setting it as the RAW area. Therefore, the implementation of the system kernel backup is to fill the system kernel code into the RAW area through the write instruction of the SD card. The loading of the system kernel is to directly read the backed-up kernel code from the RAW area.

3 Conclusion

The kernel loading boot boot method described in this article has been verified in practice. It realizes the complete disconnection of the hardware line connection between the target board and the host machine, provides convenience for system debuggers, and effectively improves the efficiency of system debugging; at the same time, it can also easily realize the online update of the system. It can be said that this method is a good choice for system boot boot design. Finally, it should be noted that the BootLoader improvement method introduced in this article is completed on the LPC22EB06I experimental platform developed by the LCP2294 chip. Since the BootLoader is closely related to the processor architecture and the configuration of specific embedded board-level devices, if the above method is to be used on other processor chips or platforms, it is also necessary to make appropriate modifications to the code related to the processor architecture in the BootLoader. This part is not the main content of this article, so it will not be described in detail here. If readers want to know more about the relevant content, please refer to relevant papers or books.

References

[1] Xu Yuqing, Huang Yanping, et al. Analysis of Bootloader Technology of S3C44B0X [J]. Journal of Shanghai University of Technology, 2005, 27 (4): 369-372.
[2] Yuan Jiandong, Zhao Qiang, Zheng Jianling. Analysis and Acquisition Method of FAT32 Partition Information under Windows System [J]. Hebei Industrial Science and Technology, 2007, 24 (1): 11-14.
[3] Microsoft Corporation. Microsoft Extensible Firmware Initiative FAT32 File System Specification. Version 1.03, 200012.
[4] SanDisk Corporation. SanDisk Secure Digital Card Product Manual. Version 2.2, 200409.
[5] Zeror. Detailed Analysis of Hard Disk FAT File System Principle [OL]. http://www.5421.net, 200404.