Outside the Walled Garden

Heute war ich mal bei Thalia um mir das Drama den Oyo 2 anzusehen. Im Vorfeld geisterten ja bereits Berichte durch diverse Foren, in denen von ähnlichen Fehlern wie beim Vorgängermodell - zum Beispiel Abstürze und andere Hänger - berichtet wurde.

Das Gerät

Das Design des ersten Oyos wirkte auf mich irgendwie immer recht altbacken, wohingegen ich das glatte Design des Oyo 2 schon als relativ ansprechend empfinde. Dass das Gerät mit 260g recht schwer ist, die Tasten schwergängig sind und kaum einen Druckpunkt haben, wurde ja bereits an verschiedenen anderen Stellen geschrieben. Aber ich wollte ihn ja nicht kaufen und habe mich im weiteren auf die für mich interessanten Punkte hin untersucht:

Display

Das Display soll ja ein Sipix-Display der zweiten Generation sein und einen besseren Kontrast aufweisen. Auf den ersten Blick ist es auch tatsächlich ein Stück heller als der daneben hängende Oyo-3G. Aber auch das Display meines Asus eeeReaders war heller als das des Oyo 1.

Das Display schien auch etwas zügiger anzusprechen als das Vormodell (im im direkten Vergleich stellte sich dass dann aber als Trugschluss heraus), was man vom Rest der Software nicht behaupten konnte.

Dafür waren aber eine ganze Menge Ghosting-Effekte, also Überbleibsel der Vorseite nach einem Wechsel, zu sehen. Hier wäre mal interessant zu testen, wie sich das Display mit richtiger Software [aka Debian + X11 ] verhalten würde, bzw. welche Modi der Ansprache es überhaupt unterstützt. In diesem Atemzug wäre zudem noch interessant welchen Display-Controller der Reader verwendet. Momentan sind mir der AUO-K1900 und -K1901, vom Hersteller der Sipix-Displays, bekannt, wobei der Oyo einen K1900 verwendet.

GPL-Compliance

Der Source-Release von Thalia für den ersten Oyo war ja zu keiner Zeit konform mit den Bedingungen die sich aus der GPL ergeben. Zum einen wurde erst mit mächtiger Verspätung und nach mehrmaligem Nachhaken überhaupt etwas veröffentlicht und zum anderen war diese Veröffentlichung extrem unvollständig, denn es wurde nur ein unvollständiger Quellcode für den Linux-Kernel und den U-Boot Bootloader veröffentlicht. Auf den Quellcode des WLan-Moduls, dass sich als GPL-lizensiert bezeichnet, warten wir heute noch.

Mit dem Oyo 2 hat Thalia aber scheinbar nichts dazu gelernt. Im Handbuch gibt es zwar am Ende eine URL, zum — man beachte die lustige Formulierung — »Quelltext der verwendeten GPL/LGPL«, diese verweist aber auf das Archiv des Oyo 1 Codes. D.h. entweder hat seit Ende 2010 kein Entwickler mehr den Kernelquelltext angefasst und der Oyo 2 verwendet exakt den selben Kernel wie der Oyo 1, oder der Link ist einfach verkehrt.

Zweifel daran, dass seit dem Oyo 1 nichts am Kernel getan wurde ,kommen auch durch die Versionsinformationen, die der Oyo selbst von sich gibt. MD06SB10 ist definitiv nicht SG060B00, deutet aber darauf hin, dass Medion diesmal sein eigenes Kürzel bekommen hat und nicht eine Variante des Sagem-Readers verwendet.

Zusammengefasst, der »verlinkte« Code ist zu 99% nicht der Kernel des Oyo 2 und der Rest der GPL-Software fehlt immernoch bzw. wiedermal. Auch um die restlichen Bestimmungen der GPL kümmert sich wiedermal niemand - denn eigentlich ist das Downloadangebot immer nur eine zusätzliche Option und kann die Möglichkeit zur Datenträgeranforderung immer nur ergänzen.

Was im kommerziellen Umfeld dabei oft niemand bedenkt ist die Termination-Clause der GPL (GPLv2 §4 and GPLv3 §8 ). In der GPLv3 ist diese etwas freundlicher dem Verletzer gegenüber gestaltet und ermöglicht ein wiederherstellen der Lizenzrechte nach Ende der Verletzung. Da der Linux-Kernel aber exklusiv unter der GPLv2 steht ergeben sich weitere interessante Denkanstöße, den die GPLv2 sagt, dass bei Verletzungen der Lizenz alle Rechte die sich daraus ergeben (u.a. Vervielfältigung und Veränderung) erlöschen »until those rights are explicitly reinstated by the copyright holder«. D.h. der bzw. die Urheber müssen explizit zustimmen die Rechte der GPL widerherzustellen. Beim Linux-Kernel sind das weit mehr als 1000 Individuen .

Thalias Lizenz für mindestens den Linux-Kernel ist eigentlich bereits beim Release des Oyo 1 erloschen, da bereits dort die Quellen für mindestens diesen Linux Kernel fehlten — ein nachträgliches Veröffentlichen hilft bei GPLv2-Software nicht. Das Vervielfältigen und Vertreiben von eben diesem Linux-Kernel auf dem Oyo 2 ist also essentiell eine sogenannte »Raubkopie«. Für ein Unternehmen, dass seine eigenen Waren mit einem DRM schützt um vermeintliche »Raubkopierer« fernzuhalten, ist dass schon irgendwie bedenklich.

Ein sehr lesenswerter Text zu diesem Thema ist übrigens A Practical Guide to GPL Compliance des Software-Freedom-Law-Centers.

Um den aktuellen Stand etwas besser zeigen zu können, habe ich heute meine ersten zwei Telefon-Kamera-Wackel-Videos aufgenommen.

Das erste Video zeigt den Thalia Oyo mit CoolReader3 und Orerry.

Im Zweiten ist die selbe Oberfläche zu sehen, nur eben auf dem größeren Display des Asus-Readers

Nach der Freigabe des Linux-Kernels der Version 3.1 vor zwei Wochen, hat sich vorgestern nun das Merge-Window für den 3.2er Kernel geschlossen. Es sind also alle Features für den 3.2er Kernel eingeflossen und werden nun bis zum Release stabilisiert.

Mit dabei waren auch eine ganze Reihe meiner Patches:

E-Reader spezifische Features im 3.2er Kernel

Die Patches gehören dabei zu vier großen Themenbereichen für den Oyo und seine Verwandten.

GPIO-regulator

Ein generischer Treiber für Spannungs- und Stromregler die über GPIOs kontrolliert werden.

Mit diesem Treiber lassen sich sowohl der Regler für die Prozessorspannung als auch die Stromstärke für den bq24075 Lade-IC kontrollieren. Er ist dabei so generisch ausgelegt, dass er sich für Regler mit beliebig vielen Spannungen/Stromstärken eignet.

OTG-Handling für den USB-Gadget-Treiber

On-The-Go ist zwar eher für USB-Ports gedacht, die sowohl Gadget als auch Host sein können, um die Umschaltung zwischen beiden Modis zu realisieren. Mit dem generischen gpio-vbus-OTG-Controller ist es aber auch möglich für reine Gadget-Controller einen Stromstärkenregler zu kontrollieren.

Dadurch wird es möglich, bei Verbindungen mit einem Host den bq24075-Lade-IC zu aktivieren bzw. deaktivieren und seine Stromaufnahme zwischen 100 und 500 Milliampere einzustellen.

Analog-Digital-Konverter

Der sogenannte ADC des S3C2416 unterscheidet sich erheblich von den Typen, die in den verwandten SoCs vorhanden sind. Ich habe also den Support dafür nachgerüstet — und weil es quasi auf dem Weg lag auch gleich die Unterstützung für den S3C2443 implementiert.

Takte für ARMCLK

Der Takt des Prozessors wird über mehrere Taktgeber gesteuert. Diese waren bereits für den in dieser Beziehung ähnlichen S3C2443 implementiert. Die Patch-Serie verschiebt den Code für die Taktgeber in den allgemeinen Bereich und bietet Raum um die feinen Unterschiede zwischen S3C2443 und S3C2416 abzubilden.

Der CPU-Frequency-Scaling-Treiber tut dann nichts anderes, als die Taktung dieser Taktgeber zu steuern.

Ausblick auf die nächsten Entwicklungsschritte

Um den Untertschied zwischen dem Haupt- und Oyokernel nicht zu groß werden zu lassen, habe ich gestern Abend auch das Update auf 3.2-rc1 vollzogen. Neben der weiteren Bastelei am AUO-K1900-Framebuffer-Treiber sieht mein Plan für den Mainline-Kernel momentan so aus:

Fehler im CPU-Frequency-Scaling suchen

Der Treiber für die dynamische Anpassung der CPU-Frequenz hatte bereits im 3.1er Kernel Probleme wenn zusätzlich die Spannung geändert wurde.

Seit dem Update auf den Entwicklungskernel produziert er sehr zuverlässig Hänger wenn die Frequenz nach dem Start heruntergesetzt wird. Diesen Problemen möchte ich auf den Grund gehen. Vieleicht erreicht er auch noch die notwendige Reife für den 3.3er Kernel.

SRAM des S3C2416 nutzen

Zusätzlich zum normalen Arbeitsspeicher besitzt der S3C2416 noch 64KB an sogenanntem SRAM. Die ersten 4KB davon werden vom Prozessor als sogenannter Steppingstone beim Booten verwendet. D.h. dorthin wird der jeweilige Bootblock kopiert, den der Prozessor starten soll. Nach dem Starten wird der gesamte Speicher freigegeben und könnte für andere Dinge genutzt werden.

In den 3.2er Kernel zieht nun auch Code ein, um solche SRAM-Blöcke mappen zu können. Hier möchte ich gern sehen ob sich eine sinnvolle Nutzungsmöglichkeit ergibt.

Touchscreen-Treiber aufräumen

Der Touchscreen-Treiber hat nun eine gewisse Reife erlangt. Vieleicht schaffe ich es, ihn bis zum Merge-Window des 3.3er-Kernels in den Maintainer-Tree des Input-Subsystems zu hieven, sodass er dann in diesen Kernel einfliessen könnte.

DeviceTree-Unterstützung

DeviceTree — auch OpenFirmware genannt — ist das neue Buzzwort im Linux-ARM-Bereich. Hier lässt sich die Hardware nicht wie im PC-Bereich durch Auslesen des Busses bestimmen, sondern es sind statische Angaben über die vorhandene Hardeare nötig. Bisher passierte dies in sogenannten Board-Files, die die Hardware mittels Programmcode beschreiben und initialisieren.

Das DeviceTree-Konzept sieht nun vor, dass die Hardware-Beschreibung nicht mehr mittels Programmcode sondern über ein strukturiertes Text-Dokument beschrieben wird. Im Endausbau soll diese Hardwarebeschreibung dann nicht mehr im Kernel selbst liegen, sondern diesem vom Bootloader her mitgegeben werden. Dadurch wäre es dann nicht mehr notwendig für jedes neue Hardwareprodukt den Kernel selbst zu modifizieren.

Da die Samsung-Entwickler hier schon einiges an Vorarbeit geleistet haben, möchte ich einfach mal schauen inwieweit dies auch schon für meine S3C2416-Platform funktioniert.

Beim Eintrag zum Display-Controller gab es noch jede Menge Baustellen. Heute scheint es nun so, als ob ich die grundlegenden Probleme endlich im Griff habe.

Wie man sieht, ist die Darstellung jetzt nicht mehr verzerrt und die 16 Graustufen werden korrekt dargestellt. Dazu habe ich in den letzten Tagen auch den Touchscreen-Treiber vervollständigt sodass sich die Geräte jetzt über diesen bedienen lassen.

Der Treiber für den Display-Controller braucht noch eine ganze Menge Arbeit - vor allem im Geschwindigkeitsbereich - und natürlich braucht es noch jemanden der sich um einen vernünftigen Userspace kümmert und z.B. die Software des OpenInkpot-Projektes nutzt.

Und weil es so schön ist, hier noch ein zweites Bild — diesmal von Orrery.

Orrery ist so eine Art Sternenatlas für mobile Geräte