Walk through the embedded Linux boot sequence from power-on to application.

The embedded Linux boot sequence has four main stages, each handing off to the next. First, the ROM bootloader (burned into the SoC at the factory) executes from internal ROM on power-on. It initializes the most basic hardware — typically a small amount of internal SRAM — and loads the next-stage bootloader from a configured boot medium (eMMC, SD card, SPI NOR flash, or UART/USB in recovery mode). The ROM bootloader is fixed by the silicon vendor and cannot be modified.

Second, U-Boot (or another second-stage bootloader) takes over. It initializes external DRAM, sets up clocks and PLLs, configures the boot medium controller, and provides a command-line environment for development. U-Boot loads the kernel image, the device tree blob (DTB), and optionally an initramfs into DRAM, then transfers control to the kernel's entry point.

Third, the Linux kernel decompresses itself (if compressed), initializes the memory management unit (MMU), sets up virtual memory, brings up the scheduler, and probes hardware drivers guided by the device tree. The kernel mounts the root filesystem — either from initramfs or directly from a block device — and launches the init process (PID 1).

Finally, the init system (systemd, BusyBox init, or a custom init script) starts userspace services in the configured order. On an embedded product, this typically ends with launching the main application daemon. Understanding this chain matters because boot-time bugs can hide at any stage, and optimizing boot time requires knowing which stage dominates.