Zwischenfazit zum Toshiba AC100

Geschrieben von MMind am Sonntag, 30. Januar 2011 in Toshiba AC100

So, ein Debian läuft erstmal — und das auch eigentlich ganz zügig sogar mit einer KDE als GUI. AC100 mit Debian Squeeze und einer KDE In meinem aktuellen Setup verwende ich ein Debian-Squeeze (Testing) sowie einen Kernel 2.6.29 (im 2011-01-16-Verzeichnis) der auf dem Toshiba-Kernelcode basiert. Wie auf dem Foto zu sehen, funktionieren die grundlegenden Sachen. Der WLan-Chip will noch nicht so richtig und an die über den einfach Framebuffer hinausgehende Unterstützung des Grafikchips braucht man auch erstmal gar nicht zu denken.

Ansonsten läuft das System aber angenehm zügig und für den primären Verwendungszweck als Buildhost ist auch alles Notwendige vorhanden.

Kernel-Situation

Während der letzten Tage habe ich mich auch etwas in die aktuelle Situation rund um den Kernel eingelesen.

Es gibt von Toshiba verschickte Kernelquellen, basierend auf einem 2.6.29er Kernel. An diesem Kernel haben dann einige Entwickler weiter rumgebastelt — das Ergebnis ist auf gitorious zu besichtigen.

Daneben gibt es noch den Versuch den AC100-Code (Codename ist paz00) auf einen aktuelleren Kernel zu portieren. Zur Zeit ist dies ein 2.6.36.

Das Hauptproblem ist momentan die komplett umgebaute Tegra-Architektur in neueren Kerneln, die nur noch recht wenig dem Code im Toshiba-Kernel ähnelt. Dabei ist fehlt unter anderem auch der Code des »Embedded Controllers« komplett, der für so unwichtige Sachen wie Tastatur- und Trackpad-Unterstützung verantwortlich ist. Es gibt in marvin24s-kernel zwar bereits ein Grundgerüst für den nvec-Treiber, es muss aber noch ein Entwickler diesen »stub« mit Code befüllen. Bei meinem ersten heutigen Versuch mit dem 2.6.36 hat er auch nicht mal die SD-Karte gefunden.

Wie weiter?

An dieser Stelle wäre es schön den AC100 so richtig zum mobilen Begleiter hochzurüsten — also Toshibas Werbespruch mit Leben zu füllen. Die Tegra2-Plattform selbst fühlt sich nämlich richtig flink an. Beim Design der Hardware möchte ich mich auch direkt Engadget anschliessen, die den AC100 als »downright sexy« bezeichnet haben — er sieht schon richtig schick aus.

Es scheint aber so, dass Toshiba den AC100 bereits abgeschrieben hat. Es gibt (vermutlich »gab«) auch ein Blog von Toshiba zum AC100 auf dem sich aber seit Mitte Dezember nichts mehr getan hat. Auch in den eigenen Foren hüllt sich der Hersteller zu den immer wieder versprochenen Updates in Schweigen.

Da es auch so scheint, dass die Entwickler-Gemeinde, für das spezielle Tegra-Modell, recht überschaubar ist wäre es natürlich schön wenn seitens Toshiba weiterer Code nachgereicht würde, der gegebenenfalls sogar den nvec in neueren Kerneln implementieren würde.

4 Kommentare Mehr...

Debian-Pakete auf schwachen Architekturen bauen

Geschrieben von MMind am Samstag, 29. Januar 2011 in Software

Debian-Pakete sollen vor dem hochladen in das Archiv ein einer »sauberen« Umgebung gebaut werden. Im Allgemeinen ist dies ein chroot das durch pbuilder verwaltet wird. pbuilder installiert dabei Pakete, die zum bauen nötig sind in das chroot und räumt sie danach auch wieder weg. Durch die Verwendung von pbuilder, oder einem seiner Verwandten, wird sichergestellt dass alle »build-dependencies« im Paket deklariert sind und dass das Programm nicht gegen irgendwelche obskuren Bibliotheksversionen gelinkt wird, die sich gerade auf dem Host-System befinden.

Schwachen System

Ganz offensichtlich führt schon die geringere Rechenleistung zu sehr langen Kompilationszeiten, sofern nicht vorher der meist ebenfalls geringe Arbeitsspeicher die Kompilation abbricht.

Ein weiteres Problem bereitet der Flash-Speicher, der meist in Embedded-Systemen verwendet wird. Der pbuilder packt für jeden build-Vorgang sein chroot aus, installiert weitere Pakete dort hinein, kompiliert das Programm und räumt schließlich alles wieder weg. Dadurch erzeugt er eine Unmenge Schreibvorgänge, die den Flash-Speichern sehr zusetzen.

Qemubuilder

Qemubuilder startet eine virtuelle Maschine der Zielarchitektur und führt den pbuilder in dieser aus. Das Problem ist nur, dass dies im Allgemeinen noch langsamer vonstatten geht als das direkte Bauen auf dem Gerät.

qemu-user

Via Jabber kam noch der Einwurf, man könnte auch qemu selbst verwenden. qemu-user ermöglicht es, einzelne Programme als andere Architektur auszuführen. Man müsste also ein armel-chroot erstellen, dort hineinwechseln und könnte dann den armel-pbuilder aufrufen. Die entsprechenden qemu-Binaries kümmern sich dann um das Ummodeln der armel-Instruktion in welche für x86. Hab ich heute also wieder was gelernt :-) .

Meine Lösung

Ich habe mich dann einfach dafür entschieden meiner Sammlung von ARM-Geräten eines hinzuzufügen, dass Pakete in einer annehmbaren Geschwindigkeit bauen kann — eben der Toshiba AC100.

Eigentlich dachte ich vorher eher an einen SheevaPlug, den Ausschlag für den AC100 gab dann aber der Umstand dass er das tollere Spielzeug ist und weitere Nutzungsmöglichkeiten ausser dem buildhost-Dasein bietet.

Da er auch einen USB-Host-Port besitzt kann ich auch das Flash-Abnutzungproblem vermeiden indem ich einfach eine USB-Festplatte als Medium für den pbuilder nutze.

0 Kommentare Mehr...

Noch ein Spielzeug

Geschrieben von MMind am Donnerstag, 27. Januar 2011 in Geräte, Toshiba AC100

Beim (Abverkaufs-)Preis von 200 EUR konnte ich dann nicht widerstehen und hab mir noch ein Spielzeug zugelegt — einen Toshiba AC100.

Toshiba AC100 vor Thinkpad R500
der Kleine im Vordergrund

Die Hardware ist ein NVida Tegra, das heißt auch ARM-basiert, mit einem Cortex A9 1GHz Dual-Core ARM7-Prozessor. Dazu 512MB Arbeitsspeicher und 8GB Flash. Besonders interessant: das Gerät hat überhaupt keine beweglichen Teile — auch keinen Lüfter — was dafür sorgt dass er keinerlei Geräusche von sich gibt.

Warum aber irgendwer auf die Idee gekommen ist dort ein Android drauf zu tun erschließt sich mir nicht, denn das funktioniert rein gar nicht, da die Bedienkonzepte eigentlich viel zu verschieden sind.

Es soll mich aber auch nicht weiter stören, da der Kleine dann sowieso ein Debian verpasst bekommt. Es gibt da so einige Projekte und Resourcen, die sich damit beschäftigen dem AC100 ein ordentliches Betriebssystem zu verpassen.

Aber was will ich eigentlich mit dem Gerät? Es soll, dank seiner ARM-Architektur, eine ganz spezielle Lücke füllen, die in Verbindung mit den anderen Geräten ensteht und über die ich nochmal getrennt schreiben werde. Und ansonsten ist die Kiste mit seinen 3-6W Stromverbrauch einfach mal ziemlich sparsam und sollte demzufolge ziemlich lange durchhalten.

0 Kommentare Mehr...

Das Innenleben des USB-Gadget-Treibers

Geschrieben von MMind am Dienstag, 25. Januar 2011 in Oyo

Wir sind ja momentan noch dabei den USB-Gadget-Treiber zum Laufen zu bringen. Deswegen habe ich heute mal versucht herauszufinden was sich überhaupt geändert hat auf dem Weg von smdk2416 zu Oyo und Verwandtschaft.

Kernelversionen

Der Oyo-Kernel basiert ja auf einem Fork des Kernels 2.6.21.5, der um die Unterstützung für die s3c-SoCs erweitert wurde, und dann von Qisda-Entwicklern so verbastelt wurde, dass er auf den Oyo passt.

Um vernünftige Vergleiche anstellen zu können benötigt man natürlich einen originalen s3c-linux-Abzug. Leider konnte ich bis jetzt keinen solchen finden ausser als Teil eines Linux-Cross-Reference-Projektes.

Der s3c-linux-Quelltext der dort verzeichnet ist, hat die Samsung-Version 4-3-0 vom 29.4.2008. Der Oyo-Kernel basiert hingegen auf der Version 4-6-0 vom 28.7.2008. Aber hoffentlich haben sich die 3 Monate Entwicklungszeit nicht zu sehr im USB-Gadget-Treiber niedergeschlagen.

Die Inhalte aus dem Cross-Reference-Projekt sind leider auch html-isiert und mit Zeilennummern versehen. Aber das Speichern der gerenderten Seite kombiniert mit etwas sed-Magie konnte auch dieses Problem lösen.

sed -E 's/^[0-9]+ //' s3c-udc-hs.c | sed -E 's/^ [0-9]+ //' | sed -E 's/^ [0-9]+ //' > s3c.c

Der Vergleich

Mein erster diff gegen das Oyo-Pendant der s3c-udc-hs.c fiel sehr ernüchternd aus, da im Oyo-Kernel so viel rumgeschmiert wurde, dass eigentlich kein ordentlicher diff möglich ist.

Der Kernel vom Asus DR-900 hingegen sieht eigentlich sehr aufgeräumt aus und produziert damit auch einen ganz übersichtlichen diff.

Mein Problem ist nun aber noch zu verstehen was dort eigentlich passiert :-) . Falls also ein fachkundiger Kernelentwickler zufällig hier vorbeischaut, habe ich meine diffs mal in einem Archiv bereitgestellt udc-diff.tar.gz.

Kleines Update

Ich habe jetzt bei den OpenEmbedded-Entwicklern Quellen zu einem aktuelleren s3c-linux gefunden. Dies ist zwar neuer als Unseres aber der s3c-udc-hs-Treiber ist scheinbar die selbe Version wie in den Oyo/Asus-Quellen.

Ich habe das Archiv mit neueren Diffs aktualisiert, sodass die eigentlichen Änderungen noch besser zu sehen sind.

0 Kommentare Mehr...

GPIObusters

Geschrieben von MMind am Donnerstag, 20. Januar 2011 in Oyo

Die sogenannten »General Purpose Input/Outputs« sind freie Pins eines Chips die mit relativ beliebigen Zielen verbunden sind und dann softwareseitig manipuliert werden können. Dabei variiert die Signalrichtung je nach Anwendungsfall. Das heißt Input-Pins liefern entweder eine 0 eine 1 im Kernel ab, je nachdem was das Verbindungsziel gerade tut und Output-Pins werden im Kernel mit einem ebensolchen Wert gesetzt um zum Beispiel Sachen ein- bzw. auszuschalten.

Eben diese GPIOs jage ich jetzt die letzten Tage verstärkt um unser Portierunternehmen etwas voranzubringen. Die Ergebnisse lagern in einer speziellen Wiki-Seite.

Wenn aber bei der Suche nach den GPIOs durch den original Kernelquelltext von Oyo und Asus-Reader kriecht, sieht man Dinge die man eigentlich nie sehen wollte. Mit der Tatsache dass Teile der Ladelogik im Keypad-Treiber stecken hatte ich mich inzwischen abgefunden. Aber WLan-ioctls im hsmmc-Treiber untergebracht — irgendwann muss doch der Tiefpunkt mal erreicht sein :-) . Mich würde es an dieser Stelle nicht mal mehr wundern, wenn die Qisda-Mitarbeiter über den Kernelcode auch Kochrezepte getauscht hätten.

Aber etwas gutes hat die Sucherei dennoch — mit etwas Glück habe ich die Ursache unseres nicht funktionierenden USBs gefunden. Dort war der Stand, dass alles geladen wurde, sich aber trotzdem nichts tat. Denn am GPIO GPB4, den der smdk2416-Code zum ein- und ausschalten des Ports nutzt, hängt bei uns ein Teil des Ladechips.

0 Kommentare Mehr...

Seite 1 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!