250
4 Systemsoftware
Um diesen doppelten Speicherbedarf zu vermeiden, wurden verschiedene Techniken zur direkten Ausführung von Programmcode aus Festwertspeichern (engl.
Execute-in-Place (XiP)) entwickelt. Diese Technik ist bei kleineren mikrocontrollerbasierten Systemen üblich, bringt aber einige Probleme mit sich. Zum Einen muss
der nichtflüchtige Speicher, der das auszuführende Programm beinhaltet, Zugriffe
mit Byte- oder Wort-Granularität unterstützen. Zum Anderen werden ausführbare
Programme meist in einem Datenformat wie ELF gespeichert, das Metainformationen (z.B. Symbole für Debugging) beinhaltet und vor der Ausführung zunächst
gelinkt werden muss.
Die Unterstützung für XiP-Techniken wird meist als eigenes Dateisystem implementiert, z.B. beim Advanced XiP Filesystem (AXFS) [42], das zusätzlich die
Kompression von nur-lese-Daten erlaubt. Die Verwendung von XiP ist besonders
für den Linux-Kern selbst nützlich, da dieser normalerweise eine große Menge an
nicht auslagerbarem Speicher belegt. Die Ausführung des Kerns direkt aus dem
Flash lässt entsprechend mehr Hauptspeicher für Benutzerprozesse übrig. XiP für
Benutzerprozesse selbst ist weniger nützlich, da der Linux-Kern in Systemen mit virtuellem Speicher jeweils nur die benötigten Speicherseiten einer ausführbaren Datei
in den Hauptspeicher lädt. Dadurch wird der RAM-Bedarf für diese Programme
automatisch minimiert.
Die Verfügbarkeit von Flash-Speicher mit byte- oder wortgranularem Zugriff,
wie für XiP benötigt, ist für aktuelle Systeme zumeist eine Kostenfrage. Die üblicherweise verwendete NAND-Flash-Technologie, die z.B. in SD-Speicherkarten und
SSDs zum Einsatz kommt, ist kostengünstig, erlaubt aber jeweils nur blockweisen
Zugriff, ähnlich wie konventionelle Festplatten. NOR-Flash hingegen ist eine Technologie, die wahlfreien Zugriff erlaubt und die sich damit für die Implementierung
von XiP-Techniken eignet. Allerdings ist NOR-Flash meist eine Größenordnung
teurer als NAND-Flash und zudem langsamer als RAM-basierter Hauptspeicher.
Entsprechend kann es für viele Systeme eine sinnvolle Entwurfsentscheidung sein,
einen größeren RAM-Speicher anstelle von NOR-Flash-basierten XiP-Techniken zu
verwenden.
4.4.5 uClinux – Linux für Systeme ohne MMU
Eine weitere Ressourcenbeschränkung findet sich schließlich in kleineren mikrocontrollerbasierten Systemen wie der Cortex-M-Serie von ARM. Die Prozessorkerne
in diesen Systemen wurden für den Einsatz mit typischen Echtzeitbetriebssystemen
entwickelt, die oft der einfachen Struktur eines Bibliotheks-Betriebssystems entsprechen, wie für Erika (siehe Seite 240) beschrieben. Daher fehlt diesen Mikrocontrollern wichtige Hardware zur Unterstützung von Betriebssystemen, speziell eine
Speicherverwaltungseinheit (engl. memory management unit (MMU), siehe Anhang
C). Mit einigen Einschränkungen ist es aber möglich, Linux auf Mikrocontrollern mit
ausreichend großem Speicher und vergleichsweise hohen Taktfrequenzen zu nutzen.
Entsprechend wurde uClinux als Abwandlung des Linux-Kerns für Systeme ohne
4 Systemsoftware
Um diesen doppelten Speicherbedarf zu vermeiden, wurden verschiedene Techniken zur direkten Ausführung von Programmcode aus Festwertspeichern (engl.
Execute-in-Place (XiP)) entwickelt. Diese Technik ist bei kleineren mikrocontrollerbasierten Systemen üblich, bringt aber einige Probleme mit sich. Zum Einen muss
der nichtflüchtige Speicher, der das auszuführende Programm beinhaltet, Zugriffe
mit Byte- oder Wort-Granularität unterstützen. Zum Anderen werden ausführbare
Programme meist in einem Datenformat wie ELF gespeichert, das Metainformationen (z.B. Symbole für Debugging) beinhaltet und vor der Ausführung zunächst
gelinkt werden muss.
Die Unterstützung für XiP-Techniken wird meist als eigenes Dateisystem implementiert, z.B. beim Advanced XiP Filesystem (AXFS) [42], das zusätzlich die
Kompression von nur-lese-Daten erlaubt. Die Verwendung von XiP ist besonders
für den Linux-Kern selbst nützlich, da dieser normalerweise eine große Menge an
nicht auslagerbarem Speicher belegt. Die Ausführung des Kerns direkt aus dem
Flash lässt entsprechend mehr Hauptspeicher für Benutzerprozesse übrig. XiP für
Benutzerprozesse selbst ist weniger nützlich, da der Linux-Kern in Systemen mit virtuellem Speicher jeweils nur die benötigten Speicherseiten einer ausführbaren Datei
in den Hauptspeicher lädt. Dadurch wird der RAM-Bedarf für diese Programme
automatisch minimiert.
Die Verfügbarkeit von Flash-Speicher mit byte- oder wortgranularem Zugriff,
wie für XiP benötigt, ist für aktuelle Systeme zumeist eine Kostenfrage. Die üblicherweise verwendete NAND-Flash-Technologie, die z.B. in SD-Speicherkarten und
SSDs zum Einsatz kommt, ist kostengünstig, erlaubt aber jeweils nur blockweisen
Zugriff, ähnlich wie konventionelle Festplatten. NOR-Flash hingegen ist eine Technologie, die wahlfreien Zugriff erlaubt und die sich damit für die Implementierung
von XiP-Techniken eignet. Allerdings ist NOR-Flash meist eine Größenordnung
teurer als NAND-Flash und zudem langsamer als RAM-basierter Hauptspeicher.
Entsprechend kann es für viele Systeme eine sinnvolle Entwurfsentscheidung sein,
einen größeren RAM-Speicher anstelle von NOR-Flash-basierten XiP-Techniken zu
verwenden.
4.4.5 uClinux – Linux für Systeme ohne MMU
Eine weitere Ressourcenbeschränkung findet sich schließlich in kleineren mikrocontrollerbasierten Systemen wie der Cortex-M-Serie von ARM. Die Prozessorkerne
in diesen Systemen wurden für den Einsatz mit typischen Echtzeitbetriebssystemen
entwickelt, die oft der einfachen Struktur eines Bibliotheks-Betriebssystems entsprechen, wie für Erika (siehe Seite 240) beschrieben. Daher fehlt diesen Mikrocontrollern wichtige Hardware zur Unterstützung von Betriebssystemen, speziell eine
Speicherverwaltungseinheit (engl. memory management unit (MMU), siehe Anhang
C). Mit einigen Einschränkungen ist es aber möglich, Linux auf Mikrocontrollern mit
ausreichend großem Speicher und vergleichsweise hohen Taktfrequenzen zu nutzen.
Entsprechend wurde uClinux als Abwandlung des Linux-Kerns für Systeme ohne