BootLoader Improvement Method Based on LPC22EB06I Experimental Platform

    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, the boot loading mode and the download mode.

    ① Boot loading mode. This boot mode is also called "autonomous boot mode", that is, the BootLoader loads the operating system from a solid-state storage device of the target machine into the RAM and boots it to run. The whole process does not involve the user. This boot mode is a commonly used boot mode in the normal working mode of the BootLoader. Therefore, when an embedded product is released, the 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 to the RAM of the target machine by the BootLoader, and then written to the solid-state storage device on the target machine by the BootLoader, and then the kernel boot operation is completed. This boot mode of BootLoader is usually used during 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 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 chips 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 a Modem), RS485, CAN and other communication bus interfaces;

    ③ 2 debugging interfaces: LPT and JTAG debugging 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, burning data from RAM area to Flash;

    ③ Block movement function within 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} "

    " Copy to Flash from SDRAM of Area. "

    "flash [dest] [SRC] [len] "

    " Copy to Flash from src to dest. ",

    "flash {loader/kernel/root} {block1/.../block16} "

    " Copy to Flash from SDRAM. ",

    "flash {loader/kernel/root} {block1/.../block16} "

    " Copy to Flash from SDRAM of Area. "

    "flash [dest] [src] [len] "

    " Copy to Flash from src to dest. "

    }

    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 (“{}” is optional, “[]” is required).

    2.2 BootLoader Improvement Experiment

    This improvement is based on the original BootLoader, 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. ",

    "readSD [filename] [addr] Read data from SD to SDRAM for startup. ",

    "readSD [filename] [addr] Read data from SD to SDRAM for startup. "

    }

    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 package is as follows:

    CMD_TBL_SD_FORMAT{

    "formatSD",DoFormatSDCard,

    "formatSDformat SD Card with FAT ",

    "formatSDformat SD card with FAT ",

    "formatSDformat SD card with FAT "

    }

    CMD_TBL_SD_STORE{

    "SDstore", DoStoreToSDBLOCks,

    "SDstore [addr] {kernel/rootfs} "

    "Store kernel/rootfs fromSDRAMto SD card. ",

    "SDstore [addr] {kernel/rootfs} "

    "Store kernel/rootfs fromSDRAM to SD card. ",

    "SDstore [addr] {kernel/rootfs} "

    "Store kernel/rootfs fromSDRAM to SD card. "

    }

    CMD_TBL_SD_LOAD{

    "SDload", DoLoadFromSDBlocks,

    "SDload [addr] {kernel/rootfs} "

    "Load kernel/rootfs from SD card toSDRAM. ",

    "SDstore [addr] {kernel/rootfs} "

    "Load kernel/rootfs from SD card toSDRAM. ",

    "SDstore [addr] {kernel/rootfs} "

    "Load kernel/rootfs from SD card toSDRAM. "

    }

    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:

    The base sector address of the DBR area = the base sector address of the MBR + 63

    The base sector address of the FAT table = the base sector address of the DBR + the number of reserved sectors

    The base sector address of the FDT area = the number of sectors per FAT table × the number of FAT tables + (the starting cluster number 2 of the FDT area) × the number of sectors per cluster + the base sector address of the FAT table. (The cluster is the unit for file management in the system. Each item in the FAT table corresponds to a cluster. Files are accessed by clusters. A 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 in the file system according to the system kernel file name, 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.