What You Will Learn

• Why Falcon mode exists and what problem it solves
• The architectural difference between a normal boot and a Falcon boot
• How to prepare the kernel argument block Falcon mode needs
• When Falcon mode is a good fit for a free embedded linux course project, and when it is not

Prerequisites

This lecture builds directly on the previous one, so you should have a working, tested U-Boot port for your board already booting normally through SPL and U-Boot proper.

Why Skip A Boot Stage?

U-Boot proper is a full-featured environment — it has a shell, a network stack, a command interpreter, USB support, and more. All of that takes time to initialize and code space to store. On a battery-powered sensor node or a camera that needs to be capturing frames within a few hundred milliseconds of power-on, that overhead is wasted: nobody is going to type commands at a shell during normal operation. Falcon mode exists for exactly this class of device.

What SPL Actually Does In Falcon Mode

SPL still runs first, still initializes DRAM and any clocks the kernel needs already configured, and still reads from the same boot medium. The difference is what it loads next: instead of fetching U-Boot proper, it fetches a kernel image and a pre-built parameter block from fixed, known locations, then jumps straight into the kernel entry point. There is no interactivity and no scripting at boot time — every decision was made in advance, on the host, at build or provisioning time.

Preparing The Falcon Boot Arguments

Because there is no U-Boot shell at runtime to construct boot arguments, you generate them ahead of time using U-Boot proper’s spl export command during development, then write the resulting blob to the fixed offset SPL expects.

# From the normal U-Boot proper shell, on the development board
ep-falcon!> setenv bootargs console=ttyS0,115200 root=/dev/mmcblk0p2 rootwait
ep-falcon!> spl export fdt $kernel_addr_r - $fdt_addr_r
ep-falcon!> mmc write ${fdt_addr_r} 0x300 0x80

This writes a ready-made “args” image containing the kernel entry point, boot arguments, and device tree reference to a raw sector SPL will read on the next power cycle — with CONFIG_SPL_OS_BOOT enabled in the defconfig.

$ make ep_falcon_defconfig
$ ./scripts/config --enable CONFIG_SPL_OS_BOOT
$ make -j$(nproc)

Real-World Use Cases

Device Type	Why Falcon Mode Helps
Battery-powered sensor node	Every millisecond of boot time drains the battery before useful work starts
Automotive rear-view camera	Regulations often require video within a fixed time budget after ignition
Industrial controller	Predictable, fixed boot path reduces field-support variability

Common Mistakes And Troubleshooting

• Stale args image: if you rebuild the kernel or change bootargs but forget to regenerate the Falcon args block, SPL will happily boot the old configuration.
• No fallback path: a board stuck in a bad Falcon config has no shell to recover from — always keep a way to force a normal boot, such as a strap pin or a held button, during development.
• DRAM or clock config drift: SPL in Falcon mode must configure everything the kernel needs, since U-Boot proper never runs to finish the job.

Best Practices

• Validate the full normal boot chain first; only move to Falcon mode once it is stable.
• Keep a hardware or strap-based escape hatch back to normal boot for field debugging.
• Regenerate the args image as part of your build pipeline, not as a manual afterthought.

Performance And Security Considerations

Falcon mode’s main win is measurable: removing U-Boot proper’s initialization typically shaves a large fraction of total boot time on constrained SoCs, since no shell, network stack, or command table needs to be brought up. Security-wise, the smaller code path running before the kernel is a smaller attack surface — but it also means there is no interactive recovery shell, so any secure-boot or verification logic must live entirely inside SPL itself.

Summary And Key Takeaways

• Falcon mode lets SPL load the Linux kernel directly, skipping U-Boot proper.
• Boot arguments are prepared ahead of time and written to a fixed location, since there is no runtime shell.
• It trades interactivity and recovery flexibility for meaningfully faster, more predictable boot times.

Conclusion

Falcon mode is a good example of how embedded boot design is really about trade-offs: flexibility versus speed, interactivity versus a smaller attack surface. Once your board reliably boots normally, Falcon mode is a natural next step for production images. In the next lecture we step away from U-Boot entirely and look at Barebox, a bootloader that took a very different design path from the same U-Boot roots.

FAQ

Does Falcon mode work with any SoC?

It requires CONFIG_SPL_OS_BOOT support in the SPL for your platform; most mainstream SoCs supported by U-Boot have this, but always check your board’s Kconfig options.

Can I still update the kernel after enabling Falcon mode?

Yes, but you must also regenerate and rewrite the Falcon args image whenever the kernel image, device tree, or bootargs change.

Is Falcon mode the same as a “fast boot” Linux distribution feature?

No — Falcon mode only affects the bootloader stage before the kernel starts; kernel and userspace boot time optimization is a separate, later concern.

What happens if the args image is corrupted?

SPL will fail to boot the kernel; without a fallback path this can leave the board unusable until physically reprogrammed.

Is Falcon mode suitable for a development board?

Generally no — you lose the interactive U-Boot shell that makes day-to-day development and debugging fast, so it is best reserved for production images.

---

PREV_LEC | NEXT_LEC