What You Will Learn

Prerequisites

bootm and booti Syntax

The classic 32-bit command is bootm; ARM64 boards typically use booti, which expects
an uncompressed Image rather than a compressed zImage. Both share the same three-address argument pattern:

bootm [kernel_addr] [ramdisk_addr] [fdt_addr]
booti [kernel_addr] [ramdisk_addr] [fdt_addr]

The kernel address is mandatory; the other two are optional depending on your board’s configuration. If there’s a
device tree but no ramdisk, the ramdisk position is replaced with a dash rather than omitted, since argument
position determines meaning:

U-Boot# booti ${ep_kernel_addr} - ${ep_fdt_addr}

What Happens During the Handoff

Running bootm/booti is not a simple jump instruction — U-Boot performs several checks and setup steps first:

1. Validates the image header(s) at each given address, the same check iminfo performs manually.
2. Decompresses the kernel into its runtime location, if compression was used.
3. If a device tree was given, fixes it up with runtime information U-Boot has gathered — things like detected memory size and the kernel command line from bootargs — before Linux ever sees it.
4. Sets up CPU state as the Linux boot protocol for the architecture requires (e.g. disabling the MMU and caches on ARM before entry, in the state Linux expects to find them).
5. Jumps to the kernel’s entry point. From this instant, U-Boot has handed off control entirely — it does not run again until the next power cycle.

Booting With Kernel, Ramdisk, and Device Tree

A complete boot with all three components loaded at separate addresses looks like this:

U-Boot# fatload mmc 0:1 ${ep_kernel_addr} Image
U-Boot# fatload mmc 0:1 ${ep_fdt_addr} board.dtb
U-Boot# fatload mmc 0:1 ${ep_ramdisk_addr} initramfs.cpio.gz
U-Boot# booti ${ep_kernel_addr} ${ep_ramdisk_addr} ${ep_fdt_addr}

Note the argument order: kernel first, ramdisk second, device tree third — swapping ramdisk and fdt addresses is
a common copy-paste mistake that produces a kernel panic very early in boot, since Linux tries to parse the ramdisk
data as a device tree or vice versa.

Booting a FIT Image in One Command

If you built a FIT image (covered in the mkimage lecture) that bundles the kernel, device tree, and ramdisk
together with a named configuration, booting collapses to a single address and an optional configuration selector:

U-Boot# tftp ${ep_fit_addr} ep-demo.itb
U-Boot# bootm ${ep_fit_addr}#conf-1

The #conf-1 suffix selects a specific named configuration from the FIT image, useful when a single
image bundles configurations for more than one board variant or boot mode.

Real-World Use Cases

• Development boards commonly boot kernel + separate dtb + rootfs over NFS via bootargs, skipping a ramdisk entirely.
• Production devices increasingly boot a single signed FIT image, since it keeps the kernel and its matching device tree cryptographically bound together.
• Recovery/rescue boot flows often use a ramdisk-based initramfs so the device can run diagnostics without depending on the (potentially corrupted) main root filesystem.

Common Mistakes and Troubleshooting

Best Practices

• Run iminfo on every loaded component immediately before calling bootm/booti, not just the kernel.
• Keep bootargs, device tree, and kernel version changes tested together — a mismatch between any two is a common source of early boot failures.
• Prefer a single signed FIT image on production hardware over separately-loaded components.
• Log the exact bootm/booti command used for a working configuration in your board’s bring-up notes — it’s easy to forget argument order months later.

Security Considerations

bootm/booti is the exact point where U-Boot’s verified boot chain either enforces or fails to enforce trust —
when booting a signed FIT image with verification enabled, U-Boot refuses to execute a kernel or device tree that
doesn’t match a trusted signature. Skipping FIT verification on production hardware means anyone who can write to
boot storage can substitute an arbitrary kernel.

Summary and Key Takeaways

• bootm and booti hand off control from U-Boot to Linux, with kernel, ramdisk, and fdt addresses as arguments.
• U-Boot fixes up the device tree with runtime information before Linux ever reads it.
• Argument order matters — kernel, ramdisk, fdt — and getting it wrong produces confusing kernel-side failures.
• A FIT image collapses multi-component boots into a single, optionally signed and verified command.

Conclusion

This closes out the boot-image chapter of our free embedded systems course: from understanding
what a bootloader does, through device trees, choosing and building U-Boot, environment variables, image wrapping,
loading, NAND programming, and finally the handoff itself. From here, control belongs to the Linux kernel — which
is exactly where the next chapter of this free linux development course picks up.

FAQ