Gesammeltes Bootloaderwissen

Geschrieben von MMind am Samstag, 15. Januar 2011 in E-Book Reader

Ich versuche jetzt Gedanken und angelesenes Wissen zu vereinen. Ich habe leider immer nur Dokumentation zu Einzelschritten gefunden habe, die sich zudem meist an Entwickler richtet, die wissen was sie tun. Deshalb können Gedanken und Schlussfolgerungen, die ich ziehe auch falsch sein. Da auch ich hier nur im Nebel stochere, bin ich für alle Tips kundiger Besucher dankbar.

Boottheorie

Wie ich gelesen habe, sind die architekturspezifischen Teile des Kernels komplett unterschiedlich implementiert. Das heißt, ich schreibe hier nur über die Architektur »arm«. Weiterhin werde ich den Bootprozess rückwärts durchgehen und mit dem Wichtigsten anfangen.

Am Ende des Bootprozesses steht immer die sogenannte »machine-definition« oder »board-definition« - das sind die »mach-XXX«—Dateien unter arch/arm/... . Diese beschreibt und initialisiert das ganz spezielle Gerät. So ist zum Beispiel die board-definition meines Openmoko-Freerunners unter arch/arm/mach-s3c-2440/mach-gta02.c zu finden.

Jedes dieser Boards hat eine eigene einzigartige ID. Diese IDs werden auf einer speziellen Website gelistet und auch angefordert.

Beim starten wählt der Kernel aus den verfügbaren Definitionen diejenige aus, deren ID ihm der Bootloader mitgeteilt hat. Dies tut der Bootloader, indem er die ID in ein spezielles Register schreibt, aus welchem der Kernel sie dann wieder herausholt.

Der Bootloader wiederrum wird vermutlich für ein spezielles Board gebaut, sodass dort die entsprechende ID wieder einfach fest drin steht.

Praxis

Die Qisda-Entwickler haben es sich einfach gemacht. Das Board der Reader-Familie ist scheinbar ähnlich zur smdk2416-Definition. Deswegen sind sie nicht den Weg über eine neue ID gegangen, sondern habe ihre Änderungen einfach in den Code für dieses Board reingeschrieben.

Sowas mag in einem Kernel-Fork ohne Pflegeabsicht vieleicht funktionieren, sobald wir aber versuchen Reader-Code in den offiziellen Kernel zu schieben, gibt‘s von den anderen Entwicklern eins auf die Rübe.

Das heißt, der auf lange Sicht zu gehende Weg ist es, eine neue Maschinen-ID anzufordern, um dort auch unsere weiteren Komponenten korrekt definieren zu können (Touchscreen, Lade-Chip, Regulator und was sonst noch alles da drin steckt.). Leider bedeutet das auch, den Bootloader auszuwechseln, da dieser die neue MaschinenId weiterreichen muss.

Hier steht auch die Frage im Raum: Eine Id für alle Reader-Varianten oder jeder Variante eine eigene Id?

Damit wir aber in der, vermutlich noch längeren, Entwicklungszeit uns nicht mit solchen Problemen aufhalten müssen, ist es vermutlich einfacher, erst mal den Qisda-Weg zu gehen [nur ordentlicher] und das smdk2416-Board anzupassen.

Den noch zu entwickelnden Treibern für die Einzelkomponenten ist vermutlich recht egal, für welches Board sie nun arbeiten.

0 Kommentare Mehr...

epaper Origami

Geschrieben von MMind am Samstag, 15. Januar 2011 in E-Book Reader

Nachdem uns durch den Sourcerelease von Asus auch Quellen des Displaytreibers in die Hände gefallen sind, haben wir auch eine erste, ganz grobe Analyse dieses Treibers von Jaya Kumar bekommen. Jaya ist der Autor sämtlicher epaper-Treiber, die sich momentan im Linux-Kernel befinden — demzufolge auf dem Technologiegebiet sehr versiert.

Wenn man sich so ansieht, was er bisher mit anderen epaper-Display angestellt hat, kommt man schon ins Staunen. Besonders wenn ich die Flashvideo-Wiedergabe auf elektronischem Papier sehe, frage ich mich ob unser Sipix-epaper auch zu so etwas im Stande ist.

Auf alle Fälle ist Jaya sehr interessiert, die Portierung und Integration des Sipix-Treibers in den offiziellen Kernel zu übernehmen.

Dabei möchte er den Treiber soweit weiterentwickeln, dass dieser fähig wird einen XServer zu unterstützen sowie die norman fbdev-APIs nutzt statt der Qisda-eigenen IOCTL-Schnittstelle.

0 Kommentare Mehr...

Quellcodes des Asus eeeReader DR-900 veröffentlicht

Geschrieben von MMind am Montag, 10. Januar 2011 in Asus DR-900

Heute war es also soweit. Asus hat einen großen Packen Quellcode zu ihrem eeeReader veröffentlicht. Mit 550MB ist dass auch ein ganz schönes Schwergewicht.

Ersteindruck

Hier reicht im Prinzip ein Wort OpenEmbedded. Wenn man, wie ich, aus der Debian-Ecke kommt ist so eine OpenEmbedded-Umgebung schon ziemlich erschreckend. Für den passenden "Rant" zum Thema verweise ich einfach mal auf einen Artikel von Andy Green - einem ehemaligen Openmoko-Entwickler - dessen Meinung über Cross-Build-Umgebungen im Allgemeinen ich voll und ganz teile.

Kommen wir jetzt aber zu den Quelltexten.

The Good

Erfreulich ist auf alle Fälle das nicht nur der Kernel sondern auch große Teile des Systems im Quelltext vorliegen. Es gibt sogar so eine Art Anleitung wie man daraus ein Image gebaut bekommt.

Auch die von uns sehnlichst erwarteten Quelltexte für auofb.o und epaper.o sind dabei. Sogar das QtEmbedded-Plugin zur Ansteuerung des Displays ist enthalten.

The Bad

Den Treiber für den WLan-Chip, irgend ein Marvell 8xxx, gibt es nur als vorkompilierte Objekt-Datei. Kann uns im Prinzip aber egal sein, da er scheinbar auch vom libertas-Projekt unterstützt wird.

Mehr schlechtes gab es beim ersten Drüberschauen gar nicht zu finden.

The Ugly

OpenEmbedded halt :-) . Aber die Wahl der Entwicklungsumgebung ist ja eher so eine Art Glaubensbekenntnis. Entwickler die sich damit hinreichend auskennen, werden vermutlich auch funktionierende Ergebnisse produzieren. Aber für mich wäre das definitiv nichts.

Ausblick

Asus leistet sich ja einen eigenen GPL-Compliance-Beauftragten und irgendwie merkt man das auch. Es ging alles etwas flotter und musste nicht erst noch beschafft werden.

Sobald der DR-900 also hier erscheint darf er bei mir einziehen. Und kann dann hoffentlich auch zügig mit einem Debian bestückt werden.

5 Kommentare Mehr...

Auf die Größe kommt es an

Geschrieben von MMind am Freitag, 7. Januar 2011 in E-Book Reader

So, während einige sehr interessante Dinge im Hintergrund laufen und hoffentlich bald Früchte tragen, will ich heute mal meine Gedanken zur idealen Größe eines Readers vorstellen.

Momentan gibt es eBook-Reader mit entsprechender Displaytechnologie in den Größen 5, 6 und seltener auch 9 Zoll. Über die ideale oder auch ausreichende Displaygröße gehen die Meinungen aber weit auseinander.

Vor dem Kauf des Oyo war ich mir nicht mal sicher, ob es sich auf einem 6-Zoll-Display überhaupt komfortabel lesen lässt oder ob ich lieber gleich auf einen 9-Zoll-Reader warten soll. Deswegen habe ich mir maßstäbliche Modelle von beiden gebastelt, um eine ungefähre Vorstellung davon zu bekommen, wie groß die entsprechenden Displays überhaupt sind.

Mockups eines 6 und eines 9 Zoll Readers

Nachdem ich den Oyo jetzt schon eine ganze Weile nutze, kann ich auch ein kleines Fazit für mich ziehen. Um abends im Bett einen Roman zu lesen, ist der Oyo ideal. Er ist klein, handlich, leicht und die Displaygröße ist dafür vollkommen ausreichend. Trotz dessen warte ich händeringend auf das Erscheinen des Asus DR-900, denn ich möchte einen eBook-Reader nicht nur zur Zerstreuung nutzen, sondern auch für ernsthaftere Dinge.

Ich studiere Informatik an der Fernuni-Hagen. Dabei kommt es oft vor, dass Dokumente nicht in gedruckter Form zu einem kommen, sondern als PDF. Diese sind im Allgemeinen im Format A4 und enthalten Diagramme, Bilder und vor allem Formeln. Dabei gibt jede noch so gute Reflow-Funktion auf.

Das heißt, für einen derartigen Einsatzzweck halte ich 6-Zoll-Displays für ungeignet und lese momentan auch weiterhin am Bildschirm, bis der Asus-Reader auf meinem Schreibtisch liegt.

Nicht zu vergessen mein Fern-/Bastelziel für den Asus-Reader - ein dynamisches Notenblatt. Als Gelegenheitssaxophonspieler stelle ich mir das interessant vor, wenn mein Notenblatt mir zeigt, wo ich bin, und vor allem selbstständig umblättert. Ganz zu schweigen von der besseren Lesbarkeit der Noten im Vergleich zu handgeschriebenen.

Idealerweise hat man also zwei Reader - einen kleinen und einen großen. Ist ja auch kein Problem - wenn man den Tablet-Hype links liegen lässt, hat man das Geld, sich drei oder noch mehr Reader zu leisten :-) .

0 Kommentare Mehr...

Entwicklerbasis

Geschrieben von MMind am Mittwoch, 5. Januar 2011 in E-Book Reader

Heute habe ich mal einen Versuch unternommen unsere Entwicklerbasis etwas zu vergrößern. Dazu habe ich die Gerätefamilie auf der Mailiingliste der Linux-Driver-Projects vorgestellt.

Das Linux-Driver-Project hat es sich zur Aufgabe gemacht, wie es der Name bereits suggeriert, Hardwaretreiber für den Linuxkernel zu entwickeln. Eigentlich richtet sich diese Angebot primär an Hardwarehersteller, damit Treiber für deren Geräte den Weg in den Hauptkernel finden. Ich hoffe aber auch für unser kleines Projekt vieleicht den ein oder anderen weiteren Entwickler dort zu finden.

Hier kann ich dann gleich den Bogen zu Ingolfs Kommentar spannen. Ich persönlich möchte keine Spenden. Falls aber einer von euch einen defekten oder nicht mehr gewollten Oyo besitzen sollte, könntet ihr vieleicht über eine Hardwarespende nachdenken. Diese könnten wir dann an interessierte Kernelentwickler verteilen damit diese nicht im Nebel stochern müssen sondern ihre Entwicklungen testen können. Ein funktionierendes Display ist dabei gar nicht notwendig.

0 Kommentare Mehr...

Seite 2 von 3, insgesamt 13 Einträge

Suche

Nach Einträgen suchen in Outside the Walled Garden:

Das Gesuchte nicht gefunden? Gib einen Kommentar in einem Eintrag ab oder nimm per E-Mail Kontakt auf!