Course contentsShow
← Embedded Systems & Computer Architecture
Lesson 776 of 93611. Introduction to Embedded LinuxFree lesson

Managing Kernel Image Loading and Execution

Learn how the bootloader locates, verifies, and executes the compressed kernel image within the system's volatile memory space.

In this lesson, you will learn how the bootloader orchestrates the transfer of a compressed kernel image from non-volatile storage into volatile system memory and prepares it for execution.

Once the bootloader has navigated the initial multi-stage sequence and identified the storage device, its primary task is to transition the kernel from a passive blob to an active, executing system. This process is rarely as simple as copying bytes; it involves a sophisticated dance between memory allocation, decompression, and architecture-specific handoffs.

Locating and Verifying

The bootloader (such as U-Boot) first reads the kernel image (often a zImage or uImage) from storage (eMMC, NAND, or SPI flash) into a designated region of RAM. Before executing, the bootloader often performs a verification step—calculating a checksum or validating a cryptographic signature—to ensure the image is intact. This is critical, as a corrupted image would lead to a silent, unrecoverable system crash during the decompression phase.

Decompression and Execution

Because kernel images are compressed to save storage space and reduce load time, the bootloader must either decompress the image into a higher memory address or, more commonly, trigger a small "decompressor stub" embedded at the start of the kernel image. The bootloader jumps to this stub, passing the necessary parameters via registers, including the address of the Device Tree Blob (DTB).

A simplified conceptual view of the handoff in assembly might look like this:

; Bootloader setting registers for the kernel
ldr r0, =0          ; Machine ID (deprecated in favor of DTB)
ldr r1, =0x20000000 ; Address of the Device Tree Blob (DTB)
ldr r2, =kernel_start ; Address where the kernel was decompressed
bx r2               ; Jump to the kernel entry point

Once bx r2 is executed, the bootloader cedes control. The kernel’s startup code takes over, finishes initializing the CPU registers, sets up the page tables, and begins the transition from the boot environment to the full Linux Kernel Abstraction Layer.

Key Takeaway: The bootloader acts as a bridge, copying a compressed kernel into RAM, verifying its integrity, and passing the machine's hardware description (DTB) to the kernel entry point to initiate system execution.