Bootloader for an Embedded Linux System

Introduction: What is boot-loader?

The bootloader is a piece of code which is responsible for basic hardware initialization (cpu,ram,gpio etc), loading of an application binary, usually an operating system kernel, from flash storage, from the network, or from another type of non-volatile storage. It also helps in execution of application binary.
Besides these basic functions, most bootloaders provide a shell with various commands implementing different operations like loading of data from storage or network, memory inspection, hardware diagnostics and testing, firmware upgrade and fail-safe functions.

Bootloaders on x86 System

The x86 processors are typically bundled on a board with a non-volatile memory containing a program, the BIOS. This program gets executed by the CPU after reset, and is responsible for basic hardware initialization and loading of a small piece of code from non-volatile storage. This piece of code is usually the first 512 bytes of a storage device. This piece of code is usually a 1st stage bootloader, which will load the full bootloader itself. The bootloader can then offer all its features. It typically understands filesystem formats so that the kernel can be loaded directly from a normal filesystem.

GRUB, Grand Unified Bootloader, the most powerful bootloader. It Can read many filesystem formats to load the kernel image and the configuration, provides a powerful shell with various commands, can load kernel images over the network, etc.
For more info visit

Booting on Embedded CPUs

Case 1:
When the system is powered ON, the CPU starts executing code at a fixed address. There is no other booting mechanism provided by the CPU and the hardware design must ensure that a NOR flash chip is wired so that it is accessible at the address at which the CPU starts executing instructions. The first stage bootloader must be programmed at this address in the NOR flash memory. NOR is mandatory, because it allows random access, which NAND doesn’t allow. This kind of booting is not very common anymore (unpractical, and requires NOR flash).
Case 2:
The CPU has an integrated boot code in ROM, BootROM on AT91 CPUs and ROM code on OMAP, etc. The exact details are CPU-dependent and the boot code is able to load a first stage bootloader from a storage device (MMC, NAND, SPI flash, UART, etc) into an internal SRAM (DRAM not initialized Yet). The first stage bootloader is limited in size due to hardware constraints (SRAM size). The first stage bootloader must initialize DRAM and other hardware devices and load a second stage bootloader into RAM.

Why are there Boot Stages?

At Power-ON-Reset, POR the internal ROM code in the processor knows nothing about the system it is in. Therefore the processor uses predefined methods on where to find the boot code that can be accessed with a minimal standard configuration of external interfaces. The internal RAM is limited in size and due to that only a portion of the boot process can be read into it. Subsequent stages are enabled from this partial boot from Internal RAM. Biggest reason why is due to system configurations that can only be defined during the application design process such as memory DDR types and settings.

Generic bootloaders for embedded CPUs

We will focus on the generic part, the main bootloader, offering the most important features. There are several open-source generic bootloaders. Here are the most popular ones:
1. U-Boot, the universal bootloader by Denx. The most used on ARM, also used on PPC, MIPS, x86, m68k, NIOS, etc. The de-facto standard nowadays.
Visit the link for more info
2. Barebox, a new architecture-neutral bootloader, written as a successor of U-Boot. Better design, better code, active development, but doesn’t yet have as much hardware support as U-Boot.
Visit the link for more info
3. There are also a lot of other open-source or proprietary bootloaders, often architecture-specific RedBoot, Yaboot, PMON, etc.

Components of the ARM Linux Boot Process (4 Stages)

1. RBL – ROM Boot Loader, contained in the ROM, minimal capability to initialize the processor and read the SPL from off chip into internal RAM.
2. SPL – Secondary Program Loader, is code of a minimal configuration specific to the target board that has the capability to setup the processor to be able to read in the next stage which is U-Boot.
3. U-boot – Enables most of the specific processor functionality for the target board and end application to configure the board for booting Linux and to load the kernel image from persistent storage.
4. Kernal image – Final stage of the boot process. Kernel initialization, MMU enable, Device Initilization, User Init process and finally user level applications.

Booting on ARM TI OMAP3

ROM Code: tries to find a valid bootstrap image from various storage sources, and load it into SRAM or RAM (RAM can be initialized by ROM code through a configuration header). Size limited to 64 KB. No user interaction possible.
X-Loader or U-Boot: runs from SRAM. Initializes the DRAM, the NAND or MMC controller, and loads the secondary bootloader into RAM and starts it. No user interaction possible.
U-Boot: runs from RAM. Initializes some other hardware devices (network, USB, etc.). Loads the kernel image from storage or network to RAM and starts it. Shell with commands provided.
Linux Kernel: runs from RAM. Takes over the system completely (bootloaders no longer exists).

This entry was posted in Technical and tagged , , . Bookmark the permalink.

One Response to Bootloader for an Embedded Linux System

  1. ramesh says:

    i need i2c client (rtc client driver ) driver document requirement please send document.
    and also i looking for emmbedded linux job in derabad and bangloor locations.if you have any vacancies please suggest me.

Leave a Reply

Your email address will not be published. Required fields are marked *