Embedded-Systeme & Mikrocontroller Multicore-Embedded-SystemE ohne BIOS

Mit so genannten Systems-on-Chip (SoC) verschiedenster Hersteller ziehen seit Jahren Embedded-Systeme in allerlei Geräte und Maschinen ein. Im Vergleich zu Desktop-PCs stehen diese an Leistungsfähigkeit und Komplexität kaum mehr nach: 32-Bit-ARM-Architektur - 64 Bit ist angekündigt - Single- und Multicore, Taktfrequenzen im Gigahertz- und Arbeitsspeicher im Gigabyte-Bereich sind keine Seltenheit. Dazu gesellen sich unzählige weitere Funktionseinheiten und Schnittstellen. Durch diese Entwicklung finden auch entsprechend komplexe und leistungsfähige Betriebssysteme ihren Einzug in die Embedded-Welt: Windows CE, Linux, Android, QNX, vxWorks u. a.Während die Boot-ROMs solcher SoCs zwar Möglichkeiten bieten, von unterschiedlichsten Medien zu booten, sind sie meist nicht dafür ausgelegt, gleich ein vollwertiges Betriebssystem direkt zu starten. Sei es, weil sie zum Beispiel keine Möglichkeit bieten, selbst das DRAM zu initialisieren - von der automatischen Erkennung und Initialisierung unterschiedlicher DRAM-Konfigurationen gar nicht zu reden - und daher schlicht daran scheitern, einen komplexen und entsprechend großen Betriebssystemkern ins RAM zu laden oder weil ein solches Konzept spätestens bei Betriebssystem-Updates an seine Grenzen stößt, weil komplexe Betriebssysteme nur selten darauf ausgelegt sind, sich selbst und insbesondere ihr gerade in Verwendung befindliches Dateisystem einfach und stabil zur Laufzeit auszutauschen. Aus diesen Gründen setzen Embedded-Systeme, die Betriebssysteme wie Windows CE, Linux oder Android verwenden, meist auch sehr komplexe BIOS-/Bootloader-Systeme ein. Weit verbreitet sind unter anderem U-Boot, EBoot, RedBoot oder Barebox , die die grundlegende Initialisierung des gesamten Systems übernehmen, das eigentliche Betriebssystem von verschiedenen Medien nachladen und darüber hinaus auch noch umfangreiche Möglichkeiten zur Systemkonfiguration und -wartung, für Software-Updates sowie Test und Diagnose zur Verfügung stellen. So flexibel dies auf den ersten Blick auch scheint, birgt ein solch komplexes BIOS dennoch einige Nachteile:

�?� Es erfordert viele eigene Treiber für verschiedenste Speichermedien (u. a. NOR-Flash, NAND-Flash, eMMC, SD-Karten, USB-Sticks), Schnittstellen (RS232, RS485, Ethernet, WLAN, Display mit Touch, USB-Maus und -Tastatur) und Kommunikationsprotokolle (u. a. Terminal, XMODEM, YMODEM, IPv4, IPv6, Telnet, FTP, SFTP, SSH, HTTP, HTTPS) , die �?� durch ihre jeweilige Initialisierung die Bootzeit verlängern, auch wenn sie im regulären Feldeinsatz gar nicht benötigt werden und �?� zusätzlich zu den Treibern im eigentlichen Betriebssystem entwickelt, getestet und gepflegt werden müssen. �?� Je nach Anwendungsfall sind verschiedene Benutzer-Interfaces für Konfiguration, Wartung, Test und Update erforderlich: �?� OS-Entwickler und Techniker vor Ort benötigen direkten Zugang zum BIOS, etwa über eine RS232-Schnittstelle oder Ethernet �?� Gerätehersteller und -betreiber wünschen zunehmend öfter Fernwartungsmöglichkeiten von einem zentralen Rechner aus oder gar übers Internet �?� Anlagenbetreiber bzw. Endanwender benötigen eine möglichst einfache ggf. sogar vollautomatische Möglichkeit zur Durchführung von System-Updates. �?� Die Bedienung unterscheidet sich sehr stark von den Bedienkonzepten des eigentlichen Betriebssystems und den Endanwendungen. �?� Viele Konfigurationseinstellungen müssen zwischen BIOS und Betriebssystem synchronisiert werden, damit ein System zum Beispiel immer über dieselbe IP-Adresse ansprechbar ist.

Die parallele Entwicklung und Pflege solcher umfangreichen Treiber- und Kommunkationsstacks in Bootloader und Betriebssystem sowie der Abgleich ihrer jeweils aktuellen Konfigurationen untereinander ist kaum noch praktikabel. Erst recht nicht, wenn man, wie zum Beispiel Garz & Fricke, dieselben Embedded-Systeme sowohl mit Windows CE als auch mit Linux oder Android anbietet. Da in der Praxis der weitaus häufigste Anwendungsfall für ein BIOS/Bootloader schlicht darin besteht, nur möglichst schnell das Betriebssystem zu starten, auf dem dann die eigentliche Steueranwendung läuft, haben wir bei unseren jüngsten Systemen zu einem anderen, einfacheren aber dennoch flexibleren Konzept gewechselt. Dazu wurde die BIOS/Bootloader-Funktionalität in zwei separate Software-Pakete aufgeteilt:

1. Ein simpler reiner Bootloader („Flash-N-Go Boot“), der vollständig aus dem SoC-internen SRAM läuft und nur das Nötigste an Treibern mitbringt, um das System zu initialisieren und ein OS von einem lokalen Speichermedium schnell nachzuladen und zu starten. Eine interaktive Konsole gibt es nicht; nur eine Möglichkeit, per Taster am Gerät oder über eine nichtflüchtige Variable im System zwischen zwei Betriebssystemen zu wählen, die beide permanent auf einem lokalen Speichermedium im System bereit stehen. 2. Ein spezialisiertes, abgespecktes Linux-System („Flash-N-Go System“), das die komplette technische Infrastruktur für Systemtest, -wartung, -konfiguration und -update zur Verfügung stellt und parallel zum eigentlichen Betriebssystem auf dem Gerät installiert ist.

Die Abbildungen stellen die beiden unterschiedlichen Ansätze gegenüber: In Abbildung 1 steht die klassische Variante mit einem „All-In-One“-Bootloader, in Abbildung 2 die Aufteilung in Bootloader (zum reinen Starten eines Betriebssystems) und Mini-Linux (für Wartung und Konfiguration des Gesamtsystems). Auf den ersten Blick mag die letztere Variante komplizierter erscheinen, tatsächlich erleichtert sie aber einiges:

�?� Der Bootloader macht nichts anderes mehr als ein Betriebssystem zu starten und bringt nur noch die dafür allernötigsten Treiber und Funktionen mit sich. Dies verringert sowohl die im Feld nicht unwichtige Bootzeit, sondern vor allem auch Zeit und Kosten für Entwicklung, Portierung, Wartung und Test des Bootloaders. �?� Die Notwendigkeit für einen Abgleich von Einstellungen zwischen Bootloader und Betriebssystem, zum Beispiel Ethernet-/IP-Konfiguration oder Display-Einstellungen, entfällt nahezu komplett. �?� Zur Konfiguration und Wartung des Systems startet der Bootloader anstelle des normalen Betriebssystems das Mini-Linux-System, das dem Benutzer die komplette Freiheit einer Linux-Umgebung zur Verfügung stellt: Eine komfortable Shell, Tools zur Flash-Verwaltung, HTTP-, FTP- und TFTP-Clients sowie nach Bedarf Test- oder Update-Applikationen, etc.

Gerade eine vollwertige Linux-Umgebung für Verwaltungs- und Wartungszwecke ermöglicht sehr einfach vielfältige Anwendungsmöglichkeiten, die noch weitaus flexibler sind als alles, was klassische BIOS-/Bootloader-Systeme bieten können. Da Linux ohnehin längst und zunehmend mehr Verbreitung als Betriebssystem für Anwendungszwecke im Embedded-Bereich findet, fallen die Treiber und Protokolle, die für ein solches Wartungssystem nötig oder gewünscht sind, quasi nebenbei ab und erfordern keine separate Entwicklung, Wartung und Tests mehr. Spezielle, kundeneigene Wartungs- und Update-Applikationen können auf ein vollwertiges Betriebssystem samt aller Treiber, Protokollstacks und auch grafischer Frameworks, wie etwa Qt oder Gnome, zurückgreifen, in nahezu beliebigen Programmier- und Skriptsprachen erstellt werden und auf beliebigen Wegen und Schnittstellen mit Anwendern, Technikern und/oder zentralen Wartungsrechnern kommunizieren.Durch den unter Linux bereits seit langem etablierten „kexec“-Mechanismus, der es erlaubt, aus einem bereits laufenden Linux heraus ein komplett neues Betriebssystem zu laden und zu starten, kann das Mini-Linux sogar als weiterer Bootloader benutzt werden, falls man Systeme aufsetzen möchte, die ggf. ein grafisches Bootmenü zur Auswahl bieten oder über ein Netzwerk booten sollen. Zudem ermöglicht dieser Ansatz es Entwicklern selbst, einfach stabile Wartungs- und Updateapplikationen zu implementieren, die auch vom optischen Design und Bedienkonzept der eigentlichen regulären Endanwendungen auf dem System entsprechen, ohne dass sie sich Spezialkenntnisse über Bootloader aneignen, diese gar selbst modifizieren oder angepasste Versionen bei externen Dienstleistern in Auftrag geben und in sämtlichen Fällen dennoch deutlich wahrnehmbare „Designbrüche“ in Kauf nehmen müssten. Sogar grafische Hilfesysteme inklusive Videoanleitungen sind auf diesem Weg auch für Wartung und Update einfach realisierbar.