© urbanhearts, Fotolia

Kaum ein Embedded-Entwickler schneidert die unteren Betriebssystem-Komponenten selbst zusammen. Die meisten greifen auf fertige Distributionen zurück – freilich nicht auf Debian, Suse, Fedora & Co., sondern auf Spezialkollektionen.

Distributionen für Desktop und Server wie Debian, Ubuntu oder Suse eignen sich für eingebettete Systeme nur bedingt, da sie nur die 32- und 64-Bit-CPUs von Intel und AMD, höchstens noch PowerPC unterstützen. Lediglich Debian läuft auch auf typischen Embedded-CPUs wie ARM und Mips. Diese Distributionen geben relativ strikt das System vor und kommen mit der vergleichsweise großen Glibc sowie einem Sys-V-Init, das nicht durch besonders kurze Bootzeiten glänzt.

Bei eingebetteten Systemen installiert nicht ein Anwender das Betriebssystem. Es kommt nur darauf an, dass das Gerät, zum Beispiel der Accesspoint, die Settop-Box, Informationsanzeigen oder das Handy, nach dem Auspacken sofort einsatzbereit ist. Distributionseigene Installations- und Setup-Tools würden nur wertvollen Speicher belegen.

Die Software im Flashspeicher besteht stattdessen aus einem maßgeschneiderten System, das nur die gewünschte Funktionalität bietet, mit kleinen C-Bibliotheken und nur mit den nötigsten Abhängigkeiten übersetzt. Einzig die Möglichkeit, gelegentlich ein Firmware-Update beispielsweise über ein Webfrontend vorzunehmen, ist für einen Teil der Geräte das technische Zugeständnis an die Softwarewartung.

Kein Linux from Scratch

Um Entwicklern die Arbeit zu erleichtern und Kosten zu sparen, erstellt man eingebettete Systeme nicht jedes Mal von Grund auf neu. Dafür sind Embedded-Linux-Distributionen von Firmen wie Montavista [1], Windriver [2] oder Timesys [3] im Angebot. Zudem empfehlen sich für die jeweilige Ziel-CPU übersetzte Open-Source-Buildsysteme wie Buildroot [4], Open Embedded [5] oder T2 SDE [6].

Fertige Lösungen reduzieren die Entwicklungszeit und bringen teilweise Frameworks zur Applikationsentwicklung sowie Eclipse-Schnittstellen mit. Der Nachteil: Der Entwickler ist mit diesen Produkten oftmals wieder auf vorübersetzte Pakete einer Firma angewiesen oder bindet sich bei herstellerspezifischen Frameworks langfristig. Als flexibler erweisen sich Open-Source-Lösungen, die mit Makefiles oder ähnlichen Buildsystemen nach eigenen Vorgaben maßschneidern.

Buildroot

Das im U-Clibc-Projekt entstandene Buildsystem [4] übersetzt automatisiert Systeme auf Basis der U-Clibc. Mit rund 250 Paketen und dem Fokus auf der kleinen C-Bibliothek U-Clibc ist Buildroot übersichtlich und für viele Embedded-Projekte ausreichend. Das Buildsystem hat U-Clibc in Form von Makefiles implementiert. Vieles an der Handhabung von Buildroot erinnert an den Linux-Kernel: Wer das System von der Projektseite heruntergeladen und entpackt hat, konfiguriert es mit »make config« beziehungsweise »make menuconfig« (siehe Abbildung 1). Mit dem gewohnten »make« startet die Übersetzung.

Die Makefiles laden dann den Code aus den einzelnen Quellen und übersetzen ihn. Der Befehl »make source« lädt alle erforderlich Quellen vorab. Als Resultat liefert Buildroot fertige Dateisysteme, die die konfigurierten Komponenten erhalten.

Abbildung 1: Der Kernel lässt grüßen: Die Konfiguration von Buildroot erfolgt per »make config« oder wie hier gezeigt mit »make menuconfig«.

Abbildung 2: Ein eigenes Programm hilft die verschiedenen Einstellungen für T2 SDE auswählen.

Open Embedded

Das 2004 aus mehreren PDA-Distributionen hervorgegangene Projekt Open Embedded (OE, [5]) kann neben U-Clibc- auch Glibc-basierte Systeme cross-kompilieren. Den Buildvorgang übernimmt das im Rahmen von Open Embedded entwickelte Programm »bitbake«. Vor dem Einsatz ist es ähnlich wie »make« zu installieren.

Das Einrichten von Bitbake gestaltet sich aufwändiger; über Details informiert [5]. Im Wesentlichen passt der Administrator die Datei »build/conf/local.conf« an. Das Programm »bitbake« – zusammen mit dem Paketsatz aufgerufen – führt den eigentlichen Übersetzungsvorgang aus.

bitbake task-base

übersetzt die Basispakete, »bitbake world« kompiliert alle.

Da OE aus PDA-Distributionen hervorgegangen ist, stehen einige auf OE basierende Linux-Versionen für handelsübliche PDAs bereit. Darüber hinaus setzt FIC (First International Computer, [7]) OE im Rahmen des Open-Moko-Neo-Handy-Projekts ein.

T2 System Development Environment

Der Baukasten T2 SDE (System Development Environment, [6]) blickt ebenfalls auf 2004 als Geburtsjahr zurück. Das Projekt begann als eine Abspaltung des Distribution Build Kit von Rock Linux [8]. T2 SDE unterstützt die C-Bibliotheken Dietlibc, U-Clibc, Glibc sowie den Eglibc-Fork der Glibc und übersetzt daher Systeme für die meisten von Linux unterstützen Architekturen. Derzeit cross-kompiliert T2 SDE rund 50 Prozent der über 3000 Pakete. Alle anderen lassen sich nativ übersetzen, zumeist solche, die sowieso selten Teil eines Embedded-Systems sind.

T2 SDE ist zum großen Teil in Form von Shellskripten realisiert und definiert die Pakete als Key-Value-Metadaten samt Patches. Das System erlaubt es, die Konfigurationen für die verschiedenen Übersetzungsziele, die so genannten Targets, vom eigentlichen Build-System separat aufzubewahren. T2 SDE pflegt sie dann in einem Versions-Kontrollsystem. Dass T2 ein umfangreiches System Development Environment (SDE) ist, macht sich im inzwischen auf 200 Seiten angewachsenen Handbuch bemerkbar.

T2 SDE in der Praxis

Das T2-SDE-Skript »./scripts/Config« dient der Konfiguration. Danach stellt der Befehl

./scripts/Build-Target

das System zusammen (Abbildung 3).Hierzu lädt es die Quellen von den Projektseiten und übersetzt sie anschließend automatisch. Es ist außerdem möglich, die benötigten Quellen vorab zu laden:

./scripts/Download -required

T2 SDE erzeugt als Endresultate zum einen Dateisysteme für ROM, Flashspeicher oder zum Booten über ein Netzwerk, zum anderen installierbare ISO-Images für normale Systeme mit Benutzer-Installation.

Neben der Sandbox-Umgebung, die während des Buildprozesses gelesene und geschriebene Dateien protokolliert, kennt T2 SDE so genannte Wrapper-Programme. Sie gestatten es, Programmargumente automatisch zu transformieren, etwa um in jeden Compiler-Aufruf verlässlich und konsistent die Architektur-Optionen einzufügen oder Pfade automatisch zu korrigieren, ohne diverse Makefiles einzelner Open-Source-Projekte patchen zu müssen.

Abbildung 3: T2-SDE-Skripte stellen entsprechend der Zielplattform das System zusammen.

Fazit

Die vorgestellten proprietären und Open-Source-Systeme für die Entwicklung von Embedded Linux decken die wichtigen Schritte der Softwareentwicklung ab.

Anders als herkömmliche Linux-Distributionen für den Desktop oder Server unterstützen sie die in den Embedded-Geräten üblichen CPU-Typen und erlauben es dem Entwickler, genauer angepasste Systeme automatisiert zusammenzustellen.

Den Programmierern, die sich nicht auf vorkompilierte Systeme der kommerziellen Anbieter festlegen wollen, bieten die Open-Source-Lösungen eine große Zukunfts- und Investitionssicherheit, da sie selbst künftige Versionen einpflegen und das System für neue CPU-Architekturen übersetzen können und auch dürfen. (hej)