BSP & Yocto Optimization
Engineering ApproachBoot Time Architecture on Yocto Devices
U-Boot Falcon Mode · LZ4 · SquashFS · NXP i.MX8M Plus
NXP i.MX8M Plus · Yocto Scarthgap 5.0 · Qt/QML HMI
01Problem
Problem: Where Boot Time Is Spent
On an industrial device, an image produced by a stock Yocto distribution brings the operator interface up only seconds after power-on. In the field the device is power-cycled several times a day, and on every start the operator waits. Boot time is not a comfort metric but time-to-operational-readiness, which makes it an architectural decision.
- 01The full U-Boot flow burned seconds on environment loading, peripheral probing, and an unnecessary bootdelay
- 02Decompressing a zlib-compressed kernel image alone takes a significant share of the critical path
- 03ext4 rootfs journal recovery and mount time were the unpredictable component of startup
- 04A full glibc-based userspace inflated init time with unnecessary service startups
- 05Boot time was not measured systematically, nobody knew which stage consumed what
02System Context
03Root Cause Analysis
- 01The full U-Boot flow was unnecessary after SPL: environment loading, USB/network probing, and bootdelay consumed seconds on the critical path
- 02The kernel image was zlib-compressed, decompression on Cortex-A53 was ~8× slower than LZ4
- 03The rootfs was ext4: journal recovery, fsck risk, and mount cost made startup both slow and unpredictable
- 04Userspace was built with glibc + full coreutils, binary size and dynamic linking cost delayed init
- 05A significant share of boot-time services was not required for the operator UI, and parallel startup was not configured
04What We Changed
U-Boot Falcon Mode: SPL configured to load the kernel directly, removing full U-Boot from the critical path
→ Bootloader stage dropped from seconds to milliseconds
Kernel compression switched from zlib to LZ4
→ Kernel decompression time on the critical path drops measurably
rootfs migrated from ext4 to read-only SquashFS + tmpfs overlay
→ Mount time became constant, journal recovery disappeared; filesystem corruption risk reduced
Userspace rebuilt with musl libc + BusyBox
→ The binary footprint shrinks, load and dynamic linking cost drops
Boot services trimmed; non-UI-critical services deferred until after the interface is up
→ Qt HMI ready for the operator 1.8 seconds after power-on
05Benchmark Results
06Why It Mattered
Boot time is not a comfort metric; it is time-to-operational-readiness. A short boot makes the device feel effectively 'instant-on' across power interruptions and shift cycles.
- 01The ~18-second blind wait the operator experienced on every start was eliminated
- 02The read-only SquashFS rootfs structurally reduced filesystem corruption risk under sudden power loss in the field
- 03The smaller image reduced OTA update time and bandwidth cost
- 04The boot-graph measurement setup was made permanent, future regressions are caught in the build pipeline
To evaluate your BSP & Yocto Optimization needs on your own platform, schedule an embedded architecture audit or scope your platform class with the system requirements calculator.
Methodology Note
- Boot time was measured end-to-end from power-on to the Qt interface's 'ready' GPIO signal, based on an external signal, not software logs
- Bootloader/kernel/init timestamps were extracted with a boot graph for per-stage analysis
- Measurements were repeated across consecutive cold boots; median and worst-case reported together
- Comparisons used identical hardware with image configuration as the only variable
- Project details remain confidential under NDA, client identity is anonymized
Is your device's boot time slowing down field operations?
Free technical assessment, let's review the latency and determinism challenges in your system together.
This page describes a method, not a measurement report. Spikedge publishes only measurements taken on its own bench whose setup can be published; when a publishable measurement for this topic exists, it will be added here.