PREV_LEC | NEXT_LEC

What You Will Learn

Prerequisites

What Does the TPL Actually Do?

By the time control reaches the TPL, the processor has already run its boot ROM code and a small first-stage loader has brought up enough SDRAM to be useful. The TPL is the first piece of software in the whole boot chain that behaves like a “real” program — it has a command-line shell, drivers for storage devices, network support, and enough intelligence to make decisions about what to boot and how.

In most embedded Linux designs, the TPL is U-Boot or Barebox. Its one real job is simple to state even though the mechanics are not: get a kernel image, an optional device tree blob, and an optional initial RAM disk into memory at the right addresses, then jump to the kernel’s entry point. After that jump, the bootloader’s memory is typically overwritten or ignored — it does not participate in normal Linux operation.

Notice the arrow of control here is one-directional. The boot ROM starts the SPL, the SPL starts the TPL, and the TPL starts the kernel — each stage trusts the layer above it just enough to hand off memory addresses and then gets out of the way. This layered handoff is exactly why embedded engineers taking a free linux kernel development course need to understand bootloaders before they ever touch a device driver: a kernel that never gets a correct memory address for its device tree will not boot, no matter how correct the driver code is.

The TPL’s Command-Line Shell

Unlike the SPL, the TPL usually exposes an interactive shell over a serial console. This is where most embedded developers spend their early bring-up time. Typical tasks performed from this shell include:

Most production boards also configure an autoboot countdown, so the same commands run automatically without a human at the console — the interactive shell exists mainly for development, recovery, and field debugging.

Booting With UEFI Firmware

Most x86 embedded PCs, and a growing number of ARM designs, don’t use a vendor-specific SoC boot ROM at all — they use UEFI firmware instead. The three-phase idea from earlier in this free embedded linux course still applies, but the concrete mechanics change:

The ESP is worth calling out specifically because it trips up a lot of people new to embedded Linux development: it must be formatted as FAT32, and it’s identified by a fixed, standardized partition type GUID rather than by any vendor-specific convention. The bootloader binary itself lives at a predictable path inside that partition, named after the target machine architecture — for example, an x86_64 build’s loader binary sits under a fixed EFI boot directory using a machine-specific filename.

The two most common Linux-side UEFI boot loaders are GRUB2, which is extremely widely used but ships under a GPL variant with some secure-boot licensing friction, and lighter systemd-integrated boot managers, which trade some flexibility for simplicity. Functionally both do the same job as U-Boot’s booti command: locate a kernel image and optional initramfs, then jump to it.

Hands-On: A Minimal TPL Boot Script on QEMU

Rather than reproducing the book’s board-specific example, let’s build our own tiny, original boot script and test it entirely inside QEMU — no physical hardware required. This mirrors exactly what a free linux kernel development course exercise should feel like: reproducible, and safe to break.

# 1. Build a minimal ARM kernel and a matching virt device tree
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- vexpress_defconfig
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j$(nproc) zImage dtbs

# 2. Build U-Boot for the QEMU ARM "virt" target
make qemu_arm_defconfig
make -j$(nproc)

# 3. Boot U-Boot on QEMU and drop into its shell
qemu-system-arm -M virt -m 512M -nographic \
  -bios u-boot.bin \
  -kernel /dev/null

# 4. From the U-Boot shell (interactive), run our own boot script
setenv ep_kernel_addr 0x42000000
setenv ep_fdt_addr    0x43000000
setenv bootargs "console=ttyAMA0 earlycon root=/dev/vda rw"
tftpboot ${ep_kernel_addr} zImage
tftpboot ${ep_fdt_addr} vexpress-v2p-ca9.dtb
bootz ${ep_kernel_addr} - ${ep_fdt_addr}

Expected console output once the jump succeeds:

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 6.x.x (ep-course-build)
[    0.000000] CPU: ARMv7 Processor [410fc090] revision 0
[    0.000000] Machine model: ARM Versatile Express
[    0.100000] Kernel command line: console=ttyAMA0 earlycon root=/dev/vda rw

The important thing to notice is the sequencing: nothing in this script assumes the kernel or DTB is baked into the image — both are loaded to explicit addresses by name, exactly the same pattern the memory diagram above describes, just driven from TFTP instead of an SD card for convenience under QEMU.

Common Mistakes and Troubleshooting

Best Practices

Summary and Key Takeaways

Conclusion

Once the TPL hands off to the kernel, our next lecture in this free linux kernel development course looks at exactly what information crosses that boundary — the kernel command line, the device tree pointer, and the initial RAM disk — and why the device tree replaced older, more fragile ways of describing hardware to Linux.

FAQ

PREV_LEC | NEXT_LEC