Embedded Linux
# Embedded Linux

Als Embedded Linux (deutsch: „eingebettetes Linux“) bezeichnet man ein eingebettetes System mit einem auf dem Linux-Kernel basierenden Betriebssystem. Dies impliziert nicht den Gebrauch bestimmter („Mindest“-)Bibliotheken oder Anwendungen mit diesem Kernel.

## Arten

Embedded-Linux-Systeme werden normalerweise aufgrund ihrer verschiedenen Systemeigenschaften und nicht aufgrund ihrer Einsatzorte eingeteilt. Das können u. a. die Skalierbarkeit, die Unterstützung für bestimmte Prozessoren, der Stromverbrauch, das Zeitverhalten (Echtzeitfähigkeit), der Grad der möglichen Nutzerinteraktionen oder andere wesentliche Faktoren sein.

## Aufbau

### Allgemeiner Aufbau

Ein Embedded-Linux-System ist grob in drei Schichten unterteilbar. Die unterste Schicht wird durch die zugrunde liegende Hardware gestellt. Hierbei wird von den Treibern der folgenden Schicht so gut wie alles an Hardware abgedeckt, was ein 32-Bit Prozessor bietet. Die zweite Schicht besteht aus dem eigentlichen Kernel, welcher wieder dreifach geschichtet ist. Die unterste Schicht hiervon ist eine Low-Level-Schnittstelle, welche eine erste Hardware-Abstraktion mit kleinem API für darüberliegende Schichten bietet. Danach folgen kleine Module zur (Vorab-)Interpretation von strukturierten Daten aus den Filesystem- und Netzwerkprotokollen, welche der Kernel empfängt und sendet. An dieser Stelle können schon erste Weichen zu Standards auf höheren Schichten gestellt werden. Die letzte Kernelschicht wird auch High-Level-Abstraction-Layer genannt und ist schon bei vielen Linux-Derivaten und Unixen gleich oder ähnlich. Diese Schicht ist bis auf Ausnahmen hardwareunabhängig; hier werden z. B. Prozesse, Threads, Dateien, Sockets und Signale generiert bzw. verarbeitet. In der letzten Schicht des Embedded-Linux-Systems sind verschiedene C-Bibliotheken (oder speziell für eingebettete Systeme speicheroptimierte Ersatzbibliotheken) und auch die Anwendungssoftware angesiedelt. Die Bibliotheken werden meist dynamisch mit den Anwendungen verlinkt.

### Entwicklungsumgebungen

Bei der Entwicklung von Embedded-Linux-Systemen kann grob zwischen Cross-Development und Standalone Setups (also Nicht-Cross-Development) unterschieden werden. Cross-Development lässt sich außerdem in die beiden Untergruppen Linked Setup und Removable Storage Setup unterteilen. Ein Beispiel für Cross-Development ist OpenWrt.

Linked Setup ist die Entwicklungsumgebung, die das klassische Cross-Development darstellt. Man benutzt ein Host-System, auf dem eine größere IDE (Integrated Development Environment) laufen kann, zum Implementieren des eigentlichen Quellcodes. Dieser Code wird über die Links (daher der Name Linked Setup) auf das Target übertragen, auf dem sich dann ein Bootloader, der Kernel und ein (minimales) Rootfilesystem oder ein Networkfilesystem befinden. Die Links sind serielle Verbindungen wie RS232 oder aber Ethernet oder beides zusammen. Aufgrund der höheren Geschwindigkeit wird häufig Ethernet für den Upload des Codes auf das Target benutzt und die Verbindung des RS232 für die Rückrichtung zum Debugging mit geringerem Datenaufkommen.

Der Aufbau des Removable Storage Setup lehnt sich grundsätzlich an den des Linked Setup an, jedoch wird bei der Entwicklung ein Zwischenspeicher (Storage) zur Verfügung gestellt, auf dem der zweite Bootloader, der Kernel sowie das Rootfilesystem vom Host abgelegt werden. Auf dem Target befindet sich vorerst lediglich der erste Bootloader, welcher danach den Rest des Systems vom Zwischenspeicher bootet.

Bei der Entwicklung mit sogenanntem Standalone Setup verzichtet man auf eine große, separate Entwicklungsplattform zu Gunsten eines alleinstehenden, entwicklungsfähigen Targets. Offensichtlich deutet dies auf eine gewisse Größe des Targets hin, denn die Entwicklungsumgebung liegt nun auf ihm selbst. Bei gegebener Hardware ist diese Möglichkeit populär, da dann alle zu entwickelnden Komponenten von vornherein in ihrer natürlichen Arbeitsumgebung laufen.

### Verwendete Hardware

In Embedded-Linux-Systemen kann eine Vielzahl unterschiedlicher Hardware Anwendung finden. Dies gilt nicht nur, weil sich schließlich bei noch nicht unterstützter Hardware auch Treiber from scratch (also von Grund auf selbst) schreiben lassen oder weil selbst fertige off the peg Distributionen schon einen Großteil der potentiellen Hardware ohne Anpassungen nutzen können, sondern weil schlicht eine überwältigende Mehrzahl der potentiell zur Verfügung stehenden Hardware von Linux unterstützt wird. John Lombardo schrieb im Jahr 2001:

    Your application will determine what type of I/O devices you need. Fortunately, a veritable army of Linux programmers have had years to develop and refine the necessary device drivers to support nearly any hardware imaginable.

Diese Aussage bezog sich lediglich auf verwendbare Ein- und Ausgabegeräte beziehungsweise Schnittstellen, jedoch kann man wohl mit gutem Gewissen behaupten, dass dies mit Ausnahme der Prozessoren auf den allergrößten Teil der Hardware anwendbar ist. An dieser Stelle werden die unterstützten Hardwarekomponenten ohne Anspruch auf Vollständigkeit genannt. Wegen Lombardos Aussage kann die Betrachtung der restlichen (also Nicht-CPU-) Hardware wegfallen und somit der Schwerpunkt auf die Prozessorfamilien gelegt werden. Nichtgenannte Prozessortypen werden nicht automatisch nicht unterstützt, sondern schlicht seltener verwendet und stellen meist Einzellösungen dar.

**x86**

Eine sehr häufig verwendete Prozessorfamilie ist die x86. Die Linuxunterstützung beginnt prinzipiell mit allen Versionen des 386ers. Wie schon weiter oben erwähnt, wird durch das Projekt ELKS (Embedded Linux Kernel Subset) auch die Verwendbarkeit von Linux auf 286ern sichergestellt, um Embedded-Linux-Systeme besser an die Größenerfordernisse von kleineren Eingebetteten Systemen anzupassen. Nach dem 486er wurden auch Intels Pentiums sowie die entsprechenden Fabrikate anderer Hersteller unterstützt, was technologisch und historisch gesehen den Sprung auf superskalare CISC-Prozessoren für Linux darstellte. Insgesamt kann man feststellen, dass der Familie der x86er eine nahezu lückenlose Unterstützung durch Linux erfährt, was jedoch nicht vordergründig aus dem Embedded-Bereich herrührt, sondern von Workstations und Desktop-PCs. Damit lässt sich begründen, warum die Reihe der x86er trotz ihrer breiten Linuxkompatibilität im traditionellen Umfeld der Eingebetteten Systeme nur einen kleinen Anteil an der verwendeten Architektur stellt. Häufiger finden ARM, MIPS sowie PowerPC wegen geringerer Komplexität und günstigerer Kosten den Weg in die Produktion.

**ARM**

Die ARM-Architektur (Advanced RISC Machine) sowie die des StrongARM sind im Bereich der Eingebetteten Systeme beliebte Prozessoren und zwar in erster Linie auf Grund ihrer geringen Stromaufnahme. Daher kamen sie schon früh für Embedded-Linux-Systeme in Betracht und wurden unterstützt. Obwohl ARM auch eine Firma ist, werden von ihr nur die Lizenzen zum Bau ihrer Prozessoren vertrieben. Alle bekannten Prozessorhersteller sind Lizenznehmer bei/für ARM. Die Projekte RTAI und RTLinux von der Firma FSMLabs (es werden hier eine freie sowie eine kommerzielle Variante angeboten) haben sich spezifischer mit der Nutzung von ARM-Architekturen mit Hinblick auf harte Echtzeitanwendungen für Embedded Linux befasst. Die Tatsache, dass es sich hierbei um militärische End-Anwendungen mit sehr kostenintensiven Produkten handelt, zeigt übrigens äußerst deutlich, dass man sehr hohe Erwartungen an Embedded Linux als hartes Echtzeitbetriebssystem stellt und nicht von einem großen Kostenaufwand zurückschreckt. Als zukunftsweisend ist zu erwähnen, dass in den Embedded-Linux-Systemen auch häufig schon die Java-Coprozessoren der ARMs verwendet werden können.

**ETRAX CRIS**

ETRAX CRIS bezeichnet eine Prozessorfamilie von Axis Communications. Dabei steht ETRAX für Ethernet, Token Ring, Achse (engl. AXis), auch wenn der Begriff nicht länger korrekt ist, weil der Support für Token Ring bei den jüngeren Modellen entfernt wurde. Diese Prozessoren basieren auf dem Code Reduced Instruction Set (CRIS). Aktuelle Modelle sind ETRAX 100LX mit 100 MHz 32 bit RISC CPU und ETRAX 200FS mit 200 MHz 32 bit RISC CPU, welche über einen Kryptographie-Beschleuniger und ein über Microcode steuerbaren I/O-Prozessor verfügt. ETRAX CPUs sind für den Einsatz unter Embedded Linux optimiert und eignen sich durch ihre hohe Konfigurierbarkeit hervorragend zur Netzwerkintegration elektronischer Geräte. Der italienische Hersteller ACME Systems hat auf Basis des 100LX einen voll funktionsfähigen Linux-Einplatinen-Computer mit LAN und USB unter dem Namen Fox Board auf den Markt gebracht.

**PowerPC**

Für die Einbindung des PowerPC wird ähnlich ambitionierte Arbeit betrieben wie bei der ARM-Architektur. Dieses Akronym besteht aus zwei Teilen: Power ist die Abkürzung für Performance optimization with enhanced RISC, also in etwa Leistungsoptimierung durch erweitertes RISC, und PC steht hierbei für Performance Chip, also Hochleistungs-Chip. In einigen Fällen wird diese Architektur auch AIM genannt, was aus den Anfangsbuchstaben der Entwicklerfirmen Apple, IBM und Motorola zusammengesetzt wird. Es existieren 32-Bit- und 64-Bit-Versionen, welche gleichermaßen durch Linux unterstützt werden. Insbesondere sind auch hier die Echtzeit-Projekte RTAI und RTLinux federführend um den PowerPC in harten Echtzeitumgebungen unter einem Linuxbetriebssystem zu verwenden sowie die Java-Unterstützung sicherzustellen.

**MIPS**

Obgleich die MIPS-Architektur, Microprocessor without interlocked pipeline stages bedeutet so viel wie Mikroprozessor ohne Pipeline-Sperren, sich ebenfalls durch geringere Komplexität und damit geringere Kosten auszeichnet, ist die Linuxunterstützung hierfür noch nicht ausgereift. Es mag eine Frage der Zeit sein, bis die 32-Bit oder die 64-Bit Version in Embedded-Linux-Systemen Einzug hält; momentan beschränkt sich die Unterstützung auf eine Portierung einzelner Distributionen, da der Befehlssatz von Lizenznehmer zu Lizenznehmer mitunter sehr stark variiert. Da die MIPS-Architektur ursprünglich im Workstation- und Serverbereich „groß geworden“ ist, häufig auf ein spezielles Motherboard zugeschnitten war und die Java-Unterstützung nicht sichergestellt war, ist der Einsatz als Grundlage eines Embedded-Linux-Systems nicht unumstritten beziehungsweise zumindest aufwändig und führt zu proprietären Lösungen.

**Hitachi SuperH**

Hitachi SuperH ist eine RISC-artige Prozessorarchitektur, welche ursprünglich von Hitachi entwickelt und später auch in Lizenz gebaut wurde. Sie wird dank ihrer „Bandbreite“ von 8 bis 64 Bit (eigentlich nur 32 und 64 Bit; 8-Bit und 16-Bit sind die ähnlichen Vorgänger) häufig in Eingebetteten Systemen genutzt. Der Einsatz von Linux auf dieser Architektur wurde allerdings erst nach der Entwicklung einer Version mit MMU beziehungsweise nach der Anpassung von μCLinux an MMU-lose Prozessoren häufiger. Ähnliches lässt sich für die Adressbreite sagen: Linux fand zunächst nur auf den 32-Bit-Versionen Anwendung, erst nach der Entwicklung von μCLinux auch auf 16-Bit breiten Datenpfaden. Für diese Architektur spricht, dass sie wenig Strom verbraucht und relativ günstig herzustellen ist.

**Motorola 68000**

Die 68000er-Familie von Motorola, auch m68k genannt, wird mit 8, 16 und 32 Bit als CISC-Prozessor eines Embedded-Linux-Systems mit Echtzeitanwendungen verwendet. In Nicht-Linux-Systemen fand sie ebenfalls oft Verwendung, wenn Echtzeitfähigkeit gefordert war; hier wurden oftmals zusätzlich mathematische Coprozessoren verwandt. Zu dieser Architektur ist jedoch zu sagen, dass Linux für sie momentan nur geringen Support bietet, was auch an der fehlenden Java-Unterstützung liegen kann.

**Andere Hardwarekomponenten**

Wie schon oben erwähnt, ist die Linux-Kompatibilität für unterschiedlichste Hardware quasi garantiert. Dies trifft sowohl für Busse, Schnittstellen, Speicher und Netzwerke als auch für I/O- und andere Peripheriegeräte zu. Generell betrifft diese Formulierung zunächst die konventionellen Geräte. Aber selbst wenn noch keine Unterstützung für neuere Hardware wie zum Beispiel Satellitenempfänger vorliegt, dann bedeutet es einen verhältnismäßig geringen zeitlichen Aufwand, eigene Treiber zu implementieren.

Erwähnenswert ist ferner, dass angebotene Treiber häufig Hardwaremonitoring unterstützen. Dies geschieht entweder über Watchdogs in der Software oder als separates Hardwareteil oder über die Interpretation besonderer Monitoringsignale der jeweiligen Hardware selbst.

