.

16 Oct 2020 - Dieser Artikel ist von John Bonesio - weitgehend automatisch übersetzt. - Die Linux Foundation hat diesen Beitrag gesponsert.

• Bootloaders for Embedded Linux Systems

.
Eingebettete Linux-Systeme enthalten fast immer einen Bootloader. Technisch gesehen ist es kein Teil von Linux, aber Bootloader sind ein wesentlicher Bestandteil der Embedded-Linux-Erfahrung.

Obwohl es technisch möglich ist, ein "embedded system" dazu zu bringen, den Linux-Kernel direkt nach dem "reboot" zu starten, wird dies im Allgemeinen nicht getan. Eingebettete Systeme trennen im Allgemeinen die Verantwortung für die Durchführung des anfänglichen Startcodes und den Power On Self Test (POST) vom Betriebssystem in einem separaten Bootloader, dem PPL.

Wenn eingebettete Systeme eingeschaltet werden, führt die CPU den Anfangscode aus – das ist ein Bootloader (der "primary bootloader" PPL). Dieser Bootloader initialisiert die erforderliche Hardware, findet dann das nächste auszuführende Programm (den "secundary bootloader" SPL), lädt dieses Programm in den Haupt-Speicher und springt in dieses Programm und führt es aus. An diesem Punkt wird der Bootloader-Code nicht erneut ausgeführt, sodass er aus dem Speicher verworfen wird.

• Mehrere Bootloader

Das nächste auszuführende Programm kann alles sein. Es ist nicht ungewöhnlich, dass der erste Bootloader PPL einen nächsten Bootloader SPL lädt, der wiederum einen weiteren Bootloader lädt.

Damit das System nützlich ist, lädt es schließlich den Betriebssystemcode – in diesem Fall den Linux-Kernel. Ein einfaches System führt den Bootloader nach dem Zurücksetzen der CPU aus und lädt und führt dann das Betriebssystem aus.

Einen separaten Bootloader zu haben, anstatt den Kernel sofort auszuführen, bietet Flexibilität; Jetzt kann sich der Kernel an verschiedenen Orten befinden, um vom Bootloader gefunden und geladen zu werden. Dadurch kann derselbe Bootloader von der frühen Entwicklung bis zur Produktion des eingebetteten Systems verwendet werden, indem einfach unterschiedliche Konfigurationen im Bootloader gespeichert werden.

Beispielsweise kann die eingebettete Plattform in der frühen Entwicklung vollständig über das Netzwerk booten; während es in einer späteren Entwicklung von einer SD-Karte booten kann und Produktionssysteme aus spi-flash und NAND-Flash Speichern booten können.

Parameter können auch basierend auf der Hardwarekonfiguration an den Kernel übergeben werden, und wir können jetzt dieselbe Kernel-Binärdatei auf verschiedenen eingebetteten Hardwaresystemen ausführen, die auf derselben Plattform basieren.

• U-Boot

Der gebräuchlichste (??) Bootloader für eingebettete Linux-Systeme ist U-Boot. U-Boot heißt offiziell "Das U-Boot", aber alle nennen es nur U-Boot. Es unterstützt viele CPU-Architekturen – einschließlich 68k, ARM, MicroBlaze, MIPS, Nios, SuperH, PPC, RISC-V, x86 und mehr. Es enthält auch Code zur Unterstützung vieler bestehender eingebetteter Entwicklungsplatinen. U-Boot ist ein Open-Source-Bootloader. Für Ihre benutzerdefinierten eingebetteten Systeme kann der U-Boot-Code geändert werden, um Ihre spezifische Hardware zu unterstützen.

• U-Boot kennt fast alle Dateisysteme

U-Boot hat auch viele Treiber, was bedeutet, dass es den Kernel an vielen verschiedenen Orten finden kann. U-Boot hat Treiber für FTP, NAND-Flash, MMC, i2c und mehr. Es enthält auch Dateisystemtreiber für FAT, ext2/3/4, Cramfs, Squashfs, JFFS2, UBIF, ZFS, btrfs und mehr.

Das bedeutet, dass sich die Kernel-Binärdatei an einem von vielen Orten befinden kann – einschließlich irgendwo in einem dieser Dateisysteme auf einem Medium – und U-Boot wird sie finden.

Die Boot-Konfiguration von U-Boot wird in Form von Umgebungsvariablen gespeichert. U-Boot speichert diese Umgebungsvariablen normalerweise im Flash-Speicher, in welchem ihre Werte über Neustarts hinweg bestehen bleiben können. Wenn U-Boot ausgeführt wird, sucht es nach der Umgebungsvariable mit dem Namen „bootcmd“. U-Boot erweitert dann diese Variable und führt alle darin enthaltenen Befehle aus.

U-Boot enthält eine Befehlszeile mit einer Unix-ähnlichen Syntax. In dieser Befehlszeilenumgebung können Sie die Umgebungsvariablen ändern und die neuen Werte im Flash speichern – um sie bei späteren Starts zu verwenden.

• Den Kernel über TFTP oder SD-Karte oder mit UBIFS vom NAND-Flash starten

In der Praxis können Sie U-Boot in der frühen Entwicklung einsetzen; B. so konfiguriert, dass der Kernel über TFTP mit NFS für das Root-Dateisystem gestartet wird. Wenn Sie sich der Veröffentlichung nähern, können Sie es ändern, um von einer SD-Karte über MMC mit ext4 zu booten. Und wenn Sie der Produktion noch näher kommen, können Sie U-Boot so ändern, dass es mit UBIFS vom NAND-Flash im Board bootet.

Ein weiteres wichtiges Feature in U-Boot ist die Unterstützung von Gerätebäumen. Gerätebäume sind eine neuere Möglichkeit, dem Kernel Hardware zu beschreiben. Eingebettete Systeme verfügen selten über zur Laufzeit erkennbare Hardware. Der Kernel kann nicht einfach die Hardware abfragen, um herauszufinden, was verfügbar ist.

Dem Kernel muss mitgeteilt werden, welche Geräte vorhanden sind. Anstatt dass Hardwareinformationen fest codiert sind, kann der Kernel den Gerätebaum lesen, der die Hardware beschreibt, und geeignete Treiber laden. Dadurch kann dieselbe Kernel-Binärdatei auf verschiedenen Boards ausgeführt werden, die auf derselben Architektur basieren.

Wie Sie anhand der großen Unterstützung für Geräte und Dateisysteme in Verbindung mit seiner Flexibilität sehen können, ist U-Boot eine einfache Wahl für eingebettete Systeme. Weitere Informationen zu U-Boot finden Sie auf der Website des Projekts:
.
https://www.denx.de/wiki/U-Boot
.

• Andere Bootloader

.
Während U-Boot ziemlich verbreitet ist, sind andere Bootloader für eingebettete Systeme möglich. Obwohl es zu viele Informationen sind, um alle möglichen abzudecken, werde ich ein paar andere gängige Open-Source-Bootloader erwähnen.

• Barebox ist ein (deutsches) Derivat von U-Boot.

Es hat die gleiche Flexibilität wie U-Boot, ist aber bestrebt, Linux-ähnlicher zu sein. Es verwendet eine dem Linux-Kernel ähnliche Treiberarchitektur und beinhaltet die Verwendung eines internen Dateisystems einschließlich Geräteknoten in /dev. (Nachtrag : barebox hat einen umfangreicheren Befehlsvorrat, ist dafür aber auch größer)

• RedBoot ist ein Bootloader von Red Hat.

Es verwendet intern die eCos RTOS-Technologie und bietet Unterstützung für das Debuggen von Anwendungen über ein serielles Kabel oder Ethernet.

Dies sind einige der gebräuchlicheren Optionen für Bootloader auf eingebetteten Linux-Systemen. Obwohl sie technisch gesehen Teil von Linux selbst sind, ist es nicht ungewöhnlich, den Bootloader zu erstellen und zu konfigurieren. Dies sollte zumindest einen Einstieg in die Welt der Embedded Bootloader geben.
.

The Zyxel NAS540 seems to have a Freescale QorIQ LS1024A SoC. There is no mainline barebox support for this SoC, so Zyxel must have created their own patches. I know nothing about these patches nor about the SoC,
so I'm sorry I can't really help you.
.
Sascha

Erklärung zu "barebox"
Der Bootloader dient in Embedded-Linux-Systemen primär dazu, die Hardware so weit zu initialisieren, dass der Kernel gestartet werden kann. Daneben ist der Bootloader aber auch ein wichtiges Werkzeug bei der Inbetriebnahme neuer Hardware: da es im Bootloader noch keine Nebenläufigkeit und keine Interrupts gibt, man aber bereits auf Hardware zugreifen kann, ist er auch bei Hardwerkern beliebt.
In modernen Systemen nutzen wir im Barebox die freedesktop.org Bootloader Specification, um die Komponenten eines zu bootenden Linux-Systems zu finden (Device Tree, Kernel, root-Dateisystem). Systeme mit Redundanzboot-Konzept und Field-Upgrade treffen im Bootloader die Entscheidung darüber, welches von 1-aus-N Systemen beim Starten gebootet werden soll.
.