Eigene Programmpakete oder Installationsimages für kleine digitale Begleiter basteln ist kompliziert und fehlerträchtig. Open Embedded hilft den Besitzern von Zaurus-PDAs, I-PAQs und Simpads umfassend.

PDAs verwalten Termine und Adressen, verarbeiten Office-Dokumente, spielen MP3s und Videos vor und verbinden sich mit dem Internet. Die meisten der persönlichen digitalen Assistenten laufen mit proprietären Betriebssystemen – einige jedoch mit einem eingebetteten Linux. Dank der Arbeit zweier Community-Projekte stehen sich die Pinguin-Pfleger keineswegs schlechter als die anderen. OPIE (Open Palmtop Integrated Environment,[1] und[2]) benutzt zur Grafikausgabe den Videoframebuffer von Linux und fußt auf Qt Embedded. GPE (GPE Palmtop Environment,[3]) setzt auf X11 und GTK+.

Punkte gegenüber anderen PDA-Betriebssystemen sammeln mobile Linuxe mit der von großen Rechnern ererbten Softwarevielfalt. Wer seinen PDA zum Schweizer Taschenmesser eines Systemadmininstrators mit Tools wie Minicom, SSH, Nessus oder Ethereal ausbauen will oder wer auch in der Bahn Doom oder Monkey Island mit der Scumm-VM daddeln muss oder zu Hause einen Strom sparenden ADSL-Router mit Webinterface braucht, den wird Embedded Linux nicht enttäuschen.

Kreuz und quer

Für die ohnehin mit Linux ausgelieferten Zaurus-PDAs von Sharp (Abbildung 1), für Hewlett-Packards I-PAQ-Modellreihe (Abbildung 2) und für das Simpad von Siemens gibt es gut gepflegte Distributionen: Open Zaurus[4], Familiar (I-PAQ,[5]) und Open Simpad[6]. Auf den jeweiligen Projektseiten liegen so genannte Flashimages zur erstmaligen Installation zum Download, meist mehrere Ausführungen unterschiedlichen Umfangs der vorinstallierten Programme.

An gleicher Stelle lagert eine Vielzahl fertiger Programmpakete in Form von IPK-Dateien, die der Itsy Package Manager IPKG, eine schlanke Abwandlung von Debians DPKG, zu verarbeiten weiß.

Illusion: Kompilieren auf dem PDA

Problematisch wird’s, sobald man ein distributionsfremdes Linux-Programm auf dem mobilen Begleiter installieren will oder fehlerhafte Treibermodule oder gar den ganzen Kernel ersetzen muss. Denn PDAs eignen sich mit ihren knapp bemessenen Ressourcen nicht oder nur sehr bedingt zum Übersetzen und Linken komplexer Programme.

Die Binaries auf einem Desktop-Rechner erzeugen wäre allein schon wegen der unterschiedlichen Prozessor-Plattformen nicht leicht. Hierzu bedarf es einer so genannten Crosscompiler-Toolchain, die den plattformfremden Maschinencode generiert. Bis zum fertigen IPK-Paket wollen aber zuvor alle möglichen Bibliotheken erzeugt, die sich daraus ergebende Abhängigkeiten aufgelöst und allerlei Umgebungsvariablen angepasst werden – ein Zeit raubendes und fehlerträchtiges Verfahren, das nach Automatisierung schreit.

Geschätzter Brückenbauer

Open Embedded[7] fasst alle Schritte zu einer ganzheitlichen Lösung zusammen. Als Archiv von Metadaten steuert es die in Python implementierten Bitbake-Tools[8]. Bitbake ist ein Gentoo-Portage-ähnliches System, das vor seiner Version 1.0 noch Open Embedded Core hieß. Die Metadaten von Open Embedded beinhalten zum einen Direktiven, mit deren Hilfe Bitbake einzelne Programme fertigt. Sie berücksichtigen die dazu passenden Quellcode-URIs sowie die anzubringenden Patches, die Abhängigkeiten zu anderen Programmen und spezielle Installationsroutinen.

Zweitens ist Open Embedded auch in der Lage, ganze Paket für fast beliebige Zielplattformen zu schnüren und Flashimages zu erzeugen. Es eignet sich übrigens nicht nur für PDAs, sondern ebenso für andere Embedded-Geräte. Open Embedded hat sich in der Praxis als derart leistungsfähig erwiesen, dass auch die Entwickler von Open Zaurus, Familiar und Open Simpad ihre Distributionen jetzt mit diesem Toolset erstellen.

Abbildung 1: Open Embedded unterstützt natürlich auch Klassiker unter den Linux-PDAs wie diesen Sharp Zaurus SL-5000D.

Abbildung 2: Mit beiden, der 3800er Serie des I-PAQ (Vordergrund) und den alten 3700ern, kommt OE klar.

Installation

Zur Installation richtet man sich zunächst ein Verzeichnis ein, das fortan Bitbake, Open Embedded und die davon erzeugten Dateien enthalten soll. Zum Herunterladen der aktuellen Snapshots sind Subversion ([9],[10]) und Bitkeeper[11] erforderlich:

mkdir ~/oe
cd ~/oe
svn co svn://svn.berlios.de/bitbake/trunk/bitbake
bk clone bk://openembedded.bkbits.net/openembedded

Der Verzeichnisname »~/oe« ist frei wählbar, bei der Wahl eines anderen ist dieser aber durchgehend zu benutzen. Wer auf den kommerziellen Bitkeeper verzichten will, kann Open Embedded auch direkt von[12] herunterladen. Die Möglichkeit zu inkrementellen Updates per »bk pull && bk -r co -q« geht dann aber verloren.

Bitbake vertraut auf die Gegenwart einer Reihe von Entwicklungswerkzeugen: Python ab Version 2.3.0, Perl ab 5.0, Patch ab 2.5.9, Make ab 3.80, »sed« ab 4.0, »m4«, Bison, »bc« und Wget, die sich in jeder Linux-Distribution finden lassen sollten. Zur Performanceverbesserung empfehlen sich der Psyco JIT-Compiler[13] und CCache[14],[15].

Zaurus- und Simpad-Nutzer müssen sich die Crosscompiler-Toolchain selbst installieren. Dazu entpacken sie den Tarball von[16] nach »/usr/local/arm/« (das Zielverzeichnis ist wegen hart kodierter Verzeichnisreferenzen bindend) und benennen Compiler und Linker für Bitbake um:

cd /usr/local/arm/2.95.3/bin
mv arm-linux-gcc arm-linux-gcc-2.95
mv arm-linux-ld arm-linux-ld-2.11.2

Universalgenie

Eine Schablone für die lokale Konfigurationsdatei findet sich nach dem Download in der Datei »~oe/openembedded /conf/local.conf.sample«, die als »local .conf« in das zu erstellende Verzeichnis »~oe/openembedded/build/conf« zu kopieren ist. In dieser Datei erfährt Bitbake nicht nur die erstellte Verzeichnisstruktur, sondern außerdem die gewünschte Hardwareplattform und die Distribution. Es empfiehlt sich das Studium der ausführlichen Kommentare zu allen Variablen.

Zwingend erforderlich ist es, »BBFILES« auf »BBFILES:=${HOME}/oe/openembedded/packages/*/*.bb« zu setzen sowie »MACHINE« und »DISTRO« anzupassen. Gültige Werte für »MACHINE« nennt die Tabelle 1. »DISTRO« akzeptiert die oben erwähnten PDA-Distributionen »openzaurus«, »familiar«, »opensimpad« und andere. Alle Open-Embedded-Parameter lassen sich in den Verzeichnissen »~/oe/openembedded/conf/distro« und »~/oe/openembedded/conf/machine« hinreichend genau studieren.

Zaurus- und Simpad-Nutzer, die vorhin die Crosscompiler-Toolchain installiert haben, fügen zur Konfigurationsdatei noch folgende Zeile hinzu, die Bitbake dazu veranlasst, an das Vorhandensein der Toolchain zu glauben und darum von deren Erzeugung abzusehen:

ASSUME_PROVIDED = "virtual/arm-linux-gcc-2.95"

Die Konfiguration schließt mit der Erstellung einer Textdatei ab (Listing 1), die zwei Umgebungsvariablen anpasst. Die Path-Variable muss um »/usr/local/ arm/2.95.3/bin« ergänzt werden, wenn die Crosscompiler-Toolchain bereits vorinstalliert ist.

In Aktion

Nach dem Einlesen der Umgebungsvariablen mit »source bb.env« (Bash) ist das Build-System zur Arbeit bereit. Der Bitbake-Start sollte vom Verzeichnis »~/oe/build/« aus passen. (Das ist allerdings nicht zwingend, wenn man in »~/oe/build/conf/local.conf« das Verzeichnis für temporäre Dateien explizit angibt.) Die Syntax des Tools ist denkbar einfach: »bitbake« gefolgt von einem oder mehreren, durch Leerzeichen getrennten Namen – und schon beginnt Bitbake damit, die gewünschten Pakete zu erzeugen.

Ein Blick in das Verzeichnis »~/oe/ openembedded/packages/« und seine Unterverzeichnisse offenbart eine lange Liste möglicher Ziele, die keineswegs nur als einzelne Programme zu verstehen sind. So generiert etwa »bitbake nano« ein Executable des Texteditors Nano für die konfigurierte Plattform (Abbildung 3). Auch entsteht eine installierbare IPK-Datei entsprechend der »DISTRO«-Variablen. Mit »bitbake task-bootstrap« hingegen liefert Open Embedded alles zur Basisinstallation eines Systems, vom Kernel mit Modulen über »init« bis hin zur Busybox.

01 #!/bin/bash
02 export BBPATH=~/oe/build:~/oe/openembedded
03 export PATH=~/oe/bitbake/bin:$PATH

Images für den Flash-ROM

Interessanter als das eben beschriebene Basissystem wird es mit »bitbake bootstrap-image«: Hiermit entsteht ein ganzes Root-Dateisystem, das der passende PDA einlesen und in sein EPROM schreiben kann. Das Image enthält das oben erwähnte Basissystem, das nicht grafisch bedienbar ist. Die Steuerung erfolgt stattdessen über die serielle Schnittstelle oder SSH, über die der PDA-Besitzer dann Stück für Stück die weitere Software einspielt.

Anders das OPIE-Image (»bitbake opie-image«) und das GPE-Image (»bitbake gpe-image«): Nach der Installation (siehe Kasten “Flashimages installieren”) und dem PDA-Reboot kann der Benutzer gleich den Stylus zur Hand nehmen und die Grundeinstellungen per Touchscreen erledigen. In beiden Fällen entsteht eine fertig installierte grafische Palmtop-Umgebung mit den wichtigsten Programmen zur Termin- und Adressenverwaltung oder zur Notizenaufnahme (Abbildungen 4a und 4b).

Auf dieser Basis ist es relativ einfach, die neuesten (Entwickler-)Versionen sowohl des Open Palmtop Integrated Environment als auch des GPE Palmtop Environment auf den eigenen PDA zu bringen. Wer nicht ohnehin Präferenzen zu einem der Geräte besitzt, hat die freie Wahl zwischen beiden.

01 LICENSE = GPL
02 SECTION = "console/utils"
03 PRIORITY = "required"
04 MAINTAINER = "Greg Gilbert <greg@treke.net>"
05 DESCRIPTION = "gzip (GNU zip) is a compression utility designed 
06 to be a replacement for 'compress'. The GNU Project uses it as 
07 the standard compression program for its system."
08 
09 SRC_URI = "${DEBIAN_MIRROR}/main/g/gzip/gzip_${PV}.orig.tar.gz 
10            file://configure.patch;patch=1"
11 
12 S = "${WORKDIR}/gzip-${PV}"
13 
14 inherit autotools

Bitbake verrichtet seine Arbeit in seinem Temporärverzeichnis, also in »~/oe/ build/tmp/« beziehungsweise dem in der Konfigurationsdatei spezifizierten. In ihm findet sich neben dem Crosscompiler und diversen Systembibliotheken auch das Verzeichnis »deploy«, das alle erzeugten IPK-Dateien und Installationsimages aufnimmt. Treten mal Fehler beim Open-Embedded-Lauf auf, lohnt sich ein Blick in die dort lagernden Logdateien ebenso wie in das Unterverzeichnis »work«, wo das eigentliche Kompilieren stattfindet.

Liefert auch dies keine tieferen Einsichten zur Problemursache, so gibt es Möglichkeiten, mit der Open-Embedded-Community in Kontakt zu treten[17]. Zuvor sollte man jedoch die relevante Dokumentation, insbesondere das Wiki[18] und die Archive der Mailinglisten, gelesen haben – die meisten Probleme sind damit schnell geklärt.

Fremde Programme

Wer so weit gekommen ist, kann bereits einzelne Pakete und vorgegebene OPIE- und GPE-Images erzeugen. Doch ist das Zusammenstellen ganz nach Gusto maßgeschneiderter Installationsimages das große Ziel, das es zu erreichen gilt. Und so geht’s: Beim Aufruf aus der Shell liest Bitbake den Inhalt der »*.bb«-Dateien aus dem Verzeichnis »~/oe/openembedded/packages/« in seine interne Datenbank ein. Die Dateien bestehen im Wesentlichen aus Key-Value-Paaren, die dann die Konfigurationsbasis für die Programmkomponenten bilden, etwa für den Quellcode-Downloader oder den IPK-Packer. Open-Embedded-fremde Software lässt sich zu den Metadaten hinzufügen, indem man ein Unterverzeichnis passenden Namens anlegt und darin eine »*.bb«-Datei erstellt.

Hat der Programmierer bereits mit den GNU Autotools Vorbereitungen getroffen, indem er beispielsweise dem »configure«-Skript Informationen über Zielplattform, Installations- und Include-Verzeichnisse sowie Compiler-Flags mit auf den Weg gegeben hat, reicht zumeist eine simple Skelettdatei. Als Beispiel dient hier die »*.bb«-Datei aus Listing 2 für den Packer Gzip, der bereits Teil von Open Embedded ist.

Nummer automatisch

Nach einigen Variablen deskriptiven Charakters listet Zeile 9 die URI für das Quellcode-Archiv. »${DEBIAN_MIRROR}« expandiert automatisch zu einem Spiegelserver der Debian-Distribution und »${PV}« zur Programmversion, die sich aus dem Namen der »*.bb«-Datei ergibt. Zeile 10 weist »configure.patch« als ein gegen den Quellcode anzubringendes Patch im Unterverzeichnis »gzip-1.3.5« aus. Der Name des Verzeichnisses definiert sich wieder aus dem Namen der »*.bb«-Datei nach dem Schema »Programmname–Version«.

Mit der Variablen »S« in Zeile 12 will der Maintainer dem Build-System mitteilen, wo es das »configure«-Skript findet. Die heruntergeladenen Archive werden dann in »~/oe/openembedded/build/tmp/ work/« in einem Unterverzeichnis, dessen Namen sich aus dem bereits erörterten Schema ergibt, entpackt. Hier bei Gzip liegt das Skript also schon im Hauptverzeichnis des Tarballs.

Abbildung 3: Bitbake hat den Quellcode des Nano-Editors heruntergeladen und macht sich gerade an die Paketerstellung.

Abbildung 4a: Open Embedded backt Images der aktuellen Entwicklerversion von OPIE …

Abbildung 4b: … genauso zuverlässig wie solche der letzten Release von GPE.

In der letzten Zeile findet sich eine Anweisung, mit der das Paket einige Standardfunktionen zum Erstellen der per Autotools vorbereiteten Programmpakete erbt. Die Definitionen hat das Open-Embedded-Team in »~/oe/openembedded/classes/« abgelegt. Die Klassentypen eignen sich nicht nur für mit Autotools vorbereite Programme, sondern auch für komplexere. So erwarten beispielsweise Programme für OPIE bestimmte Installationsroutinen, damit der Nutzer bei der Installation einen klickbaren Link auf seinem Palmtop vorfindet.

Umgekehrt sollte man nicht benötigte Features und solche, die der PDA gar nicht unterstützt, auch nicht in Open Embedded zu integrieren versuchen. So ergeben X11-Erweiterungen normaler Qt-Programme auf dem mobilen Gerät keinen Sinn, denn Qt-Embedded nutzt ausschließlich den Framebuffer.

Schwachpunkt Doku

Leider ist die Dokumentation der »*.bb«-Dateienstruktur im Wiki des Projekts recht löchrig. Wer tiefer einsteigen will, findet aber beim Studium der Programmpakete wertvolle Hilfe. Bei akuten Problemen lohnt wieder ein Blick in die schon genannten Logdateien.

Zusammenfassend ist zu sagen: Open Embedded gibt einer technisch interessierten Anwenderschicht ein mächtiges Werkzeug zum bedarfsgerechten Erstellen Plattform- und Hardware-abhängiger Binärpakete in die Hand. Technisch weniger Gewandte tun sich aber sicherlich schwer. Doch wer sich angesichts der Dokumentationsdefizite nicht scheut, im Archiv einer Mailingliste oder gar in Python-Quellen nach der Lösung eines Problems zu suchen, hat eine leistungsstarke, produktiv nutzbare Crosscompiler-Umgebung auf dem PC. (jk)