Ob Accesspoints, Firewalls, Network Attached Storage, Navigationsgeräte oder Handys – auf unendlich vielen Geräten läuft Linux. Über das Warum, das Wie und über die Eigenschaften typischer Embedded-Architekturen klärt dieser Artikel auf.

Als Linus Torvalds 1991 als Hobby die Arbeit am Unix-artigen Betriebssystem Linux begann, legte er es nur für Intel-80386-Prozessoren aus. Es unterstützte nur AT-Festplatten und Linus selbst war der Meinung, dass es wohl nicht sehr portabel sei. Doch mit zunehmender Verbreitung folgten in den 90er Jahren erste Linux-Portierungen auf DECs Alpha, Suns Sparc und andere CPU-Familien.

Heute unterstützt Linux neben I-386 nicht nur viele andere CPUs wie ARM, AVR32 [1], Mips oder PowerPC, sondern auch Architekturen ohne Memory Management Unit (MMU), beispielsweise Motorola 68000 und Derivate sowie digitale Signalprozessoren wie die Blackfin-Familie [2] von Analog Devices. Linux hat sich zu einem portablen und skalierbaren Betriebssystem entwickelt, das auf fast jeder CPU zu Hause ist und auch durch die monolithische Architektur mit sehr guter Performance glänzt (siehe Kasten “Embedded-Linux-Hardware”).

Monolithisch bedeutet, dass alle Kernelkomponenten, Subsysteme und Treiber in einem Adressraum residieren und sich direkt aufrufen. Im Unterschied dazu lagern Microkernel alle weniger zentralen Komponenten in eigene Adressräume aus, was zwar das Speichschutz-Niveau erhöht, aber den Datenaustausch erschwert und zusätzliche Kontext-Switches erzwingt.

Der monolithische Aufbau macht Linux-System jedoch nicht groß und unbeweglich: Der Quellcode [3] bietet Konfigurationsmöglichkeiten, um nicht benötigte Subsysteme und Funktionen zu deaktivieren und so das System genau an den jeweiligen Verwendungszweck anzupassen.

Abbildung 1: NGW 100, ein Beispiel für ein Linux-Board mit AVR32-Prozessor, 140 MHz Takt und 32 MByte RAM.

Abbildung 2: Als weiteres Beispiel das Linux-Board Blackfin Stamp mit einem 533-MHz-DSP, aber ohne MMU.

Extrem einfach portierbar

Der modulare Aufbau sowie der hohe Anteil an C-Code sorgen dafür, dass sich Linux einfach auf beliebige Prozessoren portieren lässt, solange sie über mindestens 32 Bit breite Register verfügen. Mit Portierungen für Renesas H8 und Intel 8086 (ELKS, Embeddable Linux Kernel Subset) existieren sogar spezielle Portierungen für 16-Bit-Systeme. Derlei Anpassungen sind allerdings mit größerem Aufwand verbunden und eher selten.

Der Befehlssatz jeder Prozessorfamilie ist anders. Grob unterscheidet man zwischen komplexen Instruktionen (Cisc) und einfacheren, reduzierten (Risc). Durch den einfacheren Aufbau sind Risc-CPUs in der Regel günstiger zu fertigen und erreichen einfacher höhere Taktfrequenzen. Die einzelnen CPU-Familien sind sehr unterschiedlich (siehe Tabelle 1). Einige, etwa Intel x86, adressieren neben dem Speicher ihre I/O-Ports separat.

Neben der Breite der Register, die sich in der Regel zwischen 8 und 64 Bit bewegt und entscheidet, wie viel Daten der Prozessor mit einem Befehl bewegen und wie viel Speicher er adressieren kann, gibt es das Unterscheidungsmerkmal der Byte-Reihenfolge (Byte-Order oder Endianness).

Legt eine CPU Daten, die länger als 8 Bits sind, mit den höchstwertigen Bytes zuerst ab, bezeichnet man sie als Big-Endian. Prozessoren, die niederwertige Bytes vor den höherwertigen speichern, heißen Little-Endian. Einige Prozessoren beherrschen sogar beide Adressierungsarten.

Auch ohne MMU

Die für Schutz und Paging zuständige Memory Management Unit fehlt den kleinsten Embedded-CPUs aus Komplexitäts- und Kostengründen. Kernel und Anwendungen laufen bei ihnen nicht voneinander getrennt, Programmierfehler führen dann schnell zum Systemabsturz. Bei Geräten mit fest definierter Funktion und ohne die Möglichkeit externer Software-Installation, zum Beispiel Digitalkameras oder Drucker, ist eine solche Systemkonfiguration aber durchaus die Regel. Einige Prozessoren bieten statt einer MMU eine Memory Protection Unit (MPU), die zwar kein Paging und somit keinen virtuellen Speicher kennt, aber die einzelnen Anwendungen und den Kernel voreinander schützt.

Wegen des Miniaturisierungs- und Kostendrucks sind die meisten Embedded-Chips keine reinen CPUs, sondern fungieren als System-on-Chip (SoC). Sie beherbergen nicht nur den Rechenkern, sondern zugleich den Speichercontroller und eine Fülle von Peripherie-Anschlüssen, etwa serielle USB- und Grafik-Schnittstellen, Ethernet und Audio. Zur praktischen Funktion benötigen die meisten SoC nur noch Speicherbausteine (ROM, RAM) und ein wenig passive Interface-Beschaltung. Eine andere Spielart stellen FPGAs mit CPU-Kernen (etwa mit PowerPCs) dar sowie synthetisierbare CPU-Cores wie Microblaze und M32R, die es erlauben, Linux mit Zusatzlogik in FPGAs zu verwenden.

Linux, speziell in eingebetteten Geräten, bietet viele Vorteile – allen voran natürlich die Freiheit des Quellcode. Durch die Verfügbarkeit der Quellen und damit auch aller Treiber ist es in der Entwicklung eines Produkts möglich, beliebige Veränderungen an der Hardware vorzunehmen und Fehler zeitnah zu lokalisieren. Linux bietet einen ausgereiften Netzwerkstack samt Firewall, IPv6 und Bridge-Funktionalität. Viele fertige Treiber und die CPU-Unterstützung erlauben es, die Hardware für ein Produkt frei nach den Funktionsvorgaben zu wählen. Eine intelligente Wahl der Hardwarekomponenten reduziert auch die Produktionskosten. Dank der Erweiterungen RTAI und RT Linux lassen sich zudem Echtzeitanforderungen abdecken. (Dazu erscheint in einem der nächsten Linux-Magazine ein Artikel.)

Standardkonform und grafisch

Linux\’ Posix-Konformität erleichtert die Portierung bestehender Programme. Im Gegensatz zu proprietären Embedded-Systemen lassen sich Programme und Bibliotheken auch auf einem normalen Linux-Desktop beziehungsweise auf Workstations im Sinne von Rapid Prototyping entwickeln. Ein im Netzwerk transparentes GUI (zum Beispiel X11) erlaubt es, die Darstellung der Applikation komfortabel auf dem Zielgerät zu prüfen und erst in einer späteren Phase die Applikation nativ für das Zielsystem zu übersetzen.

Historisch gewachsen und speziell durch Neuentwicklungen im Embedded-Bereich existiert eine Reihe von Subsystemen zur Grafikdarstellung und Programmierung von Linux (siehe Abbildung 3). Die Palette reicht vom klassischen X-Window-System (X11), das auch auf Linux-Desktops Verwendung findet, bis hin zur direkten Pixel-Manipulation im Grafikspeicher (Frame Buffer, FB). Direct FB nimmt eine Art Mittelweg, der den Kernel-FB-Treiber um chipspezifische Hardwarebeschleunigung und Managementfunktionen erweitert.

Abbildung 3: Ein Embedded-Linux-System ist in Schichten aufgebaut. Auf die Hardware legt sich der Kernel, in dem auch die Treiber enthalten sind. Eine C-Bibliothek macht die Kernelfunktionen für die darüber liegenden Schichten nutzbar.

Auf den einzelnen Systemen bauen dann Userinterface-Bibliotheken auf, welche die Widgets der Applikationen implementieren. Zur Auswahl stehen mehrere C- und C++-Bibliotheken. Die bekanntesten Vertreter sind GTK+ des Gnome-Projekts [15] und QT [16] der Firma Trolltech (beide für X11 und FB), die Enlightenment Foundation Libraries (Evas, Edje) sowie Fox, Fltk und Wx Widgets. Die freie OpenGL-Implementierung Mesa [17] sorgt entweder im Rahmen von X11 oder einzeln als OpenGLES (OpenGL Embedded Systems) für 3D-Darstellung.

Aufbau in Schichten

Ein Linux-System besteht aus dem Linux-Kernel und Anwendungsprogrammen, die ein Dateisystem zur Verfügung stellt. Das Root-System residiert bei normalen Linux-PCs auf einer Festplattenpartition, auf Embedded-Systemen im ROM oder Flashspeicher. Als Dateisysteme kommen hier meist das Journaling Flash Filesystem in der Version 2 (JFFS2), das nur lesbare Squash-FS oder andere, komprimierte Standard-Dateisysteme zum Einsatz. Über die Verzeichnisstruktur entscheidet der Entwickler selbst, im einfachsten Fall reicht ein einzelnes Programm als Init-Prozess. In der Regel wird man aber ein minimales System, das aus Bibliotheken und einzelnen Programmen besteht, unterbringen.

Es bietet sich an, neben den ausgewachsenen GNU-Programmen, zum Beispiel »awk«, Bash, den Coreutils oder »sed«, speziell auf geringe Größe optimierte Programme zu verwenden, um eigenen Skripten eine gewohnte Unix-Umgebung zu bieten. Größenoptimierte Tools liefert zum einen das Busybox-Projekt als Paket, zum anderen gibt es sie einzeln, etwa als Embutils, Minised und so weiter.

Sprachen und Programme

Im Gegensatz zu einigen proprietären Systemen hat der Entwickler unter Embedded Linux die freie Wahl der Programmiersprache. Hier kann er nach den Projektvorgaben oder eigenem Belieben zwischen C, C++, Objective C, D, Ada, Pascal, Java und vielen anderen aussuchen.

Auch die aus dem Unix-Umfeld gewohnten Skriptsprachen, etwa Perl, Python, Ruby, PHP, Lua und so weiter, stehen weitgehend zur Verfügung. Einige benötigen lediglich etwas Hilfe bei der Cross-Kompilation. (Tipps dazu gibt ein demnächst im Linux-Magazin erscheinender Artikel).

Für Projekte, die auch Standardfunktionen enthalten, bietet es sich an, auf etablierte Linux-Software, Tools und Application Stacks zurückzugreifen, beispielsweise Apache, Samba, Squid, Asterisk oder Callweaver. Sie bieten bewährte Funktionalität und Qualität und beschleunigen die Programmierung. Der Entwickler kann sich so auf die eigenen Produktmerkmale konzentrieren.

Für die Übersetzung der Linux-Software steht der GCC, zum Debuggen der GDB bereit [18]. Beide sind den meisten Entwicklern bekannt und kommen auch für viele proprietäre Embedded-Systeme zum Einsatz. Der GNU-Debugger lässt sich remote über eine serielle Schnittstelle oder Ethernet verwenden.

In letzter Zeit kommt es in Mode, mit dem Emulator Qemu [19] komplette Embedded-Systeme zu virtualisieren. Auf diese Weise testen Entwickler ihre Programme und Systeme auch ohne Zielhardware, also direkt am Arbeitsplatz. Zum komfortablen Arbeiten bietet sich Eclipse an, für das einige kommerzielle Hersteller auch dedizierte Embedded-Linux-Plugins im Programm haben.

Bootloader und Funktion überwachen

Die im Desktop-Linux-Bereich üblichen Bootloader Lilo und Grub sind derzeit nur für x86-Systeme ausgelegt. Nur Grub wird in der kommenden Version 2 auch PowerPC und Sparc unterstützen. In Embedded-Geräten finden sich hauptsächlich der aus Ppcboot hervorgegangene Bootloader “Das U-Boot” [20], der sehr viele CPU-Architekturen unterstützt, und Redboot [21] aus dem von Red Hat gekauften Embedded-Betriebssystem E-Cos von Cygnus.

Neben klassischen Watchdogs, die nach Ablauf eines Timers das System neu starten, bieten sich Kexec und Kdump in eingebetteten Systemen an. Diese ermöglichen zum einen, ein Linux-System ohne Umweg über den Bootloader zu starten, und zum anderen ein komplettes Speicherabbild zu sichern. Beide Systeme machen es möglich, vor dem Neustart ein Fallback-System zu laden und so Diagnosemeldungen und Protokolle zur Fehlerbereinigung und Produktverbesserung – auch von Geräten im Produktiveinsatz – zu erstellen.

Fazit: Pinguin die beste Wahl

Rund um Linux findet sich eine aktive Embedded-Gemeinde, die komfortable Systemlösungen entwickelt und auch Support dafür anbietet. Die Linux-Lösungen reichen nicht nur an den Funktionsumfang kommerzieller Systeme heran, sondern übertreffen diese mit interessanten Features und Funktionen.

Ob O(1)- oder CFQ-Scheduler, die Native Posix Thread Library (NPTL), Futex oder Inotify – Linux skaliert hervorragend und API-Innovationen sind kurzfristig realisierbar. Jede Komponente des Systems, sogar den Kernel, detailliert anpassen zu können sowie die Entwicklung von Treibern für neue Hardwarekomponenten, das ist in der Embedded-Entwicklung wichtig und üblich – beste Voraussetzungen also, um gerade den Pinguin einzubetten. (hej/jk)