Obwohl ein herkömmlicher PC und ein RasPi viele Gemeinsamkeiten aufweisen, fehlt dem Minirechner UEFI-Boot. Doch das lässt sich ändern.

Als der Raspberry Pi vor 13 Jahren an den Start ging, war er als preiswerter und kleiner Computer für Bildungszwecke gedacht. Für weniger als 30 Euro konnte man sich den Kleinstrechner nach Hause holen und IT von Grund auf lernen. Schnell gab es viele Projekte, die ihn für alle möglichen Zwecke einsetzten.

Dank der lizenzierbaren hardwareunterstützten Beschleunigung verrichtet er nicht selten als flotter Medienserver seine Dienste. Inzwischen gibt es unzählige Anwendungsfälle für den kleinen ARM-Rechner. Die Hardwareressourcen entsprechen heute einem Vielfachen der Anfangsmodelle. Eines hat sich in all den Jahren jedoch nicht geändert: die ersten Phasen des Bootprozesses.

Der Raspberry Pi startet grob skizziert ähnlich wie ein handelsüblicher PC. Nach dem Einschalten übernimmt die Firmware der Hauptplatine. Sie lässt sich über BIOS- beziehungsweise UEFI-Einstellungen bedingt steuern. Die Firmware übergibt anschließend an den Bootloader, im Linux-Umfeld üblicherweise Grub2, den Nachfolger des Grand Unified Bootloaders (Grub). Entweder über Benutzereingaben oder per Konfiguration findet er den Betriebssystemkern und andere notwendige Elemente wie die Initial RAM Disk (Initrd) oder die Kernel-Konfiguration. Danach geht das Kommando an das Betriebssystem über.

Beim RasPi verhält sich das ähnlich und doch etwas anders. Zunächst lässt sich die Firmware des Einplatinenrechners im Normalfall weder einsehen noch verändern. Allerdings finden sich manche Firmwares im Github-Verzeichnis des Raspberry-Pi-Projekts [1]. Einige wenige neuere Modelle erlauben das Neuprogrammieren des entsprechenden EEPROMs [2] – dazu später mehr. Die quasi fest verdrahtete Firmware lädt den Bootloader. Dabei kommt in der RasPi-Welt der Universal Bootloader, genannt U-Boot [3], zum Einsatz. Dessen Ursprünge liegen gute 20 Jahre zurück und außerhalb der ARM-Welt (siehe Kasten “PowerPC als Taufpate”).

U-Boot konfigurieren Sie typischerweise über eine ASCII-Datei. Sie befindet sich auf der ersten Partition des Bootmediums für den RasPi. Gewöhnlich nutzen Sie dazu eine SD-Karte oder eine per USB angeschlossene Festplatte. Allerdings bietet U-Boot eine Shell als interaktive Schnittstelle. Da die Ressourcen eines RasPi sehr begrenzt ausfallen, muss sich die Größe der Shell dementsprechend daran orientieren. Die Entwickler von U-Boot haben sich hier der Erfahrungen aus dem Busybox-Projekt bedient. Mit der Hush-Shell [4] erfragen Sie genauere Infos zur Hardware [5], greifen auf den Datenträger zu und laden den Linux-Kernel (Listing 1).

=> version
U-Boot 2025.07-00998-g4c3b5fcd810 (Jul 27 2025 - 09:59:51 +0200)
gcc (GCC) 15.1.1 20250521 (Red Hat 15.1.1-2)
GNU ld version 2.44-3.fc42
=>
=> bdinfo
boot_params = 0x00000000
DRAM bank   = 0x00000000
-> start    = 0x00000000
-> size     = 0x08000000
flashstart  = 0x00000000
flashsize   = 0x00000000
flashoffset = 0x00000000
baudrate    = 115200 bps
relocaddr   = 0x06f2d000
reloc off   = 0x0702d000
Build       = 32-bit
current eth = e1000#0
[...]
=> help
?         - alias for 'help'
acpi      - ACPI tables
base      - print or set address offset
bdinfo    - print Board Info structure
blkcache  - block cache diagnostics and control
bloblist  - Bloblists
boot      - boot default, i.e., run 'bootcmd'

Doch zurück zum Bootprozess. Der Raspberry Pi liest die Grundkonfiguration des Systems aus der Datei /boot/firmware/config.txt. Deren Inhalt lässt sich mit der BIOS-Konfiguration eines normalen PCs vergleichen. Interessanterweise liest nicht die CPU, sondern die GPU die Datei aus. Bei den meisten Hardwaremodellen lagern die passenden Firmware-Dateien ebenfalls im Verzeichnis /boot/firmware/ und hören auf den Namen start*.elf. Die jungen Modelle wie der RasPi 4B implementieren die Firmware direkt im EEPROM der Platine. Danach liest die GPU die Datei cmdline.txt ein und startet den Linux-Kernel mit den hinterlegten Parametern.

An dem Punkt setzt daraufhin der aus der PC-Welt bekannte Bootvorgang ein. Das Konzept aus Firmware, U-Boot und Linux-Kernel klappt sehr gut. Es gibt narrensichere Anleitungen, um einen handelsüblichen Raspberry Pi mit dem Standardbetriebssystem zum Laufen zu bringen. Obendrein können geübte Benutzer tiefer ins System eingreifen. Ebenfalls im Internet stößt man auf Rezepte zum Kompilieren eines RasPi-kompatiblen Kernels auf einem handelsüblichen Rechner [6]. Dazu gehört das Anpassen und Einbringen einer eigenen U-Boot-Version. Da bleiben also keine Wünsche offen – oder doch?

Wie sieht es mit dem System Management BIOS, kurz SMBIOS [7], aus? Dabei handelt es sich um einen Standard, um hardwarenahe Informationen über die Firmware und die Hauptplatine über eine Schnittstelle zugänglich zu machen, und das sogar vom laufenden System aus. Alte Hasen kennen in diesem Zusammenhang sicher das Linux-Werkzeug Dmidecode [8]. Einiger Beliebtheit erfreut sich das Auslesen der UUID als eindeutiges Erkennungsmerkmal der Hardware.

Doch das ist so erst einmal nicht möglich auf dem Raspberry Pi. Zwar lassen sich die Informationen innerhalb der U-Boot-Shell auslesen, aber dazu müsste man den RasPi neu starten und den Bootvorgang unterbrechen – also eher unpraktisch. Ein Auslesen aus dem laufenden Linux heraus funktioniert nicht. Stattdessen erscheint die Meldung No SMBIOS nor DMI entry point found, sorry.

Die Ursache dafür entspringt dem Linux-Kernel selbst. Auf der ARM-Plattform ist der Zugriff auf das SMBIOS nur möglich, wenn es sich um ein UEFI-System (Abbildung 1) handelt. Genau hier liegt der Hase im Pfeffer: Auf dem Raspberry Pi gibt es kein UEFI, jedenfalls nicht von Haus aus. Doch das lässt sich für ein paar Modelle ändern.

Abbildung 1: Kernel-Konfiguration für ARM mit Zugriff auf SMBIOS.

U-Boot trifft keine Schuld am fehlenden UEFI. Es lässt sich nämlich auch auf solchen Systemen als Bootloader verwenden. Sie können in der Hush-Shell sogar UEFI-Konfigurationen auslesen. Und es kommt noch besser: U-Boot muss nicht direkt einen Betriebssystemkern laden und ausführen. Prinzipiell kommen alle kompatiblen Binärobjekte infrage, also auch UEFI-Firmware.

Der Auftritt von UEFI

Doch noch einmal einen Schritt zurück: Welche Vorteile bietet UEFI auf dem RasPi? Da ist selbstredend der oben beschriebene Anwendungsfall mit SMBIOS, aber damit nicht genug. Ausgehend von UEFI lässt sich Grub2 als weiterer Bootloader integrieren, was mehrere Vorteile eröffnet. Zunächst lassen sich dann die Grub2-Kenntnisse und -Erfahrungen nahezu komplett auf das Verwalten des Raspberry Pi übertragen, was Sie auch hardwareübergreifend einfach automatisieren. Zusätzlich finden Sie im Internet deutlich mehr brauchbare Hinweise zum Untersuchen und Lösen von Problemen mit Grub2 als mit U-Boot – ein oft unterschätzter Vorteil. Im Idealfall benötigen Sie gar kein tiefergehendes Wissen bezüglich U-Boot: Sie müssen lediglich das Zusammenspiel mit UEFI hinbekommen.

Das Hauptargument für UEFI für den Raspberry Pi ist allerdings die Möglichkeit, Secure Boot einzusetzen. Seit 2013 macht es immer wieder von sich reden. Microsoft forderte es für die Hardwarezertifizierung von Windows 8, und es sah im ersten Moment so aus, dass dies Linux vor verschlossene Türen setzen würde. Letztlich kann Linux jedoch längst sehr gut mit UEFI Secure Boot umgehen, nur nicht auf dem RasPi. Es lohnt sich also, einen genaueren Blick auf UEFI für den Minirechner zu werfen. Auf dem Papier fallen die notwendigen Voraussetzungen moderat aus. Das ist zunächst die UEFI-Firmware selbst. Zur Erinnerung: Anders als beim RasPi gehört sie auf einem herkömmlichen PC zum Auslieferungszustand der Hardware.

Auch die UEFI-Firmware besitzt eine Konfiguration, die ihr sagt, welche Binärprogramme sie laden soll und wo sie sie findet. Es gibt auch eine UEFI-Shell, die interaktive Eingaben und Konfigurationen erlaubt. In jedem Fall besteht die Aufgabe darin, eben jene Binärprogramme zu laden und auszuführen. Sie liegen typischerweise auf der ersten Partition des ersten Datenträgers. Die mit einem FAT-32-Dateisystem versehene Partition verwendet als Kennung ESP (EFI System Partition). UEFI benötigt also keine Bootsektoren wie das alte PC-BIOS. Stattdessen sind es die Dateien BOOTX64.EFI und BOOTAA64.EFI für die x86- beziehungsweise die ARM-Welt (Listing 2).

### x86_64-Systeme
$ uname -m
x86_64
$ ls /boot/efi/EFI/BOOT/*EFI
/boot/efi/EFI/BOOT/BOOTX64.EFI
### ARM-Systeme
$ uname -m
aarch64
$ ls /boot/efi/EFI/BOOT/*EFI
/boot/efi/EFI/BOOT/BOOTAA64.EFI $

Die Herausforderung beim Raspberry Pi beginnt ganz am Anfang der UEFI-Ereigniskette mit der Frage: Wie gelangt die Firmware auf das Gerät? Hier kommen die Projekte ins Spiel, die die entsprechenden UEFI-Dateien [9] bereitstellen. Zum Redaktionsschluss lagen gebrauchsfertige UEFI-Firmware für die RasPi-Modelle 3 [10] und 4 [11] vor. Für Letzteres fällt die Bandbreite tatsächlich größer aus, als man auf den ersten Blick vermuten mag. Es betrifft nahezu sämtliche zum Modell 4 kompatiblen Varianten. Das schließt sowohl den Raspberry Pi 400 als auch die Compute-Varianten ein. Bei Modell 5 sieht es damit schlecht aus: Es gibt zwar eine erste Implementierung der UEFI-Firmware, aber sie funktioniert nur teilweise [12]. Überdies haben die Entwickler die Weiterarbeit derzeit eingestellt.

UEFI – Teil I

Deswegen konzentriert sich der weitere Artikel auf die Versionen 3 und 4. Dort lieferten die Labortests mit UEFI ausreichend erfolgreiche Resultate, das Modell 5 eignet sich lediglich bedingt. Ansonsten lässt sich die Aussage der UEFI-Firmware-Entwickler, dass es deutlich besser unterstützte Hardware gibt, als richtungsweisend bezeichnen. Die Untersuchung anderer Chips würde den Rahmen des Artikels sprengen. Er beschränkt sich außerdem auf die Betriebssysteme Raspberry Pi OS und Debian, jeweils in der Version “Bookworm”.

In der Standardinstallation verfügt das Linux-System über zwei Partitionen: Die mit FAT32 formatierte Bootpartition /boot/firmware enthält die Firmware-Dateien, die U-Boot zum Starten von Linux verwendet. Frühere Versionen umfassten das gesamte Verzeichnis /boot. Für UEFI benötigen Sie zwar ebenfalls eine FAT-Partition, die aber direkt unter /boot eingebunden sein muss (Abbildung 2). Darüber hinaus müssen dort die Binärdateien [13] für UEFI [14] selbst liegen.

Abbildung 2: Vergleich der Einhängepunkte auf einem traditionellen RasPi und einem Linux-System mit UEFI.

Der offensichtliche Schritt wäre also das Anlegen einer weiteren Partition inklusive Dateisystem sowie das Platzieren der genannten (U)EFI-Dateien darin. In der Realität entpuppt sich das Vorhaben jedoch als schwierig, denn typischerweise belegt die Erstinstallation die komplette SD-Karte. Sie müssen dementsprechend zuerst vorhandene Dateisysteme und Partitionen verkleinern und eventuell sogar verschieben. Je nach Systemkonfiguration müssen Sie diese Änderungen in der Partitionstabelle innerhalb des Linux-Systems eintragen. Dabei sind Fehler und unerwartete Nebeneffekte schier vorprogrammiert.

Der Autor fand dafür eine Abkürzung, die die bestehende FAT-Partition einfach wiederverwendet. Das reduziert die notwendigen Änderungen und damit die Fehleranfälligkeit. Zwar gilt es nach wie vor, eine Reihe von Schritten abzuarbeiten, doch das gelingt deutlich einfacher und lässt sich sogar komplett automatisieren.

Im ersten Schritt sichern Sie den Inhalt der ersten Partition, danach versehen Sie sie mit einer neuen ID (ESP) und dem Dateisystem FAT32. Nun binden Sie die Partition ein und platzieren dort die notwendigen Firmware-Dateien inklusive der UEFI-Shell. Spielen Sie die zuvor gesicherten Dateien zurück und passen Sie die Systemkonfiguration an, zum Beispiel in der /etc/fstab. Beim nachfolgenden Reboot lädt U-Boot dann die UEFI-Shell. Die detaillierte Beschreibung aller Schritte entnehmen Sie bitte der jeweiligen Dokumentation im Internet.

Noch einfacher erledigen Sie die Aufgabe mit einem Shell-Skript [15], das die Schritte automatisiert abarbeitet. Der Autor testete das mit den RasPi-Modellen 3, 4B, 400 und CM4. Auf der Systemseite waren Raspberry Pi OS, Debian und Armbian die Teilnehmer. Listing 3 zeigt die verkürzte Ausführung des Shell-Skripts und einige anschließende Prüfungen, ob alles wie gewünscht funktioniert.

$ ./enable.uefi.grub.4.rpi.sh
Hit:1 http://deb.debian.org/debian bookworm InRelease
[...]
The following additional packages will be installed:
  efibootmgr libefiboot1 libefivar1 libfuse2 mokutil os-prober shim-helpers-arm64-signed shim-signed shim-signed-common shim-unsigned
[...]
Creating config file /etc/default/grub with new version
[...]
Welcome to fdisk (util-linux 2.38.1).
[...]
The bootable flag on partition 1 is enabled now.
[...]
Changed type of partition 'W95 FAT32 (LBA)' to 'EFI (FAT-12/16/32)'.
[...]
Syncing disks.
[...]
mkfs.fat 4.2 (2021-01-31)
[...]
--2025-07-28 21:54:18--  https://github.com/pftf/RPi4/releases/download/v1.42/RPi4_UEFI_Firmware_v1.42.zip
[...]
RPi4_UEFI_Firmware_v1.42.zip    100%[================================>]   3.26M  10.6MB/s    in 0.3s
[...]
Archive:  /root/RPi4_UEFI_Firmware_v1.42.zip
  inflating: RPI_EFI.fd
[...]
  inflating: firmware/brcm/brcmfmac43455-sdio.txt
[...]
Installing for arm64-efi platform.
grub-install: warning: EFI variables are not supported on this system.
Installation finished. No error reported.
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.12.34+rpt-rpi-v8
[...]
done
$  fdisk -l /dev/mmcblk0[...]
Device         Boot   Start      End  Sectors  Size Id Type
/dev/mmcblk0p1 *      16384  1064959  1048576  512M ef EFI (FAT-[...])
/dev/mmcblk0p2      1064960 30536703 29471744 14.1G 83 Linux

Allerdings automatisiert das erwähnte Shell-Skript nicht alles. So fehlt zum Beispiel der Eintrag im Bootmenü, der das System hochfährt. Bei den 4er-Modellen braucht es zudem eventuell noch andere Einstellungen. Die Entwickler der Firmware haben nämlich das RAM auf 3 GByte begrenzt. Darüber hinaus ist das Verwenden der Device-Tree-Informationen (DT) deaktiviert. Das soll sicherstellen, dass die Firmware auf allen Geräten gleichermaßen funktioniert. Das Speicherlimit lässt sich ausschalten und spielt ohnehin nur bei entsprechend stark ausgerüsteten Geräten eine Rolle.

Die Device-Tree-Informationen spielen prinzipiell lediglich für den Kernel von Raspberry Pi OS eine Rolle. Sie dienen zum Beschreiben der Hardware für den Betriebssystemkern und sind daher essenziell. Doch auch hier vollzieht sich ein Wandel. Es gibt schon Konfigurationen [16], bei denen Raspberry Pi OS auch ohne die DT-Daten sauber hochfährt. Um möglichst kompatibel zu bleiben, ist der Zugriff auf diese DT-Daten im UEFI ausgeschaltet. Erneut lässt sich das modifizieren: Die beiden genannten Einstellungen finden Sie im Menü des Device Managers unter Raspberry**Pi Configuration | Advanced Configuration (Abbildung 3).

Abbildung 3: UEFI-Geräteeinstellungen für den Raspberry Pi.

Alternativzugang

Die beschriebene Prozedur erlaubt es, ein vorgefertigtes Linux-Abbild für den Raspberry Pi mit UEFI auszustatten. Der wesentliche Vorteil dabei ist, dass es keiner Neuinstallation bedarf. Der offensichtliche Nachteil besteht im Umbiegen des Einhängepunkts von /boot/firmware beziehungsweise der Doppelnutzung der ersten Partition. Wer das System frisch installiert, kann einen abgewandelten Weg zum Installieren von UEFI gehen.

Starten Sie mit einer leeren SD-Karte und erstellen Sie eine Partition mit einer Größe von 512 bis 1024 MByte. Versehen Sie diese mit der ID ef beziehungsweise uefi. Legen Sie darin ein FAT32-Dateisystem an und platzieren Sie dort die im Netz erhältlichen Firmware-Dateien inklusive UEFI. Starten Sie daraufhin den Raspberry Pi mit der eingesteckten SD-Karte, erscheint das UEFI-Begrüßungsfenster (Abbildung 4).

Abbildung 4: UEFI-Start auf dem Raspberry Pi.

Eine erfolgreiche Linux-Installation erfordert jedoch noch einige Schritte mehr. Herausforderungen begegnen Ihnen dabei ebenfalls. Zunächst müssen Sie einen möglichst einfachen Zugriff auf die Installationsdateien erlauben. Das verlangt ein minimales Betriebssystem und idealerweise den Start des Installationsprogramms. Das ist hier nicht anders. Zur Erinnerung: Bislang bootet der RasPi lediglich bis zum Ausführen von UEFI. Da gibt es noch kein Betriebssystem und auch keinen Zugriff auf die Installationsdateien.

Die Lösung des Problems ist letztlich gar nicht so schwer. Sie müssen sich nur das Bootmedium für das jeweilige Linux besorgen und dessen Inhalt komplett in die UEFI-Partition extrahieren. Dadurch landen der zugehörige Bootloader, Kernel und das Installationsprogramm genau da, wo die Firmware des RasPi sie erwartet.

Es empfiehlt sich, die netzwerkbasierte Variante des Bootmediums zu verwenden. Wie erwähnt, nutzte der Autor dieses Artikels zum Testen Debian oder direkt darauf aufbauende Distributionen, etwa debian-12.11.0-arm64-netinst.iso. Binden Sie das Image per Loop-Mount ein und kopieren Sie den gesamten Inhalt in die UEFI-Partition. Ein Beispiel sehen Sie in Listing 4. Dabei ist /dev/sdb die SD-Karte und /dev/sdb1 die Partition, die die Firmware-Dateien inklusive UEFI enthält.

$ mkdir /tmp/mnt
$ mkdir /tmp/mnt2
$ mount /dev/sdb1 /tmp
$ mount -o loop,ro debian-12.11.0-arm64-netinst.iso /tmp/mnt2
$ cd /tmp/mnt2
$ cp -a .* /tmp/mnt
$ cp -a * /tmp/mnt
$ sync

Damit fährt der RasPi über UEFI hoch und startet das Installationsprogramm. Ein paar Hindernisse warten trotzdem noch. Hintergrund ist der Umstand, dass sich UEFI und die Installationsdateien auf derselben Partition befinden. Bei Debian genügt es, an der entsprechenden Stelle auf eine Shell auszuweichen und den Befehl aus Listing 5 auszuführen. Die genauen Details [17] für diesen Fall finden Sie online.

$ mount -t vfat -o ro /dev/mmcblk0p1 /cdrom

Darüber hinaus muss das Installationsprogramm die UEFI-Partition als solche erkennen, da es die korrekte Platzierung von Bootloader und Kernel für das finale Linux-System steuert. Hier gibt es kein Allheilmittel, zuweilen hilft es aber, wenn Sie die UEFI-Partition als bootfähig markieren und mit der ID ef versehen. In unseren Tests waren immer wieder Nacharbeiten (Abbildung 5) über das Partitionskapitel des Installationsprogramms notwendig, aber machbar.

Abbildung 5: Beim Debian-Installer hakt es nicht selten.

Aussicht auf mehr

Entweder über das Skript enable.uefi.grub.4.rpi.sh oder per Neuinstallation – am Ende läuft ein Linux auf dem Raspberry Pi, das sich durchaus mit seinen PC-Pendants messen kann. Immerhin lässt sich auf das SMBIOS und damit auf Hardwareinformationen zugreifen, die sonst verborgen bleiben (Listing 6). Dabei sind die Informationen über das BIOS – also UEFI – an sich nicht überraschend. Version und Veröffentlichungsdatum kommen vom entsprechenden Projekt auf Github.

Mit der Verfügbarkeit des Zugriffs auf SMBIOS lässt sich der Raspberry Pi viel einfacher in bestehende Strukturen zur Systemverwaltung integrieren. Werkzeuge wie Dmidecode und ähnliche Skripte funktionieren hier nun identisch zu ARM-Rechnern in der Cloud oder handelsüblichen PCs aus der x86-Welt.

$ dmesg[...]
[    0.000000] efi: EFI v2.7 by https://github.com/pftf/RPi4
[    0.000000] efi: ACPI 2.0=0x38f82018 SMBIOS=0x39eb0000 SMBIOS 3.0=0x39e90000 ...
[    0.042935] efivars: Registered efivars operations
[...]
$ dmidecode[...]
Getting SMBIOS data from sysfs.
SMBIOS 3.3.0 present.
Table at 0x39E80000.
Handle 0x0000, DMI type 0, 26 bytes
BIOS Information
        Vendor: https://github.com/pftf/RPi4
        Version: UEFI Firmware v1.42
        Release Date: 05/25/2025
        ROM Size: 4032 kB
        Characteristics:
[...]
$ efibootmgr
BootCurrent: 0001
Timeout: 5 seconds
BootOrder: 0000,0006,0001
Boot0000* UiApp
Boot0001* Debian
Boot0006  UEFI Shell

Fazit

Auf Betriebssystemebene lässt sich der RasPi einfacher verwalten. Durch die Abstraktion von U-Boot durch UEFI dient Grub2 als Dreh- und Angelpunkt für die Installation und Konfiguration des Linux-Kernels. Spezielles Wissen über U-Boot ist nicht länger erforderlich. Einen Gutteil der UEFI-Konfiguration nehmen Sie nun bei Bedarf über eine SSH- oder ähnliche Verbindung vor. Das Bootmenü passen Sie mit Efibootmgr an. So lassen sich Einträge hinzufügen, entfernen oder die Bootreihenfolge festlegen. Darüber hinaus können Sie die UEFI-Daten über das Sysfs-System abrufen.

Dieser Artikel zeigt, dass sich das für neuere RasPi-Modelle vergleichsweise einfach umsetzen lässt. Doch damit nicht genug: Sie schaffen außerdem die Grundlage, um das Betriebssystem mit Secure Boot besser abzusichern. Dieses Thema behandeln wir demnächst in einem separaten Artikel. (tle)