Der generische Bootloader U-Boot

Auf Tauchkurs

Udo Seidel

Auch Embedded-Geräte brauchen einen Bootloader. Wer keinen integrierten verwenden will, kann auf einen generischen wie den freien universellen Bootloader, kurz U-Boot, zurückgreifen.

Der Erfolg von Raspberry Pi und Co. hat auch andere Embedded-Projekte ins Rampenlicht gerückt. Weniger Beachtung finden Projekte, die unscheinbare, aber notwendige Embedded-Komponenten wie Bootloader entwickeln. Einen sogenannten universellen Bootloader für eine Reihe von Architekturen hat das Projekt U-Boot unter der Federführung der Firma DENX entwickelt. iX hat sich den Universal Bootloader genauer angesehen.

Fertigmachen zum Ablegen

Die Ursprünge von U-Boot liegen fast 20 Jahre zurück außerhalb der ARM-Welt. Urahn ist das Projekt 8xxROM, ein Bootloader für die PowerPC-Architektur Ende des letzten Jahrtausends. 1999 zog das Projekt nach SourceForge um. Da der Hoster für Open-Source-Software aber keine Einträge mit Ziffern am Anfang erlaubte, musste ein neuer Name her: PPCBoot. Im Sommer 2000 erschien die erste Version unter dem neuen Namen. Knapp zwei Jahre später markierte die Version 2.0.0 von PPCBoot den Beginn von U-Boot. Die erneute Namensänderung trägt einer Neuausrichtung des Projekts Rechnung. Neben PPC soll der Bootloader auch andere Architekturen bedienen können. Inzwischen lautet der genaue Name des Softwareprojektes „Das U-Boot“, angeblich um eine Verwechslung mit dem deutschen Wort für Unterseeboot zu provozieren. Den Anfang der neu unterstützten Plattformen machte x86, gefolgt von MIPS und 2004 ARM. Inzwischen kann U-Boot auf 12 Architekturen arbeiten.

Derzeit kann der Bootloader auf 12 unterschiedlichen Architekturen Systeme starten. Die Software steht unter der GPL und ist mittlerweile über die üblichen Git-Mechanismen zugänglich. Der vorliegende Artikel konzentriert sich auf Untersuchungen von U-Boot auf ARM- und x86-Geräten.

U-Boot versteht sich als Bindeglied zwischen der Hardware und dem Betriebssystem, genauer gesagt dessen Kern. Nach dem Einschalten des Gerätes lädt die Firmware gemäß ihrer Konfiguration den Bootloader. Dessen Hauptaufgabe besteht darin, den Kernel zu lokalisieren, zu laden und auszuführen. Alte IT-Hasen wissen, dass für den letzten Schritt unterschiedliche Ansätze existieren.

Wer findet den Kernel

Der früher verbreitete Linux-Bootloader LILO musste den genauen Ablageort des Kernels auf dem Datenträger kennen, und zwar unabhängig vom Dateisystem. Dieser Ansatz erleichtert den Entwicklern die Arbeit, da sie sich nicht mit den logischen Strukturen oberhalb der Hardware beschäftigen müssen. Den Preis dafür bezahlen die Anwender. Sie müssen dem Bootloader den Ablageort jedes zusätzlichen oder neuen Betriebssystemkerns bekannt geben. Andernfalls schlägt der Ladevorgang fehl.

Kann der Bootloader hingegen Dateisysteme verstehen und lesen, ist er in der Lage, den Kernel selbstständig zu lokalisieren. U-Boot kann mit beiden Ansätzen umgehen. Zu den unterstützten Dateisystemen gehören die üblichen Verdächtigen wie die ext-Familie, FAT, JFSS2 (Journalling Flash File System 2), aber auch ZFS oder CramFS (Compressed ROM File System). Eine aktuelle und vollständige Liste findet sich im Quelltext von U-Boot. Außerdem kann der Bootloader den Kernel auch über die serielle Schnittstelle oder per TFTP oder gar NFS aus dem Netz laden. Für den letzteren Fall verfügt U-Boot über eigene NFS-Treiber. Sie verstehen die Versionen 2 und 3.