Embedded Linux Boot Time Architecture
A Yocto-Based, Measurable Approach
Introduction
Boot time is one of the most underestimated problems in embedded systems, until it isn't. In production it directly affects system availability, recovery after failure, power-cycle scenarios and safety constraints. Most teams try to optimise it late and discover that the architecture itself is the bottleneck.
What Boot Time Really Is
Not "power on to login prompt" but power on to system ready for mission. That is the number worth measuring, and it is measured at the boundary of the system, not inside it.
Why Systems Boot Slowly
- Overloaded userspace. A stock systemd target starts services no operator needs before the interface appears.
- Kernel initialisation overhead. A generic kernel configuration probes hardware that does not exist on the board.
- Filesystem bottlenecks. An ext4 rootfs brings journal recovery and mount cost, and makes boot time unpredictable.
- Bootloader inefficiency. Environment loading, peripheral probing and boot delay sit on the critical path after SPL.
- No boot profiling. Without a staged boot graph, nobody knows which phase spends what.
How to Measure It (The Right Way)
Wrong: reading a timestamp from userspace once the shell is up.
Correct: an external signal, power-on to a GPIO raised by the application when it is genuinely ready, plus a staged boot graph for phase attribution, repeated across consecutive cold starts with median and worst case reported together.
What Changes the Answer
U-Boot Falcon Mode, so SPL loads the kernel directly and the full U-Boot flow leaves the critical path. LZ4 instead of zlib for kernel compression. A read-only SquashFS rootfs with a tmpfs overlay, which also removes journal recovery and reduces corruption risk on sudden power loss. Pruned and parallelised systemd services. A kernel configuration reduced to the hardware actually present. A user space rebuilt with musl libc and BusyBox.
Engineering Note
Smaller images decompress faster, and faster decompression shortens boot. The optimisation compounds, which is exactly why boot time belongs to architecture rather than to a late tuning pass.
When we publish a boot number, the board, the image configuration and the measurement point are published with it.