Download Tagungsband.qxd

M. Fuchs / M. Sturm / D. Lippik
Speicheradresse ist demnach prinzipiell egal, solange der Bootloader sie kennt. Zur
Laufzeit wird der Kernel im dynamischen Speicher ausgeführt, sodass er komprimiert
gespeichert werden kann. In der Regel wird er in Form des so genannten zImages verwendet, dass beim Kompilieren automatisch erstellt wird. Das Archiv ist selbstentpackend und enthält den Kernel in komprimierter Form. Bevor es durch den Bootloader
gestartet wird, kopiert dieser es vom statischen in den dynamischen Speicher. Auch der
Kernel muss, genau wie der Bootloader, auf die Zielhardware portiert werden, insofern
sie nicht bereits unterstützt wird. Dies ist sehr zeitaufwendig und verlangt vom
Entwickler ein sehr großes Know-How über den Aufbau und die Funktionsweise des
Kernels. Der Aufwand dafür ist umso größer, je weniger verwendeten
Hardwarekomponenten durch Treiber bereits unterstützt werden. Aber auch wenn eine
Portierung für die Hardwareplattform vorhanden ist, gestaltet sich die Konfiguration des
Kernels viel schwieriger als beim Bootloader. Letztlich hängt die Größe des zImages sehr
stark von der gewählten Konfiguration ab. Die Größe des Kernels für die easyToWebARM-Platine beträgt mit TCP/IP-Stack ca. 1 MiB.
Für die Implementierung des Root-Dateisystems existieren verschiedene Möglichkeiten.
Zum einen ist das Speichern in unkomprimierter Form möglich. Meist werden aber die
Kernkomponenten eines einmal erstellten Root-Dateisystems nicht verändert, sodass es
durchaus sinnvoll ist, es komprimiert statisch zu speichern und es beim Systemstart in
den dynamischen Speicher zu entpacken. Speziell dazu unterstützt der Kernel die
Verwendung eines Initial-Ramdisk-Images. Wenn der Bootloader dem Kernel die Position
des komprimierten Root-Dateisystems mitteilt, ist dieser in der Lage, es automatisch zu
entpacken und, wie in Abb. 1 bereits dargestellt, den init-Prozess zu starten. Vernachlässigt man die Zeit für eine mögliche Portierung des Kernels und des Bootloaders, so ist
das Erstellen eines Root-Dateisystems der aufwändigste Prozess bei der Implementierung eines Embedded-Linux-Systems. Nichtsdestotrotz kommt diesem Arbeitsschritt
eine hohe Bedeutung zu, weil er den Speicherbedarf des Gesamtsystems maßgeblich
beeinflusst. In [4] wird sehr detailliert beschrieben, wie ein Root-Dateisystem Schritt für
Schritt erstellt werden kann. Als Alternative für diese so genannte „From-Sratch“Variante bietet sich die Verwendung einer Embedded-Linux-Distribution an, die entweder Teil eines Linux-BSP ist, die aber auch im Internet als Open-Source-Lösung verfügbar ist. Ein Beispiel für eine solche Distribution ist Embedded Debian. Meist muss der
Entwickler die Distribution aber entsprechend den Anforderungen anpassen. Das für die
easyToWeb-ARM-Platine exemplarisch implementierte Root-Dateisystem hat eine Größe
von ca. 3.5 MiB und das daraus erstellte Initial-Ramsik-Image ca. 1.6 MiB.
Falls das Root-Dateisystem zur Laufzeit im dynamischen Speicher ausgeführt wird, gibt
es zunächst keine Möglichkeit, Daten, wie zum Beispiel Messwerte, statisch zu speichern. Eine Lösung ist die Verwendung eines zusätzlichen Dateisystems auf einer
Partition des statischen Speichers. Dieses Dateisystem kann dann in das RootDateisystem eingebunden werden. Ein für Flash-Speicher geeignetes Dateisystem ist
JFFS2.
36
Tagungsband 8. Nachwuchswissenschaftlerkonferenz FH Jena