Outside the Walled Garden

Mein Ziel ist ja immer noch ein echtes Debian mit X-Server auf dem Oyo zu betreiben. Gestern habe ich einen ersten relativ erfolgreichen Startversuch unternommen.

Vorbereitungen

Es sind einige Dinge einzurichten und auch einige Besonderheiten des Qisda-u-boots zu beachten.

Speichermedium

Benötigt wird eine MicroSD-Karte mit mindestens 2 Partitionen. Die erste sollte FAT-formatiert sein, da die mmcboot-Funktion unseres u-boot-Bootloaders scheinbar nur Kernel von einer FAT-Partition lädt. Die zweite, größere sollte dann ein etwas fortschrittlicheres Dateisystem enthalten. Ich wähle hier meist ext3. Es heißt zwar immer dass Dateisysteme mit Journaling-Funktion nicht für Flash-Speicher geeignet seien, da sie zu viele Schreibvorgänge erzeugen. Eine Untersuchung von Theodore Ts'o zeigt jedoch, dass der Overhead durch das Journal nicht so groß ist.

Basissystem

Weiterhin benötigt man auf alle Fälle ein Debian-Basisystem in der Geschmacksrichtung armel. Hier konnte ich mir behelfen indem ich einfach das funktionierende System von meinem Openmoko Freerunner kopiert habe. Dieses platziert man auf der zweiten Partition der SD-Karte.

Sollte das ganze später mal richtig funktionieren würde es sich anbieten das Installations-Skript aus dem pkg-fso-Debian-Projekt anzupassen. Das Skript ist momentan nur für Openmoko-Geräte gedacht, wird aus der originalen Firmware heraus aufgerufen und installiert ein Debian-Basissystem auf die SD-Karte, inklusive SSH-Daemon und dergleichen.

Kernel

An dieser Stelle habe ich erstmal den 2.6.21.5 von Thalia mit kleineren Modifikationen verwendet. Das Cross-Kompilieren eines Kernels habe ich ja bereits an anderer Stelle beschrieben.

Geändert sind dabei nur die Boot-Optionen und der zusätzlich aktivierte gadget-Ethernet-Treiber.

--- .config.old 2010-11-09 08:38:56.000000000 +0100
+++ .config     2010-12-27 15:56:43.000000000 +0100
@@ -278,7 +278,7 @@
 #
 CONFIG_ZBOOT_ROM_TEXT=0x0
 CONFIG_ZBOOT_ROM_BSS=0x0
-CONFIG_CMDLINE="root=/dev/mmcblk0p1 rootfstype=ext3 ro init=/linuxrc console=ttySAC0,115200"
+CONFIG_CMDLINE="root=/dev/mmcblk1p2 rootfstype=ext3 ro init=/sbin/init console=ttySAC0,115200"
 # CONFIG_XIP_KERNEL is not set
 # CONFIG_KEXEC is not set

@@ -1286,7 +1286,8 @@
 # CONFIG_USB_GADGET_DUMMY_HCD is not set
 CONFIG_USB_GADGET_DUALSPEED=y
 # CONFIG_USB_ZERO is not set
-# CONFIG_USB_ETH is not set
+CONFIG_USB_ETH=m
+CONFIG_USB_ETH_RNDIS=y
 CONFIG_USB_GADGETFS=m
 CONFIG_USB_FILE_STORAGE=m
 # CONFIG_USB_FILE_STORAGE_TEST is not set

Wichtig ist hier noch die Modul-abhänigigkeiten zu erzeugen. Ich habe mir hier mit einem chroot aus der Oyo-Firmware in mein Debian-System beholfen um das

depmod -a

Zur Größe des Kernels ist zu sagen, dass er 1,5MB nicht überschreiten sollte. Nach dem was ich in cpu/s3c24xx/mmc.c in den u-boot-Quellen gefunden habe liest er nur diese Größe (1586688 Byte) von der SD-Karte. D.h. größere Kernel-Images werden Fehler produzieren da dort der restliche Teil fehlt. Die maximale Größe der Ramdisk-Datei liegt bei 2,4 MB (2607616 Byte).

Das Kernel-Image platzieren wir in qdutil/uzImage auf der ersten Partition der SD-Karte. Auch die qdutil/urootfs.img muss vorhanden sein. Sollte sie fehlen, weigert sich der u-boot den Kernel zu starten.

Der Start

Mit all diesen Vorbereitungen und den gedrückten Vor- und Zurück-Knöpfen beim Einschalten, startete das System erfolgreich und ich konnte mich per SSH über die USB-Ethernetverbindung anmelden. Da der Kernel aber so furchtbar alt ist, arbeitet dieser nicht mehr mit aktuellen udev-Versionen zusammen, sodass die Anzahl der Geräte in /dev sehr überschaubar waren.

Es geht also tendenziell erstmal nichts, aber es startet wenigsten schon mal. Als nächstes werde ich das ganze mal mit einem aktuellen Kernel versuchen.

Da der u-boot in allen Readern der Qisda-Familie gleich zu sein scheint trifft die oben beschriebene Prozedur nicht nur auf den Oyo sondern auch auf alle anderen Reader auf Qisda-Basis wie dem Asus DR-900 oder Sagem Binder alias Fnacbook zu

Ein Nebenprodukt der Entwicklung der Openmoko-Platform war das Projekt freesmartphone.org . Dieses hat sich zum Ziel gesetzt eine sogenannte Middleware für mobile Geräte zu entwicklen.

Auch nach dem Ende der Openmoko Telefonproduktion besteht freesmartphone.org fort und bietet momentan Unterstützung nicht nur für Openmoko-Telefone sondern unter anderem auch für den Palm Pre und das Nokia N900.

Middleware bezeichnet Software die zwischen den rohen Treibern des Kernels und Anwendungsprogrammen sitzt und den Zugriff auf die Hardwarekomponenten abstrahiert. So sollte sich zum Beispiel idealerweise eine Telefonie-Anwendung nicht dafür interessieren müssen was für ein GSM-Modem die eigentliche Arbeit tut.

Das ofono-Projekt tut ähnliches aber eben nur auf dem Gebiet der GSM-Kommunikation. freesmartphone.org geht hier aber noch einen Schritt weiter und möchte alle Features eines mobilen Gerätes kapseln.

Die Kommunikation der Komponenten untereinander und mit den Anwendungsprogrammen erfolgt dabei über DBus.

Einzelkomponenten

Der Software-Stack besteht dabei aus mehreren Einzelkomponenten die sich um die verschiedenen Themenbereiche kümmern. Die bisher am weitesten fortgeschrittenen Komponenten sind dabei:

fsousaged - Resourcenmanagement

Der fsousaged kümmert sich um die Verwaltung der Resourcen. In einem mobilen Gerät ist der Stromverbrauch sehr wichtig. Deswegen sollten Komponenten nur aktiviert sein wenn sie auch benötigt werden.

Hier fordern also die Anwendungen den Zugriff auf eine Resource des Gerätes an und der usage-Daemon kümmert sich darum dass das Gerät aktiviert wird. Wenn die letzte Anwendung ihren Zugriff auf die Resource wieder freigibt deaktiviert fsusaged dieses auch wieder.

Ein weiterer wichtiger Aspekt des usage-Daemons ist das sogenannte "suspend-handling". Bei mobilen Geräten ist der Schlaf-Modus (suspend) sehr wichtig um die Akku-Laufzeit annehmbar zu halten. Der Akku würde zum Beispiel schnell schlapp machen wenn das Gerät normal läuft, obwohl es in einer Tasche steckt und höchstens auf einen Anruf wartet. Der fsousaged kümmert sich dabei auch um das Ermitteln des Aufwachgrundes. Dies kann zum Beispiel ein druck auf den Anschaltknopf sein, aber auch ein ankommender Anruf.

fsodeviced - Gerätemanagement

Hier erfolgt die eigentliche Kapselung der Einzelkomponenten der Geräte. D.h. die verschiedenen Eigenarten einzelner Geräte werden ausgeglichen und das ganze dann per DBus-API verfügbar gemacht.

Hier sitzen dann auch Funktionen um manche Geräte das Schlafengehen zu erleichtern. Vor allem GSM-Modems, benötigen viel Hilfe um schlafen zu gehen und trotzdem empfangsbereit zu bleiben und das Gerät bei einem Anruf aufzuwecken.

fsogsmd - Management von GSM-Verbindungen

Der GSM-Daemon kuemmert sich darum Sprach und Datenverbindungen ueber ein GSM-Modem zu ermöglichen. Hier gibt es dann Module die die Eigenarten der verschiedenen GSM-Module überdecken und vor den Telefonieanwendungen verstecken.

GSM-Modems arbeiten zwar im Allgemeinen mit normalen AT-Befehlen, es scheint aber so, dass Hersteller oft eigene Erweiterungen entwicklen oder die Modems manche Befehle nicht korrekt unterstützen.

fsodtld - Zeit- und Ortsverwaltung

Der date-time-location-Daemon kümmert sich um die Bestimmung von Orts- und Zeitwerten. Er nutzt dabei GPS-Empfänger und verschiedene Zeitresourcen zur Bestimmung der Werte.

Gelegentlich möchte ich auch Dinge aus der Vergangenheit - also vor dem Start des Blogs - aufarbeiten um darzustellen wie ich zu bestimmten Ein- bzw. Ansichten gelangt bin. An vielen Stellen wird es auch nützlich sein, auf solche allgemeineren Einträge zurückverweisen zu können um Betrachtungen eines bestimmten Themas nicht mit allgemeinen Informationen zu überfluten. Heute also etwas über mein erstes freies Gerät.

Das erste mal aus dem "Walled Garden" herausgetraut habe ich mich Mitte 2008 mit dem Openmoko Freerunner - einem Mobiltelefon.

Hardwareseitig ist der Freerunner dem Oyo recht ähnlich: Samsung S3C-SoC mit 400MHz und 128MB Arbeitsspeicher. Nur dass der S3C-2443 des Freerunners nur die ARMv4-Instruktionen unterstützt wärend der S3C-2416 vom Oyo das ARMv5 Instructionset bietet.

Ich hab dann auch direkt das von Openmoko gepflegte, OpenEmbeded-basierte GNU/Linux-System links liegen gelassen und bin auf dem Telefon direkt zu Debian gewechselt.

Das erste Jahr über war an die Nutzung als Telefon gar nicht zu denken. So nach und nach nahm dann aber der freesmartphone.org Software-Stack Form an, sodass ich den Freerunner dann bis Mitte 2010 als einziges mobiles Telefon genutzt habe.

Die Kombination X11 + E17 mit Illume Frontend + allem was Debian zu bieten hat ist schon überwältigend. Sei es zum Geocachen, Sterne beobachten oder eben ganz profan zum telefonieren - man möchte einfach nicht mehr zurück.

Dann bin ich doch dem Google Nexus One erlegen - aber darüber schreibe ich ein anderes Mal . Nur soviel: auch auf dem Nexus One ist Debian mein Ziel, denn der Schritt von Debian zu Android fühlt sich schon sehr einschränkend an.

Ich hab ja bereits vermutet das der angekündigte Asus Eee-Reader DR-900 ebenfalls zur Familie der Qisda-OEM-eBook-Reader gehört. Verräterisch ist unter anderem die weitestgehend gleiche Hardware wie in Oyo und Konsorten, als auch das Kürzel AS090B00 in verschiedenen Quelltexten.

Die ersten beiden ersten Buchstaben bezeichnen im Allgemeinen den Anbieter des Gerätes und die folgenden 3 Zahlen die Displaygröße. So hat der Oyo zum Beispiel das Kürzel SG060B00 was ihn zu einem Abkömmling des Sagem Binder macht.

Heute habe ich auf den Support-Seiten von Asus nun auch ein Firmware-Archiv gefunden und natürlich gleich seziert - ich hatte Recht mit meiner Vermutung.

Grundlagen

Das Archiv enthält erstmal andere Dateien als in den bisherigen Firmware-Archiven. Der Kernel ist der uns bereits bekannte 2.6.21.5 mit Erweiterungen. Eigentlich hatte ich hier gehofft dass Asus als größere Firma hier etwas mehr investiert und die Qisda-Treiber auf einen neueren Kernel portiert. Der WLan-Chip ist von Marvell und wird hoffentlich direkt vom libertas-Treiber unterstützt.

Ganz wichtig für die Bastler: die bereits vom Oyo bekannte mmcboot-Möglichkeit ist im Asus u-boot.bin scheinbar wie gehabt vorhanden - dem eigenen Betriebssystem als Dual-Boot steht also nichts im Wege.

Anwendungen

Beim Stöbern in usr/local/asus findet sich eine gänzlich andere Struktur als bisher zu sehen war. Wo beim Oyo die ganze Anwendung ein 40MB großer monolithischer Klotz inklusive Browser und der gleichen ist findet sich bei Asus ein leichtgewichtiges Geflecht verschiedener Anwendungen die sich dann scheinbar mittels .desktop-Dateien dem System bekannt machen.

Wie weiter

Mit dem Anbieten des Firmwaredownloads hat Asus mir und dem Rest der Welt den Linux-Kernel und die restlichen (L)GPL-Anwendungen des Readers unter den Bedingunen der (L)GPL zur Verfügung gestellt. Im Handbuch gab es sogar einen längeren Absatz darüber dass Asus die GPL-Konformität wichtig ist zusammen mit einer Mail-Adresse für GPL-spezifische Anfragen. Deswegen werde ich dort mal anfragen wann die Quellen veröffentlicht werden. Eventuell ist ja auch der auofb-Quelltext dabei.

Ansonsten hoffe ich mal dass der DR-900 bald auch hier erhältlich ist, da ich ihn als sehr interessanten Zweitreader vor allem für großformatige Dokumente empfinde.

In einem anderen Blog über die Oyo-Reader-Familie habe ich einen interessanten Link zum FCC Testreport des VRS-QD060B00 Modells gefunden.

Besonders interessant daran ist das Dokument mit dem Titel "Internal Photos". Dort wird das Gerät fein säuberlich auseinandergenommen und die einzelnen Komponenten sehr detailiert in Fotos festgehalten.