Bootloader启动流程

• 学习Bootloader.

1.Bootloader

  Microprocessors can execute only code that exists in memory (either ROM or RAM), while operating systems normally reside in large-capacity devices such as hard disks, CD-ROMs, USB disks, network servers, and other permanent storage media.

  When the processor is powered on, the memory doesn’t hold an operating system, so special software is needed to bring the OS into memory from the media on which it resides. This software is normally a small piece of code called the boot loader. On a desktop PC, the boot loader resides on the master boot record (MBR) of the hard drive and is executed after the PC’s basic input output system (BIOS) performs system initialization tasks.

1.1.What does a bootloader do

  In an embedded Linux system, the bootloader has two main jobs: basic system initialization and the loading of the kernel. In fact, the frst job is somewhat subsidiary to the second in that it is only necessary to get as much of the system working as is needed to load the kernel.

  When the frst lines of bootloader code are executed, following power-on or a reset,the system is in a very minimal state. The DRAM controller will not have been set up so main memory is not accessible, likewise other interfaces will not have been confgured so storage accessed via NAND flash controllers, MMC controllers, and
so on, are also not usable. Typically, the only resources operational at the beginning
are a single CPU core and some on-chip static memory. As a result, system bootstrap
consists of several phases of code, each bringing more of the system into operation.

  At a minimum, a boot loader for an embedded system performs these functions:

• Initializing the hardware, especially the memory controller
• Providing boot parameters for the OS
• Starting the OS

  Most boot loaders provide features that simplify developing and updating firmware; for example:

• Reading and writing arbitrary memory locations
• Uploading new binary images to the board’s RAM from mass storage devices
• Copying binary images from RAM into flash

1.2.Choosing a bootloader

2.U-Boot

  U-Boot is an open-source, cross-platform boot loader that provides out-of-box support for hundreds of embedded boards and many CPUs, including PowerPC, ARM, XScale, MIPS, Coldfire, NIOS, Microblaze, and x86.

3.The boot sequence

3.1.Phase 1 – ROM code

  In the absence of reliable external memory, the code that runs immediately after a reset or power-on has to be stored on-chip in the SoC; this is known as ROM code. It is programmed into the chip when it is manufactured, hence ROM code is proprietary and cannot be replaced by an open source equivalent.

  The only RAM that the ROM code has access to is the small amount of static RAM (SRAM) found in most SoC designs. The size of the SRAM varies from as little as 4 KiB up to a few hundred KiB.

  The ROM code function includes:

• Loading a small chunk of code from one of several preprogrammed locations into the SRAM.

  In SoCs where the SRAM is not large enough to load a full bootloader like U-Boot, there has to be an intermediate loader called the secondary program loader, or SPL.

  At the end of the second phase, the third stage loader is present in DRAM, and the SPL can make a jump to that area.

3.2.Phase 2 – SPL

  SPL (Secondary Program Loader) is a small binary, generated from U-Boot source, that fits in the SRAM and loads the main U-Boot into system RAM.

  The SPL functions includes：

• set up the memory controller
• loading the third stage program loader (TPL) into main memory(DRAM)

  The functionality of the SPL is limited by its size. It can read a program from a list of storage devices, as can the ROM code, once again using preprogrammed offsets from the start of a flash device, or a well known fle name such as u-boot.bin. The following diagram explains the phase 2 architecture:

3.3.Phase 3: TPL

   we are running a full bootloader like U-Boot. Usually, there is a simple command-line user interface that will let you perform maintenance tasks such as loading new boot and kernel images into flash storage, loading and booting a kernel, and there is a way to load the kernel automatically without user intervention.

The following diagram explains the phase 3 architecture:
  At the end of the third phase, there is a kernel in memory, waiting to be started. Embedded bootloaders usually disappear from memory once the kernel is running and perform no further part in the operation of the system.

4.The boot process
  After power-up or reset, the processor loads the U-Boot boot loader in several steps.

  The processor does these steps:

• Executes a primary bootstrap that configures the interrupt and exception vectors, clocks, and SDRAM
• Decompresses the U-Boot code from flash to RAM
• Passes execution control to the U-Boot

  U-Boot does these steps:

• Configures the Ethernet MAC address, flash, and, serial console
• Loads the settings stored as environment variables in non-volatile memory
• After a few seconds (a length of time you can program), automatically boots the preinstalled kernel

5.Moving from bootloader to kernel

  When the bootloader passes control to the kernel it has to pass some basic information to the kernel, which may include:

• A number unique to the type of the SoC
• Basic details of the hardware detected including at least the size and
  location of the physical RAM, and the CPU clock speed
• The kernel command line
• Optionally, the location and size of a device tree binary
• Optionally, the location and size of an initial RAM disk

How to move the information form the bootloader to the kernel?

  The way this information is passed includes:

• PowerPC, the bootloader simply used to pass a pointer to a board information structure, whereas, with ARM, it passed a pointer to a list of “A tags”.
  Note:In both cases, the amount of information passed was very limited, leaving the bulk of it to be discovered at runtime or hard-coded into the kernel as “platform data”.
• A better way was needed, the device tree.

6.小结：