BSP & Yocto Optimization
Repeatable MeasurementReducing Cold Boot from 18.4s to 1.8s
−90% boot time · NXP i.MX8M Plus · Yocto Scarthgap 5.0
NXP i.MX8M Plus · Yocto Scarthgap 5.0 · Qt/QML HMI
01Problem
Problem: Why 18.4 Seconds Was Unacceptable
On an industrial platform, the image produced by a standard Yocto distribution brought the operator interface up 18.4 seconds after power-on. In the field scenario the device is power-cycled multiple times per day; on every start the operator was blind for more than 18 seconds. For critical system startup, this delay was operationally unacceptable.
- 01The full U-Boot flow burned seconds on environment loading, peripheral probing, and an unnecessary bootdelay
- 02Decompressing the zlib-compressed kernel image alone consumed ~1.7 seconds
- 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
→ Decompress time fell to 0.21 seconds (−88%)
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
→ Binary footprint shrank 65% (4.1 MB) — load and link cost dropped
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. The 1.8-second boot made 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.
All performance data was obtained in our own lab under repeatable conditions. Project-specific details are confidential under NDA. The methodology document is available on request.