Der Oyo im Embedded Journal
Geschrieben von MMind am Mittwoch, 27. August 2014 in Oyo
Das Embedded Journal ist in der Selbstbeschreibung »Eine Open-Source Zeitschrift zum Mitmachen!« und wird von der Embedded Projects GmbH aus Augsburg herausgegeben. Die Artikel und das gesamte Heft stehen dabei unter einer Creative-Commons-Lizenz und werden von verschiedenen Autoren eingereicht. Auch der Vertriebsweg ist interessant. Die Ausgaben sind zum einen natürlich im Netz erhältlich und zum anderen auch als Papierversion.
Thematisch dreht sich alles um Embedded-Ideen im weitesten Sinne — von Elektronik-Bastelanleitungen bis zu Beschreibungen Embedded-Projekten.
Im letztgenannten Bereich habe ich mich auch mal beteiligt, wie an den Oyo-3G-Innereien auf dem Cover der Ausgabe 21 zu sehen ist. Der Artikel geht den Weg von einer Beschreibung des Oyos und seiner Komponenten über die bisherige Entwicklung bis hin zum extrem wichtigen Anwendungsfall ScummVM und ist damit neben diesem Blog meine erste richtige Veröffentlichung.
Das nächste Großprojekt - der S3C24XX-DMA-Controller
Geschrieben von MMind am Sonntag, 21. April 2013 in E-Book Reader
Nachdem die Erneuerung des Interrupt-Controllers ja nun abgeschlossen ist, folgt gleich das nächste Großprojekt — der DMA-Controller der S3C24XX-Prozessoren.
Was ist DMA
DMA steht für Direct Memory Access und soll helfen die Übertragung von Daten vom Arbeitsspeicher zu Geräten (und zurück) zu beschleunigen.
Der einfache Weg, Daten zwischen diesen auszutauschen nennt sich PIO — Programmed Input/Output. Dabei liest der Prozessor die zu übertragenden Daten häppchenweise aus dem Speicher und schreibt sie in spezielle Register des Gerätes. Gerade diese Häppchen-Arbeitsweise macht das ganze zum einen langsam und erfordert zum anderen auch eine ständige Beteiligung des Prozessors.
Hier setzt nun DMA an, indem es einen Kommunikationsweg zwischen Sender und Empfänger ohne Beteiligung des Prozessors bietet. Hier wird dem DMA-Controller nur noch mitgeteilt, welchen Speicherbereich er zu welchem Ziel übertragen soll. Nach dem Start der Übertragung hat der Prozessor mit dieser nichts mehr zu tun und kann andere Aufgaben erledigen. Nach dem Ende des Transfers wird er über einen Interrupt darüber benachrichtigt und kann dann an der entsprechenden Position weitermachen.

Aktueller Zustand
Wie bei fast allen anderen Subsystemen auch, gab es im ARM-Bereich auch bei den DMA-Controllern die Tendenz, dass jeder seine eigene Schnittstelle zwischen Gerätetreibern und DMA-Controllern kreierte — so ist der aktuelle DMA-Treiber der S3C24XX-Prozessoren in den Jahren 2003 bis 2006 entstanden — und seit dem auch nicht mehr großartig verändert worden.
In dieser Konstellation bieten natürlich nur Treiber DMA-Funktionalität, die speziell für diese Controller-Schnittstelle angepasst geschrieben wurden. Im ARM-Bereich ist dies oftmals möglich, da die Prozessoren meist spezielle Peripheriegeräte mitbringen die auch nur in diesen Prozessoren vorkommen. Schwierig wird es mit solchen privaten Schnittstellen dann, wenn sich wirklich mehrere Prozessoren dieselben Geräte teilen — so teilen sich die S3C24XX Prozessoren zum Beispiel einige wenige Geräte mit neueren Samsung-Prozessoren bis hin zum aktuellen Exynos.
DMAEngine
Seit 2006 hat sich aber auch das DMAEngine-Framework von Intel als die hardwareunabhängige Lösung für DMA-Transfers etabliert. Dort implementieren die Hardware-Treiber nicht mehr den gesamten Transfer sondern nur noch die wirklich hardwarespezifischen-Einstellungen des DMA-Controllers.
Interessanterweise gibt es zwar eine recht gute Dokumentation zur Nutzung der DMAEngine in Treibern, aber keine zum Schreiben von DMAEngine-Treibern. Es bleibt also beim Lesen von Code-Kommentaren um die Funktionsweise zusammen zu puzzeln.
Der Kernel 3.10 wird gigantisch
Geschrieben von MMind am Montag, 15. April 2013 in E-Book Reader
Das Release des Kernel 3.9 nähert sich mit großen Schritten und wenn ich meinem Patch-Tracker glauben darf, wird der folgende 3.10 mein volumenstärkster Kernel bisher. Die dortige Statistik sagt mir:
- 48 individual patches
- 1832 lines added
- 1680 lines removed
Die 48 Patches sind also nochmal knapp 40% meiner bisherigen Kernel-Patches — schon cool. Im Einzelnen gehören dazu:
Die Restarbeiten der Interrupt-Umstellung, die ja bereits letztens erwähnt wurden (ARM: S3C24XX: irq rework for S3C2412, S3C2440 and S3C2442, ARM: S3C24XX: integrate special s3c2412 eint handling, ARM: S3C24XX: more fixes and enhancements for the s3c24xx irqs).
Die DeviceTree-Unterstützung für die Interrupt-Controller war dann doch nicht ganz so trivial und weckte etwas Diskussionsbedarf — wie an der Menge der Revisionen gut zu erkennen ist. Jetzt nach allen Änderungen muss ich aber auch sagen, dass die Devicetree-Syntax für die Interrupt-Controller deutlich besser gworden ist, als mein erster Versuch.
Der Rest ist dann im Vergleich dazu eher Kleinkram. Der Oyo-Display-Controller bekommt die Fähigkeit die Anzeige zu rotieren und den Anwendungen 16bit vorzugaukeln, da nicht alle Anwendungen mit einem palettenbasierten Display zurechtkommen. Der Oyo-Touchscreen bekommt Devicetree-Unterstützung. Und dann gibts da noch ein paar weitere Kleinigkeiten in anderen Teilen.
Nach Ladenschluss
Momentan läuft die vermutlich letzte Woche des Entwicklungszyklus von 3.9. Das heißt, alle Features für das Merge-Window von 3.10 müssen jetzt bereits linux-next erreicht haben. Leider bedeutet dies auch, dass einige meiner Patches erst für 3.11 in Frage kommen.
Dies sind der Pinctrl-Treiber für die Samsung S3C24xx SoCs und die generelle Devicetree-Unterstützung für den S3C2416.
Großprojekt beendet
Geschrieben von MMind am Donnerstag, 7. Februar 2013 in E-Book Reader
Vor ein paar Tagen kam mit der Aufnahme in den Samsung-Maintainer-Tree mein bisher größtes Restrukturierungsprojekt der älteren Samsung-SoCs zu einem vorläufigen Ende. Im Kern ging es dabei um eine Neuordnung des Codes, der die Interrupt-Controller der S3C24XX-SoCs steuert, um später DeviceTree-Unterstützung für die S3C24XX-SoCs realisieren zu können — mehr zu DeviceTree folgt in einem späteren Eintrag.
Bisheriger Zustand
Die S3C24XX-SoCs verwenden zwar den selben Interrupt-Controller, dessen innere Struktur unterscheidet sich jedoch zwischen allen SoC-Varianten. Im Endeffekt handelt es sich »nur« um unterschiedlich belegte Bits in den Registern des Controllers. Zur Verdeutlichung ein kleines Beispiel:
Bit | 0 | ... | 18 | ... |
---|---|---|---|---|
S3C2410 | EINT0 | ... | DMA1 | ... |
S3C2416 | EINT0 | ... | UART3 | ... |
Der S3C2410 signalisiert also in Bit 18 Interrupts des zweiten DMA-Kanals, während der S3C2416 dort Interrupts der vierten seriellen Schnittstelle signalisiert.
Implementiert war das Ganze dann derart, dass ein generischer Interrupt-Init die Struktur für den S3C2410 zusammenbaute und später dann eine SoC-spezifische zweite Init-Funktion, die geänderten Werte überschrieb. Diese zweite Funktion wurde über einen arch_initcall und damit zu einem gänzlich anderen Zeitpunkt gestartet.
Ein zweites großes Manko war die Festlegung auf statische Interrupt-Nummern. In arch/arm/mach-s3c24xx/include/mach/irqs.h waren den jeweiligen Interrupts feste Nummern zugewiesen und diese Nummern wurden auch durch den ganzen Interrupt-Code verstreut verwendet. D.h. es fanden sich überall Fragmente wie das folgende:
if (irq >= IRQ_EINT0 && irq <= IRQ_EINT3) ....
Dadurch kam es zu vielen Code-Dopplungen die sich nur in den verwendeten Interrupt-Nummern unterschieden.
Als drittes großes Problem ist noch das fehlen einer IRQ-Domain, welche aber für DeviceTree-Unterstützung absolut notwendig ist.
Der gesamte Prozess zog sich von Anfang November bis Ende Januar und große Teile davon entstanden auf den Flughäfen von Barcelone, Frankfurt und Hong Kong .
Neue Weltordnung
Nach dem Entfernen und Hinzufügen von 1132 respektive 688 Codezeilen stellt sich das System nun folgendermassen dar. Der gesamte Aufbau folgt nun einem deklarativen Ansatz. In einer speziellen Struktur werden die Parameter der Interrupt, also Typ und gegebenenfalls Eltern-Interrupt deklariert. Die mehrfach vorhandenen Funktionen zum quittieren, maskieren und demaskieren von Interrupts sind verschwunden und wurden durch einen einzigen Satz von Funktionen ersetzt, die ihr spezifisches Verhalten aus der Interrupt-Deklaration ableiten.
Ebenso wird jetzt für jeden der Subinterrupt-Controller eine IRQ-Domain erstellt und der vorherige zweistufige Init ist auch normalisiert.
Ausblick
Als Restarbeit müssen noch die S3C2412, S3C2440 und S3C2442 Varianten in die neue Struktur konvertiert werden. Nachdem das generelle Konzept aber angenommen wurde, ist dies nichtmehr allzu schwierig. Die eigentliche DeviceTree-Unterstützung im Interrupt-Code ist dann auch nur noch eine relativ kleine Änderung, die auch schon im Großen und Ganzen existiert und nur noch etwas Feinschliff benötigt.
Ghosting überall
Geschrieben von MMind am Montag, 19. März 2012 in E-Book Reader
Eine interessante Beobachtung vom Wochenende war auch, dass der im MediaMarkt ausgestellte Kobo-Touch ähnliche Ghosting-Effekte zeigte, wie der Oyo 2. Es bleiben also Ränder des vorherigen Textes zurück. Ein eInk-Pearl-Display ist also anscheinend auch nicht über alle Zweifel erhaben.
Stattdessen kommt es sowohl bei eInk- als auch bei Sipix-Displays hauptsächlich darauf an, wie diese von der Software angesprochen werden. So ist beim Oyo-2 das Ghosting am stärksten im Modus mit 16 Graustufen. Die Modi mit 4 oder 2 Graustufen ghosten eigentlich gar nicht. Auch scheint ein kurzzeitiger Wechsel in einen dieser Modi, die Rückstände relativ gut zu entfernen. Momentan versuchen die Thalia-Entwickler aber das Problem mit eingefügten weißen Seiten einzudämmen. Dies hilft nur bedingt und sorgt ausserdem für einen Eindruck einer sehr langsamen Software beim Benutzer.
Seite 1 von 15, insgesamt 72 Einträge