ES: Embedded Linux Bootloader

Before any operating system can run, the hardware must be prepared. The bootloader is the software responsible for that preparation. It is the first code that executes after a power-up or reset, and its job is to bring the hardware to a state where the Linux kernel can take over.

Why a Bootloader is Needed

When the CPU is powered up, it knows nothing about the system — not where the software is, not how to access memory, not where the stack lives.

The processor needs to know:

• Where the software is located
• How to access that location
• Where the stack is located

Power On
   |
   v
CPU Reset
   |
   v
Program Counter = Reset Vector (first instruction address)
   |
   v
Bootloader executes
   |
   v
Hardware initialised, software loaded
   |
   v
Kernel starts

The Reset Vector

When the CPU powers up, the Program Counter (PC) register is set to a fixed address called the Reset Vector.

**Program Counter** — a CPU register that holds the address of the next instruction to execute.

**Reset Vector** — a pointer to the address containing the first instruction executed from firmware.

The software at the reset vector is the bootloader, which takes care of providing the processor with everything it needs to start the operating system.

The operation of the bootloader is system architecture dependent — each SoC vendor defines their own boot ROM and reset vector location.

Bootloader in a Microcontroller

In a microcontroller, all software is stored in persistent storage (Boot Flash) embedded within the chip.

+--------------------------------------+
|         Microcontroller              |
|  +-------+  +-------+               |
|  |  CPU  |  |  I/O  |               |
|  +-------+  +-------+               |
|  +-------+  +------------------+    |
|  |  RAM  |  |   Boot Flash      |    |
|  | (heap/|  | (bootloader +     |    |
|  | stack)|  |  OS + RFS)        |    |
|  +-------+  +------------------+    |
+--------------------------------------+

The CPU reset vector points into the Boot Flash. All software — bootloader, device tree, OS, and root filesystem — is stored there. RAM is used only for runtime data, stack, and heap.

Bootloader in a SoC

A System on Chip (SoC) separates the boot flash from the mass storage.

+--------------------------------------+
|               SoC                    |
|  +-------+  +-------+               |
|  |  CPU  |  |  I/O  |               |
|  +-------+  +-------+               |
|  +-------+  +------------------+    |
|  |  RAM  |  |   Boot Flash      |    |
|  |       |  | (bootloader only) |    |
|  +-------+  +------------------+    |
+--------------------------------------+
         |
         v  loaded at runtime
+------------------+
|  Mass Memory     |
|  (eMMC / SD)     |
|  Device Tree     |
|  OS Kernel       |
|  Root Filesystem |
+------------------+

The bootloader and reset vector live in the Boot Flash, but the rest of the software (device tree, OS, root filesystem) resides in mass memory and is copied to RAM by the bootloader.

The Boot Sequence in Detail

Before Power Up

Both memories are preloaded by the manufacturing or flashing process.

Boot Flash contains:

• CPU reset vector at 0x0000_0000
• First bootloader instruction at 0x0000_0FFF
• Last bootloader instruction at 0x0000_AFFF

Mass Memory contains:

• Device Tree (DT)
• Operating System (OS kernel)
• System Programs (SP)
• Application

During Power Up

The CPU starts executing from the reset vector:

1. Jumps to the first instruction of the bootloader
2. Runs the bootloader software from Boot Flash memory

During the Bootstrap Process

The bootloader software:

1. Initialises the CPU RAM memory controller — configures timing, width, refresh
2. Sets up the CPU registers — maps stack and heap to RAM
3. Copies software to RAM — device tree, OS kernel, system programs, application

Bootstrap Process:
Boot Flash
    |
    | 1. CPU RAM controller init
    v
RAM available
    |
    | 2. Copy DT + Kernel + RFS from Mass Memory
    v
RAM populated
    |
    | 3. Jump to first kernel instruction
    v
Linux Kernel starts

End of Bootstrap Process

The bootloader jumps to the first instruction of the operating system.

The CPU now executes the Linux kernel, which is responsible for:

• Setting up the execution environment for applications
• Mounting the root filesystem
• Starting the init process
• Starting user-space applications

Common Bootloaders for Embedded Linux

U-Boot (Das U-Boot) is the de facto standard for ARM-based embedded Linux systems. It supports a rich command environment, network booting, and loading images from NAND, eMMC, SD card, NFS, and USB.

U-Boot Boot Flow

A typical U-Boot boot sequence on an ARM SoC:

1. SoC Boot ROM executes (factory-programmed)
        |
        v
2. U-Boot SPL (Secondary Program Loader)
   - Minimal first-stage loader
   - Fits in on-chip SRAM
   - Initialises DRAM controller
        |
        v
3. U-Boot proper
   - Full bootloader environment
   - Loads kernel + DTB from storage
   - Passes boot arguments
        |
        v
4. Linux Kernel

Final Thoughts

The bootloader is the foundation of the entire embedded Linux boot sequence. Without a correctly configured bootloader:

• The kernel will never load
• The hardware will never be properly initialised
• The system will never start

Embedded Linux Boot Summary:
Reset Vector
    --> Bootloader (initialise HW, load software)
        --> Linux Kernel (manage resources)
            --> Root Filesystem (system programs)
                --> Application (end-user function)

Understanding the bootloader means understanding what happens in the critical moments between power-up and a running Linux system.