What is bootloader?

Running GNU/Linux systems on dedicated embedded boards has become increasingly popular. An embedded Linux system can be divided into four levels from the software perspective:

1. Boot LoadingProgram. Includes the firmware (firmware) bootCode(Optional), and bootloader.

2. Linux kernel. Customized kernel and kernel startup parameters specific to embedded boards.

3. file system. Including the root file system and the file system built on the flash memory device. Ramdisk is usually used as rootfs.

4. user applications. User-specific applications. Sometimes an embedded graphical user interface may be included between the user application and the kernel layer. Common embedded guis are Microwindows and MiniGUI.

The pilot loader is the first piece of software code that runs after the system is powered on. The boot loader in a PC is composed of BIOS (which is essentially a firmware program) and OS bootloader (such as Lilo and grub) in the hard disk MBR. After completing hardware detection and resource allocation, the BIOS reads the bootloader in the hard disk MBR to the system ram, and then gives the control to the OS bootloader. The main task of bootloader is to read the kernel image from the hard disk to ram, and then jump to the kernel entry point to run, that is, start the operating system.

In embedded systems, there are usually no firmware programs like bios (NOTE: Some embedded CPUs also embed short boot programs ), therefore, the boot task of the entire system is completely completed by bootloader. For example, in an embedded system based on ARM7TDMI core, the system usually runs from the address 0x00000000 during power-on or reset, And the bootloader program is usually arranged at this address.

In short, bootloader is a small program that runs before the operating system kernel runs. Through this small program, we can initialize hardware devices and build a map of memory space to bring the system's hardware and software environment to a suitable state, in order to prepare the correct environment for the final call to the operating system kernel.

Generally, bootloader relies heavily on hardware, especially in the embedded world. Therefore, it is almost impossible to build a general bootloader in the embedded world. However, we can still summarize some general concepts of bootloader to guide the user's specific design and implementation of bootloader.

II. Introduction to common bootloader

1. Introduction to U-BOOT

Uboot is a huge open source software. He supports some arm systems, including common peripheral drivers, and is a powerful board support package. The code can be downloaded from http://sourceforge.net/projects/u-boot

U-BOOT is developed by ppcboot, is PowerPC, arm9-, XScale, x86 and other general system boot solution, from the official version of 0.3.2 began to fully support SC series single machine. U-boot is an open source bootloader. The current version is 0.4.0. U-boot is developed on the basis of ppcboot and armboot. Although it is declared as version 0.4.0, it is quite mature and stable and has been used in many embedded system development processes. Because of its DevelopmentSource codeIt supports many development boards. The only pity is that the Development Board Samsung 44b0x is not supported.

Why do we need u-boot? Obviously, uClinux can be directly burned into flash without the need for additional boot loader ). However, from the perspective of software upgrade and program patching, automatic software update is very important. In fact, the purpose of the bootstrap loader is not only that, but it is necessary to develop the software only from the need for automatic updates.

At the same time, the U-Boot porting process is also a process of deep understanding of embedded systems, including hardware and software and operating systems.

2. Vivi introduction (http://www.mizi.com/developer)

Vivi is a bootloader developed by South Korea's mizi company and is suitable for the arm9-processor. Vivi has two working modes: Start loading mode and download mode. You can start the Linux kernel after a period of time (this time can be changed). In this case, the default Vivi mode is used. In the download mode, Vivi provides you with a command line interface, through which you can use some commands provided by Vivi, as follows:

Command

Function

Load

Load binary files into flash or RAM

Part

Operate MTD partition information. Display, add, delete, reset, and save MTD partitions

Param

Set parameters

Boot

Start the system

Flash

Manage flash, such as deleting flash data

Vivi code analysis

Vivi code includes several directories, including Arch, init, Lib, drivers, and include. There are more than 200 files.

Vivi mainly includes the following directories:

Arch: This directory contains subdirectories of all target boards supported by Vivi, such as the S3C2410 directory.

Drivers: contains the driver (MTD and serial port) of the device required to boot the kernel ). The MTD directory contains three directories: map, Nand, and nor.

Init: This directory contains only the main. C and version. c files. Like a common C program, Vivi will be executed from the main function.

Lib: common interface code of some platforms, such as udelay () and mdelay () in time. C ().

Include: the public directory of the header file. The S3C2410. h defines some registers of this processor. Platform/smdk2410.h defines the resource configuration parameters related to the development board. You only need to modify this file to configure the parameters of the Target Board, such as the baud rate, boot parameters, and physical memory ing.