Linux 3.0
Geschrieben von MMind am Dienstag, 31. Mai 2011 in Oyo
Nachdem es der Treiber für den USB-Device-Controller in diesem Merge-Window in den Hauptkernel geschafft hat, habe ich heute mal das update des Oyo-Kernels in Angriff genommen. Der Kernel basiert jetzt also auf Linux 3.0rc1
Abgesehen von der gewöhnungsbedürftigen neuen Nummerierung ging das Update eigentlich relativ problemlos vonstatten. Hier zahlte sich auch der Einsatz von topgit aus. Nacheinem einfachen tg update war der Unterbau meiner Topic-Branches und damit auch gleich die späteren Upstream-Patches aktualisiert.
Ein paar kleine Fehler haben sich anscheinend bei einem groß angelegten Update des Power-Managements eingeschlichen. Diese muss ich jetzt also noch bereinigen und wieder in Richtung der Kernel-Entwickler schieben.
Auch der zweite HSMMC-Kanal hat scheinbar einen Schnupfen entwickelt und wirft Unmengen irgendwelcher IRQ-Meldungen. Ich hab ihn jetzt einfach erstmal deaktiviert, da beim Oyo die SD-Karte eh am ersten Kanal hängt. Bis ich so einen Asus DR-900 besitze, sollte ich das Problem aber schon noch finden, da dort die MMC-Kanäle vertauscht sind.
Communicating with the AUO-K1900
Geschrieben von MMind am Dienstag, 17. Mai 2011 in Oyo
Sorry, wieder in Englisch — aber die Zielgruppe des Artikels ist im deutschsprachigen Raum eher klein 
Last time I described the raw interface between the host and the K1900. Today I want to describe how this interface is used when talking to the K1900.
The i80 interface supports two modes of operation — command mode and a mode for display data.
The command mode is used as the name implies to send commands to the controller. These contain for example init, refresh and reset commands. The display mode is used to send frame data from the framebuffer to the controller.
Missing an i80 bus driver
The i80 bus seems to be some sort of cross of I2C and SPI. The addressing of the target device is done via chip-selects like in SPI but the communication seems to be more similar to I2C.
Messages to send over i80 could be described like the following struct:
{
{ WC, 6001 }, //write-control
{ WD, 576 }, //write-data
{ WD, 12 }, //write-data
{ RD, buf } // read-data
}This should access register 6001, write 576, write 12 and get a return value put into buf.
As the headline implies the Linux kernel is currently missing support for i80. Therefore it seems an i80 bus-driver made it onto my todo-list too.
Concurrency issues
The two modes of access also create concurrency problems, show in the following diagram:
A semaphor or similar structure is needed to prevent one driver from getting to the i80 bus while it is occupied by the other driver.
Real-life example
To illustrate how this all comes together I will describe what happens when a part of the display should be refreshed from the framebuffer.
The following command starts the display update and describes to the display which region should be updated:
{
{ WC, PRE_DISP_START }, //write-control
{ WD, x }, //write-data
{ WD, y }, //write-data
{ WD, width }, //write-data
{ WD, height }, //write-data
}The followin part is specific to the S3C SoC and may look different on other SoCs. The region to send has to be marked. On the S3C2416 the specific region is copied to a memory region and the VIDWW00ADD* registers are used to declare its position and size to the i80 part of the framebuffer.
Now the ENVID/ENVID_F bits of VIDCON0 are set to binary-11. This enables the lcd logic and the frame-data is sent via the i80 bus to the K1900. After this single frame the lcd logic is deactivated again. And another command is sent to the K1900 which marks the end of the data transmission.
{
{ WC, PRE_DISP_STOP }, //write-control
}After this the K1900 updates the named region with the sent data.
The grayscale part is strange thing happening in the original framebuffer. It presents a normal color framebuffer to the user-space and converts it internally to gray levels. I'm not sure if this is necessary, or if the framebuffer can also be completly grayscale.
SPI interface
The K1900 also has a SPI interface alongside the i80 one, but it seems to only be used to access the flash storage attached to it. At least it's not documented and also not used in the upstream code we have.
Documenting the K1900 interface
Geschrieben von MMind am Sonntag, 15. Mai 2011 in Oyo
This time in english to keep as reference for whoever may need it.
As written last time, the K1900 uses the I80 interface of the S3C2416. This interface is also present on the following SoCs [S3C64xx, S5Psomething] in an improved version where the S3C2416 only has the so called "manual command mode".
The connection between the I80-pins of the S3C and the K1900 are as follows:
| PIN | S3C (SIFCCON0) | K1900 |
|---|---|---|
| Command mode enable | SCOMEN | ---- |
| Chip-Select | nCS0 | CSEL |
| Register/State switch (where to write to) | SYS_RS | DC |
| Write enable | nWE | HWE |
| Read enable | nOE | HRD |
| Data | SIFCCON1/2 [17:0] | DBUS[15:0] |
Settings are made in the SYSIFCON / I80IFCON register. The data exchange is then handled via the SIFCCON[0,1,2] registers. SIFCCON0 controls the connection, SIFCCON1 contains the data to send to the K1900 and SIFCCON2 contains the data received from the K1900. Data is transmitted through setting the SIFCCON0 bits in the right sequence and combination:
| RS | nOE | nWE | Function |
|---|---|---|---|
| 0 | 0 | 1 | Write command to register |
| 0 | 1 | 0 | (read register - not used) |
| 1 | 0 | 1 | Write data (params) |
| 1 | 1 | 0 | Read data (return values) |
Sending a command to the K1900 therefore follows along this path:
- command mode enable
- nCS0 enable
- send command
- RS low
- nWE enable
- write command to SIFCCON1
- nWE disable
- RS high
- optionally send parameters
- nWE enabled
- write value to SIFCCON1
- nWE disabled
- optionally read returned values
- nRD enabled
- read value from SIFCCON2
- nRD disabled
- nCS0 disable
- command mode disable
kleine Tintenkleckse
Geschrieben von MMind am Sonntag, 15. Mai 2011 in Oyo
In den letzten Tagen habe ich begonnen, mich etwas mit dem Display-Controller der Reader zu beschäftigen.
Der AUO-K1900 ist ein sogenannter FPGA (Field-programmable-Gate-Array), der von SiliconBlue hergestellt wird. FPGAs sind im Prinzip eine Sammlung von Schaltungselementen, deren Funktion erst später durch eine Konfiguration festgelegt wird und auch später noch änderbar ist.
Ist-Zustand
Wie alle anderen Teile des Original-Kernelcodes, sieht auch der Displaycode wüst aus. Im Prinzip wurde nichts anderes getan, als den Framebuffer-Treiber für den S3C2416 zu kopieren und das Display-Interface hinein zu hacken. Herausgekommen sind dabei stolze 242KB Quelltext.
Der erste Schritt war also, den ganzen Mist, der eh nie wieder benötigt wird, raus zu werfen. Danach habe ich versucht die ganzen ähnlichen Codeblöcke zusammenzufassen — also so in Funktionen auszulagern, dass das Funktionsprinzip besser erkennbar wird.
So ist die schiere Masse an Code schon mal auf 120KB zusammengeschrumpft und es lässt sich überblicken, was dort eigentlich passiert.
Das Interface
Das Interface zwischen Host-Framebuffer und dem K1900 wird meist »Intel 8080-like I80 interface« genannt. Allgemeinere Dokumentation dafür zu finden ist scheinbar fast unmöglich und es scheint im Umfeld des Linux-Kernels bis jetzt auch noch nicht verwendet worden zu sein. Es ist vom Aufbau aber auch nicht so dramatisch, denn es werden einfach nacheinander ein Kommando und gegebenenfalls ein paar Parameter übertragen.
Interessanter wird schon werden, dem aktuellen s3c-fb beizubringen bei Änderungen des Framebuffers, diese automatisch an den K1900 zu übermitteln. Im Originalcode wurde dieses Update ja von der Anwendungssoftware ausgelöst.
Und an die notwendige Konvertierung der RBG-Farben in Graystufen möchte ich noch gar nicht denken
Zukünftiges Bastelobjekt
Geschrieben von MMind am Freitag, 6. Mai 2011 in Geräte
Ein interessantes Projekt von dem ich heute gelesen habe ist der Raspberry Pi — ein sehr kleiner Stick-Computer der sich vornehmlich an Schüler richtet.
Früher — auch in meiner Jugend — waren die »Heimcomputer« ja meist die Domäne des Nachwuchses. Eltern hatten damit im Allgemeinen wenig am Hut. Das heißt man konnte als Kind nach Herzenslust herumprobieren ohne Rücksicht auf andere Nutzer. Heutzutage hat der Familiencomputer meist mehr Nutzer — zum Beispiel zum Online-Banking oder -Einkauf. Das heißt wenn er dann kaputtgespielt ist, hängt der Haussegen schief.
Hier soll der Raspberry Pi ansetzen und eine ungefährliche Bastelumgebung liefern. Im Idealfall soll er an Schüler verschenkt werden — bei einem Preis von 17EUR wäre er aber auch erschwinglich. Durch Ausstattung mit einem HDMI-Anschluss und einem USB-Port fehlt nur noch ein Fernseher und eine Tastatur um ihn nutzen zu können. Für Hardwareexperimente scheint auch ein spezieller Port eingeplat worden zu sein.
Seite 1 von 1, insgesamt 5 Einträge
