Die Boot-Kette von eingebettetem Linux

July 30, 2026 · – Besucher

Beim letzten Mal habe ich über DFU als Möglichkeit geschrieben, Firmware über USB zu flashen. Dieser Beitrag ließ eine Frage aus, die es wert ist, für sich beantwortet zu werden: Was passiert eigentlich zwischen dem Drücken des Einschaltknopfs und dem Erscheinen eines Shell-Prompts? DFU ist nur ein Zweig auf diesem Weg, daher lohnt es sich, ihn einmal ganz durchzugehen.

Die Stufen

Als Mermaid-Flussdiagramm gezeichnet sieht die Kette (mit dem Platz von DFU darin) so aus:

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]

Und gerendert:

Flussdiagramm der Boot-Kette von eingebettetem Linux: Das Einschalten setzt in die Boot-ROM zurück, die das Boot-Medium auf ein gültiges Image prüft. Wird keines gefunden (oder Recovery erzwungen), wechselt sie in einen UART/USB-Recovery-Modus. Andernfalls lädt sie das SPL, das wiederum U-Boot proper lädt. U-Boot kann entweder in den DFU-Modus wechseln, um auf Firmware über USB zu warten, oder Kernel und Device Tree laden, Linux booten, das Root-Dateisystem einhängen und an init/systemd übergeben.

Boot-ROM

Zur Herstellungszeit in das Silizium eingebrannt — daran kann im Nachhinein nichts geändert werden. Ihre einzige Aufgabe ist es, auf einem von wenigen möglichen Boot-Medien (eMMC, SD, QSPI-Flash, manchmal USB) irgendetwas Bootfähiges zu finden — abhängig von Boot-Mode-Pins oder eFuses — und dorthin zu springen. Findet sie nichts Gültiges, fallen die meisten SoCs an dieser Stelle auf einen minimalen UART- oder USB-Recovery-Modus zurück — die allererste Stelle, an der man überhaupt mit dem Chip kommunizieren kann.

SPL

Kurz für Secondary Program Loader (U-Boots Bezeichnung dafür; andere Hersteller nennen es FSBL oder Ähnliches). Es läuft aus einer kleinen Menge On-Chip-SRAM heraus, noch bevor der DRAM überhaupt initialisiert ist, muss also winzig sein. Seine Hauptaufgabe ist genau das: den DRAM hochfahren und dann die nächste Stufe — vollständiges U-Boot — hineinladen.

U-Boot proper

Das ist es, was die meisten Leute meinen, wenn sie „der Bootloader" sagen. Es hat Treiber, eine Shell, Umgebungsvariablen, Netzwerkunterstützung und einen Befehlsinterpreter. Hier lebt auch tatsächlich DFU — der Befehl dfu 0 mmc 0 (oder ähnlich) versetzt U-Boot in den DFU-Modus, anstatt den normalen Bootvorgang fortzusetzen, und genau mit diesem Modus spricht dfu-util von der Host-Seite aus. Andernfalls lädt es das Kernel-Image und den Device-Tree-Blob in den Speicher und springt zum Kernel.

Kernel und Userspace

Der Kernel entpackt sich selbst, aktiviert die Konsole, sondiert die Hardware anhand des ihm übergebenen Device Trees und hängt ein Root-Dateisystem ein — oft dieselbe eMMC- oder SD-Karte, von der der Bootloader gebootet hat, während der Entwicklung manchmal NFS. Sobald das Root-Dateisystem eingehängt ist, übergibt der Kernel an PID 1 — bei einem mit Yocto gebauten Image üblicherweise systemd — und dort beginnt der „Userspace" tatsächlich.

Warum das für DFU wichtig ist

DFU ergibt erst Sinn, wenn man sieht, wo es einzuordnen ist: Es ist ein Umweg, den U-Boot anstelle des Ladens des Kernels nehmen kann, kein separat aufgesetztes Extra. Deshalb kann DFU auch nicht jeden Fehlerfall retten — findet die Boot-ROM selbst kein gültiges SPL, erreicht man U-Boot überhaupt nie und ist stattdessen auf den von der Boot-ROM unterstützten Recovery-Modus angewiesen (der je nach Hersteller stark variiert und ein gutes Thema für einen weiteren Beitrag wäre).

Weiterführende Literatur

Weiterführende Artikel

Kommentare