Bootloader boot Guide (SD card boot)

Http://www.elecfans.com/article/87/107/2009/2009032939161.html

 

During large-scale embedded system development, bootloader is often required to load and boot the system kernel. Most of the existing boot and boot modes require the line between the target machine and the host machine.
Connection, which is inconvenient to use and inefficient. Based on the analysis of the existing loading and boot guide methods, this paper proposes an improved method, that is, using removable devices based on the FAT file system as the loading and startup methods.
And analyzes the process of loading and starting the boot kernel.

Keywords
Bootloader FAT file system boot Guide

Introduction

Bootloader is generally referred to as the "System Boot Loader". It is the first program code executed after the system is powered on or reset [1]. The main task of this program is to implement the hardware device
First, and establish a map of memory space, so as to bring the system's hardware and software environment to a suitable state, in order to finally call the operating system kernel or user applications to prepare the correct environment. Connect
Usually, bootloader contains two different loading and boot modes, namely the start loading mode and download mode.

① Boot
Loading) method. This Bootstrap mode is also known as the autonomous (autonomous) bootstrap mode, that is, the operating system is mounted by the bootloader from a solid-state storage device of the target machine.
Load to Ram and boot the operation. No user intervention is involved in the whole process. This Bootstrap mode is a commonly used Bootstrap mode in normal operating mode of bootloader. Therefore, in embedded products
During deployment, bootloader generally starts the kernel code in this boot mode.
② Download (down
Loading) method. In this mode, the bootloader on the target machine will download files from the host by means of serial port connection or network connection, such as downloading applications, data files,
Kernel image. Files downloaded from the host are usually saved to the ram of the target machine by bootloader, and then written to the solid state storage device of the target machine.
Complete the boot operation of the kernel. This Bootstrap mode of bootloader is usually used in system development and updating.

In the development phase of embedded systems, the existing bootloader download guide methods can be divided into the following types based on different loading methods:

① Download the kernel from the host to the target board through the Ethernet port to enable the software system;
② Download the kernel from the host 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.

Summary of the above guidance methods will find that they have some common drawbacks. During system debugging, the actual connection between the hardware line between the host machine and the target board is not convenient enough, and the speed of slice burning
It is relatively slow, and debugging efficiency is not high. In terms of hardware, large-capacity Flash is required, which increases R & D costs. It is not flexible enough to update the kernel. Therefore, the system uses removable storage media
Core for storage (such as SD card, CF card, etc.), to achieve flexible debugging and boot of the system kernel. The advantage of this mode of guidance is that you do not need to connect the host machine to the target board during debugging, which improves debugging.
It is more convenient and flexible to use. When updating the kernel, it is more flexible. You only need to store the updated kernel to the specified directory. In addition, its implementation is relatively simple. To make improvements in this area, you only need to do the following:
In terms of hardware, hardware circuits for specific mobile storage media are added. In medium and large systems, hardware circuits for Mobile storage media (such as SD card and CF card) is ready-made, so hard
Parts can also be ignored. Inside the bootloader program, you only need to add instructions for storing and accessing mobile storage media (such as the CF card and SD card) based on the file system. In this way, the existing hardware
Based on the platform, the original bootloader is improved for SD cards of mobile devices. The following describes the implementation process.

1. Hardware Platform

The hardware platform for this improvement test is the lpc22eb06i experimental platform developed by intime Based on the lpc2294 arm controller. Its main functional modules include:

① 2 MB flash, 1 mb sram (expandable to 4 MB), 256b E2PROM with I2C interface and other memory;
② Two RS232 (one of which can be connected to modem), RS485, can and other communication bus interfaces;
③ Two debugging interfaces: LPT and JTAG;
④ Mobile storage media such as CF card and SD/MMC are supported;
⑤ Supports 128x128 true color display.

Figure 1 shows the hardware function diagram.

Figure 1 functional diagram of the lpc22eb06i Development Platform

2. Improved bootloader Design

2.1 original bootloader Function

The original bootloader has the following functions:

① The serial download function downloads the kernel to the specified Ram zone through the serial port;
② Flash burning and writing function, burning data from the ram area to flash;
③ Block migration function in the Data zone;
④ Other functions. The command 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 burning 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"
}

Among them, Flash is its command word; dowritetoflashblocks is its method name; flash
{Loader/kernel/root} {block1/.../block16} and FLASH [DEST] [SRC]
[Len] Is the format used for its command ("{}" is optional, and "[]" is required ).

2.2 bootloader improvement Experiment

This improvement is based on the original Bootloader and added instructions for reading data from the SD card of the Mobile storage media in the fat format. The command is encapsulated as follows:
Pai_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"
}
The function is to extract the kernel files in the specified directory to the SDRAM area in the SD card to load the kernel.

Add three additional auxiliary commands, one for formatting the SD card, the other for saving the system kernel, and the last for loading the system kernel. The command is encapsulated as follows:
Performance_tbl_sd_format {
"Formatsd", doformatsdcard,
"Formatsdformat SD card with fat/N ",
"Formatsdformat SD card with fat/N ",
"Formatsdformat SD card with fat/N"
}
Performance_tbl_sd_store {
"Sdstore", dostoretosdblocks,
"Sdstore/[ADDR] {kernel/rootfs}/N"
"Store 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"
}
Performance_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"
}

The function of pai_tbl_sd_format is to format the SD card. The function of pai_tbl_sd_store is to set the kernel
Code is backed up to the fixed storage area of the SD card. The kernel code in the fixed storage area of the SD card is loaded into the specified SDRAM area.

Next we will analyze 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 consists of four major groups.
Into: MBR (primary Boot Record area), DBR (DOS Boot Record area), fat (File Allocation Table area, fat1 for primary File Allocation Table area, fat2 for backup file allocation table area) and
Data zone (Data zone, including FDT zone-file directory and table zone ). The structure of the FAT file system is as follows:

The base slice address of each region (the base slice address of the MBR zone is regarded as 0) is calculated as follows:

Base sector address of DBR area = MBR base sector address + 63
Base sector address of the fat table = base sector address of DBR + number of reserved sectors
FDT base sector address = number of sectors per fat table × Number of fat tables + (Starting cluster number 2 in FDT) × number of sectors per cluster + address of base sector in fat table. (A cluster is the unit in which the system manages files. Each item in the fat table corresponds to a cluster. The file is accessed by cluster. A cluster contains several sectors .)

From the organization structure of the FAT file system, it can be seen that it is easier to read the system kernel code data from the SD card to the specified Ram zone, that is, to find the data in the file system according to the system kernel file name.
Locate and then complete reading. For kernel code backup and loading, SD card formatting must be performed on the basis of in-depth analysis of the structure of the FAT file system. During formatting, set MBR
The data in the partition and DBR areas is not the last 8 in the SD card storage area.
MB area (can be increased or decreased according to actual needs) for formatting, that is, it is set to raw area. Therefore, the implementation of system kernel backup is to fill the system kernel code with the SD card write instructions to raw
. The system kernel is loaded to directly read the backup kernel code from the raw area.

3. Conclusion

The kernel loading boot guide method described in this article has been verified in practice. It completely disconnects the hardware line between the target board and the host machine, facilitating system debugging and effectively improving the system.
Debugging efficiency; at the same time, it can also easily implement online system updates. It can be said that the system boot guide design is required. This method is a good choice. Last, this article introduces
The Improvement Method of bootloader is completed on the lcp2294 chip-developed lpc22eb06i experimental platform. Because of the architecture and specific embed of Bootloader and processor
The configurations of the incoming board-level devices are closely related. To use the preceding Method on other processor chips or platforms, you also need to modify the Code related to the processor architecture in bootloader. This part
This is not the main content of this article, so I will not detail it here. If you want to learn more about it, please refer to the relevant papers or books.