la chaîne de démarrage de Linux embarqué

July 30, 2026 · – visiteurs

La dernière fois, j'ai écrit sur le DFU comme moyen de flasher un firmware via USB. Cet article laissait de côté une question qui mérite d'être traitée à part : que se passe-t-il réellement entre l'appui sur le bouton d'alimentation et l'apparition d'une invite de shell ? Le DFU n'est qu'une branche de ce chemin, il vaut donc la peine de le parcourir en entier une fois.

Les étapes

Représentée sous forme d'organigramme Mermaid, la chaîne (avec la place du DFU) ressemble à ceci :

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]

Et une fois rendue :

Boot ROM

Gravée dans le silicium à la fabrication — rien ne peut y être modifié par la suite. Son seul rôle est de trouver quelque chose de démarrable parmi un petit ensemble de supports de démarrage (eMMC, SD, flash QSPI, parfois USB) selon les broches de mode de démarrage ou les eFuses, et d'y sauter. Si elle ne trouve rien de valide, la plupart des SoC basculent à ce stade vers un mode de récupération minimal UART ou USB — le tout premier endroit où l'on peut communiquer avec la puce.

SPL

Abréviation de Secondary Program Loader (le terme employé par U-Boot ; d'autres fabricants l'appellent FSBL ou similaire). Il s'exécute depuis une petite quantité de SRAM intégrée à la puce, avant même que la DRAM soit initialisée, il doit donc être minuscule. Son rôle principal est exactement cela : initialiser la DRAM, puis y charger l'étape suivante — U-Boot complet.

U-Boot proprement dit

C'est ce que la plupart des gens désignent par « le bootloader ». Il dispose de pilotes, d'un shell, de variables d'environnement, d'un support réseau et d'un interpréteur de commandes. C'est aussi là que vit réellement le DFU — exécuter dfu 0 mmc 0 (ou similaire) fait basculer U-Boot en mode DFU au lieu de poursuivre le démarrage normal, c'est ce mode auquel dfu-util s'adresse depuis le côté hôte. Sinon, il charge l'image du noyau et le blob de device tree en mémoire et saute vers le noyau.

Noyau et espace utilisateur

Le noyau se décompresse lui-même, active la console, sonde le matériel à l'aide du device tree qui lui a été transmis, et monte un système de fichiers racine — souvent la même carte eMMC ou SD depuis laquelle le bootloader a démarré, parfois du NFS pendant le développement. Une fois le système de fichiers racine monté, le noyau passe la main au PID 1 — généralement systemd sur une image construite avec Yocto — et c'est là que l'« espace utilisateur » commence réellement.

Pourquoi c'est important pour le DFU

Le DFU ne prend son sens qu'une fois qu'on voit où il se situe : c'est un détour qu'U-Boot peut emprunter au lieu de charger le noyau, pas un élément séparé greffé par-dessus. C'est aussi pourquoi le DFU ne peut pas sauver tous les modes de défaillance — si la boot ROM elle-même ne trouve pas de SPL valide, on n'atteint jamais U-Boot, et il faut alors compter sur le mode de récupération que la boot ROM prend en charge (ce qui varie beaucoup selon le fabricant et constituerait un bon sujet pour un autre article).

Pour aller plus loin

U-Boot: Generic SPL framework — comment le SPL est construit et de quoi il est responsable.
Trusted Firmware-A: Firmware Design — le flux de démarrage multi-étapes plus élaboré (BL1/BL2/BL31/BL32/BL33) utilisé sur de nombreux SoC Arm modernes avec une chaîne de démarrage sécurisé, qui se situe sous U-Boot sur ces plateformes.