Brief introduction of Bootloader Uboot

From http://blog.ednchina.com/hhuwxf/1915416/message.aspx, thanks to the author

First, the introduction of bootloader

From the previous hardware experiment you can know that after the system is powered up, a program is required to initialize: off
WATCHDOG, changing the system clock, initializing the storage controller, copying more code into memory, and so on. If it can put the operating system kernel (whether from the local, such as Flash, or from the remote,
such as through the network copy into the memory to run, it is called this program is bootloader.

Simply put, Bootloader is a small program that starts executing when the system is power-up, initializes the hardware device, prepares the software environment, and finally calls the operating system kernel.

can enhance the function of bootloader, such as adding network function, downloading files from PC via serial port or network,
Burning files, extracting compressed files from flash, and running them--this is a more powerful bootloader, also known as Monitor. In fact, in the end product, the user
These features are not needed, they are just for easy development.

The implementation of Bootloader relies heavily on specific hardware, and in embedded systems the hardware configuration varies widely, even
The same CPU, its peripherals (such as flash) may also be different, so it is impossible to have a bootloader support all CPUs, all the boards. Even if the CPU architecture is more supported
U-boot, and it is not available for use (unless the configuration is exactly the same as your board), some porting is required.

Second, the starting mode of bootloader

When the CPU is power-up, it executes from an address. For example, the CPU of MIPS structure will be taken from 0xbfc00000
The first instruction, and the CPU of the arm structure begins with the address 0x0000000. In the embedded veneer, you need to map the memory ROM or flash to this place
Location, the bootloader is stored at the beginning of this address so that a power-up can be performed.

At development time, it is often necessary to use various commands to operate the bootloader, usually via the serial port to connect the PC and develop
Board, you can enter various commands on the serial port, observe the running results, and so on. This is only for developers to make sense, users use the product is not connected to the serial port to control the bootloader. From this point of view.
See, bootloader can be divided into two modes of operation (operation mode):

(1) Boot load (boot loading) mode.

When power is on, bootloader loads the operating system into RAM from a solid-state storage device on the board, and the process does not involve the user. When the product is released, bootloader works in this mode.

(2) Download (downloading) mode.

In this mode, developers can use a variety of commands to download files (such as kernel images, file system images) from hosts (host) through communication means such as serial connections or network connections, either directly in memory or burning into flash-class solid state storage devices.

Between the board and the host transfer files, you can use the serial port of the Xmodem/ymodem/zmodem protocol, they use simple, but the speed is relatively slow, you can also use the network through TFTP, NFS protocol to transmit, at this time, the host to open TFTP, NFS service; There are other ways such as USB.

Powerful bootloader such as blobs or u-boot often support both working modes
and allows the user to switch between the two modes of operation. For example, U-boot is in normal boot load mode at startup, but it will delay for several seconds (this can be set) waiting for the end user to press
Any key and switch u-boot to download mode. If there are no user keystrokes within the specified time, U-boot continues to boot the Linux kernel. Edit] 15.1.2 bootloader structure and start-up process 1. Overview

Understanding some of the general concepts of bootloader before porting is helpful for understanding its code.

In an embedded Linux system, from the software perspective can usually be divided into 4 levels:

(1) boot loader, including the boot code (optional) and bootloader, which are cured in firmware (firmware).

Some CPUs run a cured program (firmware, firmware) before running bootloader, such as the CPU of the x86 structure that runs the firmware in the BIOS before running the bootloader in the first partition (MBR) of the hard disk.

In most embedded systems there is no firmware, and Bootloader is the first program to be executed after power-up.

(2) Linux kernel.

Custom kernel and kernel startup parameters specific to the embedded board. The kernel's startup parameters can be either kernel-default or passed to it by bootloader.

(3) file system.

Includes the root file system and the file system built on top of the flash memory device. It contains the necessary applications, libraries, etc. that the Linux system can run, such as the shell program that gives the user the control interface to operate Linux, the GLIBC or UCLIBC library that the dynamically connected program runs, and so on.

(4) User application program.

User-specific applications, which are also stored in the file system. Sometimes an embedded graphical user interface may also be included between the user application and the kernel layer. Commonly used embedded GUI are: Qtopia and MiniGUI and so on.

Obviously, there are partitions on the solid-state storage devices embedded in the system to store them, and figure 15.1 is a typical partitioning structure. [[Image:]]

Figure 15.1 Typical partition structure in an embedded Linux system

The Boot
Parameters "Partition contains some parameters that can be set, such as IP address, serial port baud rate, command line parameters to be passed to the kernel, and so on. During normal startup, the bootloader first
Run, then it copies the kernel into memory (and some cores can run directly on the solid state storage device), and at a fixed address in memory set the parameters to pass to the kernel, and finally run the kernel. Kernel boot
It mounts (mount) the root filesystem ("root filesystem") and launches the application in the file system. 2. Two stages of bootloader

The START process of the bootloader startup process can be divided into single-stage
stage), multi-phase (multi-stage) two kinds. Often multi-stage bootloader can provide more complex functionality and better portability. Boot from the solid state storage device
Most of the bootloader are 2-stage start-up processes. This is well understood from the previous hardware experiment: the first stage is implemented using a compilation, which accomplishes some CPU-dependent
Initializes the architecture and invokes the second-stage code. The second phase is usually implemented in C, which allows for more complex functionality and makes the code more readable and portable.

In general, the functions completed in these two phases can be categorized as follows, but this is not absolute:

(1) bootloader function of the first stage. Initialization of hardware devices. Prepare the RAM space for the second-stage code that loads bootloader. Copy Bootloader's second-stage code into RAM space. Set up the stack. Jump to the C entry point of the second-stage code.

Hardware initialization in the first phase typically includes: Turn off watchdog, shut down interrupts, set CPU speed and clock frequency, ram initialization, and so on. These are not all necessary, such as the u-boot used in S3C2410/S3C2440 's development board, which puts the CPU's speed and clock frequency settings in the second phase.

Even copying the second-stage code into RAM space is not required, and for storage devices such as nor flash, it is entirely possible to execute code directly above it, except that it is significantly less efficient than in RAM.

(2) Bootloader function of the second stage. Initializes the hardware device to be used at this stage. Detects the system memory map. Read the kernel image and root file system image from Flash to ram space. Set the startup parameters for the kernel. Call the kernel.

For ease of development, at least one serial port should be initialized for programmers to interact with bootloader.

The so-called detection of memory mapping is to determine how much memory is used on the board, and what their address space is. Because of the embedded development, bootloader is for some kind of board to write, so it can be set directly according to the situation of the Board, do not need to consider the complex algorithms that can be applied to various situations.

The kernel image on Flash may be compressed, and it needs to be decompressed after reading RAM. Of course, for a kernel with self-extracting function, bootloader is not required to decompress.

It is not required to copy the root file system image into RAM. This depends on what type of root file system it is, and how the kernel accesses it.

Setting the startup parameters for the kernel is described in the next section.

After storing the kernel in the appropriate location, jump directly to its entry point to invoke the kernel. Before invoking the kernel, the following conditions are met:

(1) The setting of the CPU register. R0=0 r1= machine type ID; for ARM-structured CPUs, the machine type ID can be found in linux/arch/arm/tools/mach-types. r2= Start parameter marker list in RAM start base address

(2) CPU operating mode. Interrupts must be disabled (IRQs and Fiqs) The CPU must be in SVC mode

(3) Cache and MMU settings. MMU must close the instruction cache can be opened or the data cache must be closed

If you use C, you can call the kernel like the following sample code:

void (*thekernel) (int zero, int arch, u32
PARAMS_ADDR) = (void (*) (int, int, u32)) Kernel_ram_base; ......
Thekernel (0, Arch_number, (u32) kernel_params_start); 3. Bootloader interaction with the kernel

Bootloader interaction with the kernel is unidirectional, and bootloader passes all kinds of parameters to the kernel. Since they cannot be run at the same time, there is only one way to pass: bootloader the parameters after a certain convention, and then starts the kernel, which gets the parameters from this place after the kernel is booted.

In addition to the agreed parameters to store the address, but also to specify the structure of the parameters. Linux 2.4.x
Future kernels are expected to have a list of tokens (tagged
list) to pass the startup parameters. A tag is a data structure; a tag list is a number of tags that are stored next to each other. Tag list to mark Atag_core
Start with the Mark Atag_none
End. The data structure of the tag is tag, which consists of a tag_header structure and a Union (union). The Tag_header structure represents the type and length of the tag, as
Represents memory or command line arguments, and so on. Use a different union (union) for different types of tags, such as using tag_mem32 when representing memory, to represent command lines using
Tag_cmdline. The data structure tag and tag_header are defined in the Include/asm/setup.h header file of the Linux kernel source code:?

1 2 3 4 5 6 7 8

struct Tag_header {u32 size; u32 tag;};