la catena di avvio di Linux embedded

July 30, 2026 · – visitatori

L'ultima volta ho scritto del DFU come modo per flashare il firmware via USB. Quell'articolo lasciava da parte una domanda che merita una risposta a sé: cosa succede realmente tra la pressione del pulsante di accensione e la comparsa di un prompt di shell? Il DFU è solo un ramo di questo percorso, quindi vale la pena percorrerlo tutto una volta.

Le fasi

Disegnata come un diagramma di flusso Mermaid, la catena (con il posto occupato dal DFU) è così:

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]

E, renderizzata:

Boot ROM

Incisa nel silicio in fase di produzione — dopodiché non può più essere modificata in alcun modo. Il suo unico compito è trovare qualcosa di avviabile su uno dei pochi supporti di avvio possibili (eMMC, SD, flash QSPI, a volte USB) in base ai pin di boot-mode o agli eFuse, e saltarci. Se non trova nulla di valido, la maggior parte dei SoC ripiega a questo punto su una modalità di recovery minimale via UART o USB — il primissimo punto in cui è possibile comunicare con il chip.

SPL

Abbreviazione di Secondary Program Loader (il termine usato da U-Boot; altri produttori lo chiamano FSBL o simili). Viene eseguito da una piccola quantità di SRAM on-chip, prima ancora che la DRAM sia inizializzata, quindi deve essere minuscolo. Il suo compito principale è esattamente questo: inizializzare la DRAM, quindi caricarvi la fase successiva — U-Boot completo.

U-Boot vero e proprio

È ciò che la maggior parte delle persone intende quando dice "il bootloader". Ha driver, una shell, variabili d'ambiente, supporto di rete e un interprete di comandi. È anche qui che vive realmente il DFU — eseguire dfu 0 mmc 0 (o simile) fa entrare U-Boot in modalità DFU invece di proseguire con l'avvio normale, ed è la modalità con cui dfu-util comunica dal lato host. Altrimenti, carica in memoria l'immagine del kernel e il blob del device tree e salta al kernel.

Kernel e userspace

Il kernel si decomprime da solo, attiva la console, sonda l'hardware usando il device tree che gli è stato passato, e monta un file system radice — spesso la stessa scheda eMMC o SD da cui il bootloader ha avviato, a volte NFS durante lo sviluppo. Una volta montato il file system radice, il kernel passa il controllo al PID 1 — di solito systemd su un'immagine costruita con Yocto — ed è lì che lo "userspace" inizia davvero.

Perché questo è importante per il DFU

Il DFU ha senso solo una volta che si vede dove si colloca: è una deviazione che U-Boot può prendere al posto di caricare il kernel, non qualcosa di separato aggiunto sopra. È anche per questo che il DFU non può salvare da ogni modalità di guasto — se la boot ROM stessa non riesce a trovare uno SPL valido, non si arriva mai a U-Boot, e si deve fare affidamento sulla modalità di recovery supportata dalla boot ROM (che varia molto da produttore a produttore ed è un buon argomento per un altro articolo).

Per approfondire

• U-Boot: Generic SPL framework — come viene costruito lo SPL e di cosa è responsabile.
• Trusted Firmware-A: Firmware Design — il flusso di avvio multi-fase più elaborato (BL1/BL2/BL31/BL32/BL33) usato su molti SoC Arm moderni con una catena di avvio sicuro, che su queste piattaforme si trova sotto U-Boot.

Letture Correlate

• Che Cos'è un Device Tree? — come l'hardware viene descritto al kernel
• Cos'è il DFU? — scrivere il firmware via USB quando non resta altra via