Outside the Walled Garden

Heute bin ich auf einen interessanten Aufsatz der LiMo-Foundation gestoßen. Dieser trägt den Titel "Mobile Open Source Economic Analysis" und versucht Vorteile der Nutzung von "Open Source"-Software quantitativ, wie immer als "Ersparnis", darzustellen.

Gedanken

Die LiMo-Foundation ist dabei eine Allianz, die von Motorola, NEC, NTT DoCoMo, Panasonic Mobile Communications, Samsung Electronics und Vodafone gegründet wurde. Also im Prinzip eine Herstellervereinigung.

In dieser Blickrichtung eines Herstellers finde ich die Erkenntnisse in Punkt 4.3 ab Seite 20 besonders interessant. Die zentrale Aussage ist, dass das "Forken", also abspalten von einem Open Source Projekt, unrentabel ist und Hersteller bedeutend besser fahren, wenn sie versuchen mit den Upstream-Projekten zusammenzuarbeiten und ihren Code dort unterzubringen. Grundlage dieser Aussage ist die Annahme dass sich freie Softwareprojekte immer weiterentwickeln, also keinen "fertig"-Zustand besitzen. Dies wird auch durch verschiedene Betrachtungen zur Entwicklung mehrer Projekte ganz am Anfang des Aufsatzes unterstützt.

Wenn nun ein Fork neuere Features des Upstream-Projektes nutzen möchte ist ein großer Aufwand nötig den separat gepflegten Code auf die Änderungen des Quellprojektes zu portieren, was sehr oft dazu führt, dass das zugrunde liegende Projekt niemals aktualisiert wird. Wenn hingegen der meiste Code direkt im Upstream-Projekt integriert ist, wird dieser bei Änderungen meist direkt mit angepasst, sodass sich der Wartungsaufwand auf lange Sicht sehr stark verringert. Diese langfristige Ersparnis wird aber mit etwas Mehraufwand erkauft, der nötig ist, um den Code soweit aufzubereiten, dass die Upstream-Entwickler bereit sind diesen in das Projekt aufzunehmen.

Im Oyo-Kontext betrachtet

Wie bereits im Ersteindruck zu den Kernel-Quellen beschrieben, hat der Oyo-Kernel genau das oben beschriebene Problem. Der original 2.6.21.5-Kernel ist fast 3 Jahre alt und aktuelle offizielle Kernel besitzen inzwischen auch schon länger Unterstützung für große Teile der S3C-Plattform.

Da sich aber der S3C-Code zwischen s3c-linux und dem offiziellen Kernel unterscheiden, scheuen die Betreuer vermutlich den oben beschriebenen ziemlich großen Aufwand des Upgrades. Es müsste ja zuerst herausgefunden werden welcher Code selber oder abgewandelter Form im offiziellen Kernel liegt und die restlichen Teile daran angepasst werden.

Da nun aber auch die Oyo-spezifischen Module ebenfalls auf dieser nicht-mainline S3C-Implementierung basieren wird die herstellerseitige Bereitschaft zum Upgrade noch weiter sinken, da der notwendige Aufwand damit noch weiter gestiegen ist.

Damit haben sich die Hersteller dann aber effektiv auch von allen anderen Verbesserungen des Kernel abgekoppelt. In den letzten 3 Jahren sind nun auch ein ganz paar Performance-Verbesserungen dazugekommen, die dem offiziellen Oyo nicht zur Verfügung stehen, auch wenn es gerade im Embeded-Bereich extrem sinnvoll wäre.

Heute hat Thalia also einen Teil der Oyo-Quellen zur Verfügung gestellt. Hier also ein erster Eindruck zu diesen.

Zu allererst ist zu bemerken, dass es sich nur um den Kernel- und u-boot-Quellen handelt. Die (L)GPL-Elemente des Grundsystems wie auch der Treiber für dem MediaTek 5921 WLan-Chip fehlen. Den u-boot habe ich mir bis jetzt noch nicht näher angesehen - funktioniert ja auch erstmal.

Der Kernel selbst ist ein 2.6.21.5 der scheinbar die Ausgangsbasis für Samsung war um darauf ihren S3C aufzubauen. Die meißten S3C-spezifischen Sachen sind aber auch in aktuelleren offiziellen Kernel-Versionen enthalten. Mir ist schleierhaft weswegen niemand auf die Idee kommt sich den Pflege-Aufwand dieses Forks zu sparen, die offiziellen Kernelquellen als Ausgangsbasis zu nehmen und Änderungen in den offiziellen Kernel zurückfließen zu lassen.

Auf dieses "s3c-linux" genannte Gebilde (rel-4-6-0) hat dann Benq/Qisda noch ein paar Erweiterungen für die eigentlichen eBook-Reader draufgesetzt. Treiber für Touchscreen, Tasten und das nvram habe ich als Quelltexte gefunden.

Der einzige Wermutstropfen sind die Treiber für das Sipix-Display. Diese liegen als vorkompilierte Objektdateien direkt im Kernelquelltext - also ohne den eigentlichen Quelltext. Dass dies so nicht GPL-kompatibel ist, ist vermutlich noch nicht bis zu AU Optronics durchgedrungen.

Dienstag habe ich bei Thalia nachgefragt wann denn nun mit den Quellen der verwendeten GPL-Software zu rechnen ist, da diese ja eigentlich zum Kaufzeitpunkt verfügbar sein müssten. Der sehr nette Mitarbeiter von Thalia der damit betraut zu sein scheint, hat mir dann am Mittwoch früh direkt geantwortet, dass sie damit rechnen die Quellen bis Freitag - also morgen - zur Verfügung zu stellen.

Da wir es ja bereits hinbekommen haben den Oyo einen Kernel von der SD-Karte booten zu lassen fehlen uns nur noch einige Treiber für die Oyo-spezifischen Komponenten um dann ein ganz anderes System darauf zu starten.

Da die meisten Treiber direkt in den Kernel eingebunden sind fallen diese ganz automatisch unter die GPL. Von besonderem Interesse sind dabei besonders:

• auofb, der Treiber für die Ansteuerung des Sipix-Displays
• der Treiber für den RT5624 Soundcodec, der aber lt. Google auch in irgend einem Android-Kernel zu finden sein sollte.
• qisda-nvram, einfach um herauszufinden was in diesem nvram steht
• qisda_iic, was scheinbar der Treiber für den Touchscreen ist
• s3c-keypad-qisda vermutlich zur Ansteuerung der 4 Knöpfe

Ein Sonderfall ist dabei der Treiber für den MT5921, also das WLAN-Modul. Diese schwirrt an einer sehr eigentartigen Position im Dabeisystem herum. Das Modul selbst behauptet aber von sich unter der GPL zu stehen, sodass es eigentlich auch im Source-Release enthalten sein müsste.

Also noch einmal schlafen und dann werden wir sehen was uns Thalia beschert - hoffentlich keine Kohle.

Der Oyo ist ja scheinbar nur eins von mindestens 20 relativ gleichartigen Modellen. Ich habe also heute mal angefangen diese in der Wiki-Seite zu dokumentieren. Dann habe ich noch etwas nach deren Firmware gestöbert, da ich gehofft habe dort noch interessante Einblicke zu ergattern.

Die grundlegenden Mechanismen der Firmware sind bei alle Geräten gleich. Es gibt immer eine .bin-Datei und eine rootfs.tar. Auch der eigentliche Inhalt der Basissysteme ist gleich. Nur bei der eigentlichen Lesesoftware unterscheiden sich die Geräte etwas voneinander - jedenfalls anhand der Screenshots die ich gesehen habe.

So wie es aussieht hat aber noch keiner dieser "Hersteller" die Quellen der verwendeten Software herausgerückt. Außerdem steht ja die Vermutung im Raum, dass der u-boot-Quelltext den Thalia bisher freigegeben hat nicht vollständig ist, da z.B. die mmcboot-Option die der Oyo scheinbar verwendet um Sachen von der SD-Karte zu booten überhaupt nicht vorhanden ist.

Ansonsten bin ich in einer Version der Firmware des NVSBL L337 (vom 01.11.2010) auf die von mir gesuchten uzImage und urootfs.img Dateien gestoßen. So wie ich die Texte in unserer .bin-Datei und kjus u-boot-Meldungen gelesen habe, habe ich ja die starke Vermutung, dass der Oyo auch eben dieses System direkt von der SD-Karte starten kann. Nur bisher fehlten mir leider Beispieldateien um zu sehen um was es sich da handelt.

Morgen werde ich mal versuchen herauszufinden was dort jetzt genau passiert.

Das Kompilieren eines bootfähigen Kernels für ein "embedded"-System ruft immer wieder den Geist des Cross-Kompilierens auf den Plan. Dabei wird der Kernel nicht auf dem Zielsystem selbst, sondern auf einem anderen Host mit einer anderen Prozessor-Architektur erstellt.

Nun gibt es bereits dutzende Howtos zu diesem Thema, und trotzdem habe ich festgestellt, dass ich immer eine größere Menge Browser-Tabs benötige, bis ich die entsprechenden Informationen wieder zusammen habe. Deswegen sind die folgenden Punkte eher für mich zum Nachschlagen gedacht - aber vieleicht helfen sie später auch mal jemand anderem.

Mal sehen, ob das jetzt mit dem „Erweiterten Eintrag“ von Serendipity klappt …

"Cross-compiling 101" vollständig lesen