la cadena de arranque de Linux embebido

July 30, 2026 · – visitantes

La última vez escribí sobre DFU como una forma de flashear firmware por USB. Esa entrada dejó sin responder una pregunta que merece su propio espacio: ¿qué pasa realmente entre pulsar el botón de encendido y que aparezca un prompt de shell? DFU es solo una rama de este camino, así que vale la pena recorrerlo entero una vez.

Las etapas

Dibujada como un diagrama de flujo Mermaid, la cadena (con el lugar que ocupa DFU en ella) se ve así:

flowchart TD
    A[Power-on / Reset] --> B[Boot ROM<br/>immutable, on-chip]
    B --> C{Valid image on<br/>boot media?}
    C -->|No / forced| D[ROM recovery mode<br/>UART / USB]
    C -->|Yes| E[SPL<br/>first-stage bootloader]
    E --> F[U-Boot<br/>second-stage bootloader]
    F --> G{Enter DFU?}
    G -->|Yes| H[DFU mode<br/>waiting for firmware over USB]
    G -->|No| I[Load kernel + device tree]
    I --> J[Linux kernel]
    J --> K[Mount root filesystem]
    K --> L[init / systemd]

Y renderizada:

Boot ROM

Grabada en el silicio en el momento de fabricación — nada de ella puede cambiarse después. Su único trabajo es encontrar algo arrancable en uno de un pequeño conjunto de medios de arranque (eMMC, SD, flash QSPI, a veces USB) según los pines de modo de arranque o los eFuses, y saltar a ello. Si no encuentra nada válido, la mayoría de los SoC recurren en esta etapa a un modo mínimo de recuperación por UART o USB — el primerísimo lugar donde se puede hablar con el chip.

SPL

Abreviatura de Secondary Program Loader (el término que usa U-Boot para él; otros fabricantes lo llaman FSBL o similar). Se ejecuta desde una pequeña cantidad de SRAM integrada en el chip, antes incluso de que la DRAM esté inicializada, así que tiene que ser diminuto. Su trabajo principal es exactamente ese: levantar la DRAM y luego cargar la siguiente etapa — U-Boot completo — en ella.

U-Boot propiamente dicho

Esto es lo que la mayoría de la gente entiende por "el bootloader". Tiene drivers, una shell, variables de entorno, soporte de red y un intérprete de comandos. También es donde realmente vive DFU — ejecutar dfu 0 mmc 0 (o algo similar) hace que U-Boot entre en modo DFU en lugar de continuar con el arranque normal, que es el modo con el que dfu-util habla desde el lado del host. En caso contrario, carga la imagen del kernel y el blob del device tree en memoria y salta al kernel.

Kernel y espacio de usuario

El kernel se descomprime a sí mismo, activa la consola, sondea el hardware usando el device tree que se le pasó, y monta un sistema de archivos raíz — a menudo la misma tarjeta eMMC o SD desde la que arrancó el bootloader, a veces NFS durante el desarrollo. Una vez montado el sistema de archivos raíz, el kernel cede el control al PID 1 — normalmente systemd en una imagen construida con Yocto — y ahí es donde realmente empieza el "espacio de usuario".

Por qué esto importa para DFU

DFU solo tiene sentido una vez que se ve dónde encaja: es un desvío que U-Boot puede tomar en lugar de cargar el kernel, no algo separado añadido por encima. Por eso mismo DFU no puede rescatar todos los modos de fallo — si la propia boot ROM no puede encontrar un SPL válido, nunca se llega a U-Boot, y hay que depender del modo de recuperación que soporte la boot ROM (que varía mucho según el fabricante y es un buen tema para otra entrada).

Para seguir leyendo

• U-Boot: Generic SPL framework — cómo se construye el SPL y de qué es responsable.
• Trusted Firmware-A: Firmware Design — el flujo de arranque multietapa más elaborado (BL1/BL2/BL31/BL32/BL33) que se usa en muchos SoC Arm modernos con una cadena de arranque seguro, y que en esas plataformas se sitúa por debajo de U-Boot.

Lecturas Relacionadas

• ¿Qué es un Device Tree? — cómo se le describe el hardware al kernel
• ¿Qué es DFU? — grabar firmware por USB cuando no queda otra vía