Hands-on courses for your engineering team.
Fast Boot
Boot Time Optimization.
Fast and Reliable Booting
Fast boot times and a reliable bootloader are foundational requirements for embedded Linux systems. The bootloader’s influence on system behavior — and on the user’s first impression of a product — is often underestimated, and boot time is frequently the last thing optimized, yet can be the hardest to recover once the architecture is set.
11 s → 656 ms
Measured on an Atmel AT91 ARM9: a 94% reduction across bootloader, kernel, and userspace — with no changes to the application or target hardware.
A bootloader does more than initializing hardware and handing off to the operating system. It directly influences boot time, is an essential part of the secure boot chain, and often includes watchdog monitoring and factory reset logic as well.
Many of these requirements can be addressed with well-established bootloaders such as U-Boot, coreboot, or Redboot. We use these in customer projects regularly and adapt them to the specific hardware and requirements of each system.
When demands become more complex — tighter boot time targets, more sophisticated update concepts, or stricter security requirements — an Initial Program Loader (IPL) approach can be applied: the bootloader itself is kept as small and simple as possible, while the logic that would otherwise live there is moved into the operating system.
This offers two concrete advantages:
- The bootloader codebase is significantly smaller, which reduces maintenance effort and makes the component easier to verify and certify.
- Update logic and other system management tasks can be implemented with standard Linux tools, rather than in a constrained bootloader environment.
Fast Boot
Modern embedded devices are complex — in terms of their own capabilities and in terms of their integration into larger systems. IoT and Industry 4.0 contexts add further requirements around connectivity, remote management, and availability.
Boot time becomes a critical factor especially when a project moves from a microcontroller to a more capable SoC. The new hardware is significantly more powerful, but the introduction of a full operating system can make boot times feel like a step backward. Managing this trade-off is a core part of embedded Linux engineering.
The Boot Process
A Linux system boots in different phases. Each one is a lever, and each one can be measured independently:
PhaseWhat happensOptimization potential
Bootloader
Hardware init, kernel and device tree load, handoff
HIGHMany default features unused
Kernel
Drivers init, userspace start
HIGHAn un-optimized kernel commonly costs 3–10 seconds on the critical path, worse when drivers need synchronized firmware loads over a slow bus
Initramfs
Mounts root fs, loads modules, prepares userspace
MEDIUMOften removed entirely in optimized systems
Userspace init
systemd services and init scripts
VERY HIGHOften the largest share
Application
Application ready
DEPENDSIf critical path is not optimized
Results from 11 Seconds to under 700 msec
Boot-time optimization is usually approached from several angles simultaneously. The chart below shows the cumulative reduction in boot time after each optimization step, measured on an Atmel AT91 ARM9.
Unoptimized baseline
11.00 s
U-Boot: remove networking, USB
8.75 s
Skip per-boot image verification
8.39 s
Trim kernel configuration
8.10 s
Streamline userspace init scripts
7.38 s
Initramfs with direct app launch
4.16 s
Replace U-Boot with custom IPL
1.26 s
Pre-set
lpj= (skip calibration)
1.06 s
Suppress serial console output
736 ms
Kernel compression: gzip → LZO
656 ms
cumulative boot time after each step · Atmel AT91 ARM9
The first two optimizations tackle the bootloader: removing unused U-Boot features such as networking and USB support cuts the boot time to 8.75 s, and skipping the per-boot image verification check brings it to 8.39 s.
Trimming the kernel configuration to what the hardware actually needs drops the time to 8.1 s, and streamlining the userspace init scripts by cutting sequential waits and services not required at startup takes it to 7.38 s.
Switching to an initramfs with direct application launch cuts the time nearly in half, from 7.38 s to 4.16 s. Replacing U-Boot with a custom Initial Program Loader brings it down to 1.26 s: a purpose-built loader that does only what this specific hardware requires is faster than a general-purpose bootloader.
The final three steps are smaller but visible. Pre-setting the lpj= kernel parameter skips the delay loop calibration that normally runs on every boot (1.06 s). Suppressing serial console output removes the blocking UART I/O behind every kernel log line (736 ms). Switching kernel compression from gzip to LZO which decompresses faster on low-power CPUs brings the bar to its final length: 656 ms.
The result is a system that boots 94% faster than the baseline, with no changes to the application or target hardware.
Work with us on your next Boot up
We work with you on security architecture, integration, and certification for your embedded project. If you have specific requirements around CRA compliance, IEC 62443, or a particular hardware platform, get in touch.
Consulting
Boot time analyses, Boot Security and more.
Implementation
Boottime optimization and bootloader development.
Training
How fast does your product need to boot?