Control Flow in U-boot (Bootloader)

Bootloader Description
Bootloader for embedded development is bound to touch a concept, it is embedded College two courses in the embedded linux system in the development of important content. This article mainly explains the basic concepts and CY7C1329-100AC datasheet and internal Bootloader principle, this part of the master development will be embedded linux system was extremely helpful!

Bootloader definition: Bootloader is executed before the operating system is running a short program, through this short process, we can initialize the hardware devices, the establishment of a mapping table memory space in order to establish appropriate systems hardware and CY7C1329-100AC price and software environment, called the operating system kernel for the final preparation. Meaning that if we want an operating system up and CY7C1329-100AC suppliers and running on our board, we must first of all on board some of our basic configuration and initialization before it can come in to run the operating system boot. Bootloader specific in what actions to complete the analysis we will be back to where we first recall the architecture of PC: PC, boot loader in the BIOS and the hard disk from MBR in OS Boot Loader (such as LILO and GRUB, etc.) with the composition, BIOS hardware detection and the completion of the allocation of resources, will be hard to read MBR Boot Loader in the system RAM, then transfer control to the OS Boot Loader. Boot Loaders main task is to run the kernel image will be read from the RAM disk, and then jump to kernel entry point to run, which started operating system. In embedded systems, often as not, as the firmware BIOS (Note: some embedded embedded cpu will start a short program), so start the task of loading the whole system is completely done by the Boot Loader. For example, in an embedded ARM7TDMI core-based systems, the system is powered on or reset is usually started from the address at 0x00000000, and in this address is usually arranged at the system Boot Loader program. (First think about, general PC and embedded system why there is such a difference here then?)

Bootloader is based on the specific hardware platform to achieve, therefore virtually impossible for all of the embedded system the establishment of a common Bootloader, different processor architectures have different Bootloader, Bootloader not only dependent on the cpu architecture, but also on board-level embedded system device configuration. For two different board, even if they use the same processor, to get on the board running in a Bootloader program can be run on another piece of board, generally need to modify the source code Bootloader.

Bootloader boot methods

Bootloader boot methods are network boot mode Flash boot disk boot mode and manner.

1, the network boot method





Figure 1 Bootloader Network Starting method diagram

shown in Figure 1, which the host and target board, among them over a network connection, the first target of the DHCP / BIOS Bootloader through the BOOTP service to assign IP addresses, configure the network parameters, in order to support the network transmission function. We use the u-boot can set network parameters, so there would not have a way to use DHCP dynamic allocation of IP was. Bootloader next target board kernel image via TFTP service to download to the target board and then through the network file system to create the host and target communication process between the documents, after the system update usually use this mode of Boot Loader . Work in this mode of Boot Loader to its end users usually provide a simple command line interface.

2, disk boot method

this approach is mainly used in desktop computers and servers, these computers are using the BIOS boot, and use the disk as a storage medium, there is Two important are used to start the linux LILO and GRUB, not specifically described here.

3, flash boot mode

This is the most common way. Flash NOR Flash and NAND Flash has two. NOR Flash can support random access, so the code can run directly in Flash, Bootloader is generally stored in the Flash chip. Flash also has stores on the parameters, the kernel image and file system. This starts with the network boot mode difference between the way is that, in the network boot mode, kernel image and file system on the host first, and then transmitted through the network to download into the target board, which started in the way the kernel image and file system is placed directly in Flash, these two points we use u-boot is used a process.

U-boot definition

U-boot, full name of the Universal Boot Loader, the development team by DENX terms of compliance with GPL open source project, its main function is to complete the hardware device initialization, the operating system code handling, and provide a console and a set of instructions before running the operating system control hardware devices. The reason why such a universal U-boot, because he has a lot of features: open source, support for multiple embedded operating system kernel, supports multiple processors, high stability, a highly flexible feature set, rich devices driver source code and more extensive development and debug documents and a strong network of technical support. Also u-boot operating system and product development provides a rich and flexible support, mainly in: you can boot the kernel compressed or uncompressed, can be flexibly set / pass multiple key parameters to the operating system, for systems in different stages of development commissioning requirements and product releases, support for multiple file system, support for multiple target environment parameters storage medium, the use of CRC32 verification, you can check the kernel and the image file is intact, offers a variety of console interface, so users can not the case of ICE through the serial port / Ethernet / USB interface to download data such as storage devices and burn to go (this feature in the actual product is very useful, especially in the software field upgrades of the time), and provide a rich The device drivers and so on.

u-boot source code directory structure

1, board development board stored in the configuration files related to each development board are in the form of sub-folders.

2, Commom folder implementation to support u-boot command line, each command corresponds to a file.

3, cpu stored in the relevant directory structure of a specific cpu, cpu structure of each section corresponds to a subdirectory.

4, Doc is a document directory, there u-boot is very well documented.

5, Drivers is u-boot support for a variety of device drivers.

6, Fs is a supported file system, the most commonly used is the JFFS2 file system.

7, Include folder is the u-boot using the header files, and various hardware platforms to support the compilation of files, system configuration files and file system support files.

8, Net is the code associated with the network protocol, bootp protocol, TFTP protocol, NFS file system was achieved.

9, Tooles is to generate a U-boot tool.

on the u-boot directory has some understanding, the process of boot code to be much more convenient, the more important directory is / board, / cpu, / drivers, and / include directories, if you want to to achieve u-boot on a platform migration, it is necessary depth of analysis of these directories.

u-boot startup process

system startup entry point. Since we now have to analyze the process of u-boot startup, you must first find the u-boot, which code the first realization, the first completed what tasks. On the other hand an executable image must have an entry point, and only a global entry point, so to inform the compiler where the entrance. From this we can find the entry point is in / board/lpc2210/u-boot.lds specified, which ENTRY (_start) _start start running from that program, and he points to the cpu/arm7tdmi/start.o file. Because we are using the cpu ARM7TDMI architecture, from the address 0x00000000 after reset to take its first instruction, so we will Flash map to this address, so that the system is powered up, cpu will be the first implementation of u-boot process.

u-boot startup process is multi-stage implementation, divided in two stages. Architecture depends on the cpu code (such as device initialization code, etc.) are usually placed in stage1, but also usually implemented in assembly language in order to achieve the purpose of short and pithy. The stage2 is usually implemented with C language, so that complex functions can be achieved, and the code has better readability and portability.

following detailed analysis of our first under the stage1 code shown in Figure 2:





Figure 2 Start.s program flow

code really started in _start, set the exception vector table, so that when an exception occurs in the cpu to jump to / cpu/arm7tdmi / interrupts in the code to execute the appropriate service routine. Most of the document in the interrupts are not implemented exception code specific functions, but only print some exception message, which is the key to reset the interrupt code, skip to the reset entry address.

reset reset before the entrance of some segments of the statement. In the reset, the first is the cpu is set to svc32 mode, and block all irq and fiq. In addition to the u-boot using the timer interrupt, the other is basically no need to use interrupts, such as serial communications and network communications, as long as the u-boot to complete some simple communication can be, so here mask out all interrupts.

initialize the external bus. This part of the first set of I / O port features, including serial, network interface settings, and other I / O port is set to GPIO. Then set BCFG0 ~ BCFG3, the external bus controller. Here bank0 corresponding Flash, set to 16-bit width, the slowest bus speed is set to achieve stable operation; Bank1 corresponding DRAM, the same settings and Flash; Bank2 corresponding RTL8019.

Next is the key to set the cpu, including system re-mapping (to tell the processor when the interrupt occurs in the system to the external memory to read the interrupt vector table) and the system frequency.

lowlevel_init, set the RAM timing, and interrupt controller cleared. The relevant part of the platform-specific, but generally the process is the same.

Here is the code of the move phase. In order to obtain faster execution, usually stage2 is loaded into RAM space to run, it is necessary to load the stage2 ready for Boot Loader section of the scope of available RAM space. Space is best memory page size (usually 4KB) multiple of, in general, 1M of RAM space is enough. stored in flash u-boot executable file, the code segment, data segment, and BSS segments are stored end to end, so when calculating the size of the move is to use the first address with the BSS segment minus the first address code, This is actually calculated using the space. Program uses a loop to move the code 0x81180000, that is the bottom 1M RAM space used to store code. And the program continues to move to RAM interrupt vector table top. Stage2 is usually the C language implementation of the code, therefore I have to build the stack. Even before the stack area allocated to malloc space and the space required for global data space down, and their size is given by the macro definition can be modified in the appropriate location. Basic memory map:




Figure 3, the distribution of moving, memory map

Next is the u-boot start of the second phase, is written in c code, which is of relatively little change in some part of the board that we change it for different number of initialization function call, and by setting Some macro to change the initialization process, so the code in the process of transplantation does not need to modify is the file the error appears relatively small. In the beginning of the file first defines a function pointer array, the array, the program through a loop initialization routine in order, and thereafter through a number of macros to initialize a specific device. In the final program enters a loop, main_loop. This loop receives user input commands to set the parameters or the boot.

of this article will focus on the front of the start.s on, because this part of both the transplant or in the debugging process is the most error-prone places on the need for procedures to solve the problem staff to modify the code, so heres a brief introduction about the basic process start.s, hoping to help.