Embedded Linux 부팅 최적화: 초에서 밀리초까지

Source: Dev.to

Overview

Fast boot is not a single kernel option. It is the result of measuring and shortening every stage between power‑on and useful work. For HMIs, gateways, and control devices, boot time affects perceived quality and sometimes functional requirements. A desktop‑like boot path is rarely acceptable in a dedicated embedded product.

Boot Pipeline

The boot chain includes:

• ROM
• Bootloader
• Kernel decompression
• Driver initialization
• Root filesystem mount
• Init services (e.g., systemd)

Common Sources of Latency

• U‑Boot delays – countdowns, unused discovery paths, and generic configuration.
• Unused kernel drivers – building a monolithic kernel adds unnecessary initialization time.
• Broad systemd dependencies – loading generic distribution services that are not needed for the first interaction.
• Filesystem choice – SquashFS, initramfs, ext4, and read‑only layouts have different trade‑offs.

Optimization Checklist

• Instrument boot with timestamps before optimizing.
• Remove bootloader countdowns and any unused discovery paths.
• Build a kernel with only the required drivers and features.
• Parallelize or defer services that are not needed for the first user interaction.
• Measure cold boot repeatedly on production‑like storage.
• Optimize systemd after checking for bootloader delays.
• Avoid loading generic distribution services on a dedicated device.
• Define the user‑visible target (the moment the system becomes useful), not just when Linux finishes booting.

Conclusion

Embedded Linux can boot very quickly, but only when the system is treated as a product‑specific boot pipeline rather than a generic desktop environment.

Canonical Source

Embedded Linux boot optimization: from seconds to milliseconds – the original article that inspired this draft.