Register auslesen
Als Nächstes schreibe ich ein kleines Skript für OpenOCD, um den Inhalt der SoC-Register über JTAG auszulesen. Die folgenden OpenOCD-Kommandos zeigen zum Beispiel die Konfiguration des GPIO-Port C an:
> mdw phys 0x56000020 0x56000020: aaaa56aa > mdw phys 0x56000024 0x56000024: 0000000c > mdw phys 0x56000028 0x56000028: ffffffff
Allein mit dem Blick auf die Register gibt es schon Einiges zu entdecken. Die Registerdaten zusammen mit dem Datenblatt für den SoC helfen mir, herauszufinden, wie die Hardware konfiguriert ist.
An der Adresse 0x56000020 steht das GPIO-C-Control-Register (GPCCON). Es legt fest, wie die GPIO-Pins konfiguriert sind. Jedem Pin im Register sind zwei Bits zugewiesen. Der Wert 00 heißt, der Pin ist ein Input-Pin, 01 ein Output-Pin und 10 weist dem Pin eine spezielle Funktion zu. Die Pins 5, 6 und 7 sind als Output definiert, die übrigen mit speziellen Funktionen. Bei Port C heißt das, sie werden für die Videoausgabe benutzt. Das Register an Adresse 0x56000024 (GPCDAT) zeigt den aktuellen Zustand der Pins dieses Ports und 0x56000028 (GPCUDP) steuert aktiviert Pull-up- beziehungsweise Pull-down-Widerstände an den Pins.
Die Belegung für die Videoausgabe-Pins habe ich mir notiert:
GPC0 2 LEND Video Line End GPC1 2 VCLK Video Clock GPC2 2 HSYNC Video Horizontal Sync GPC3 2 VSYNC Video Vertical Sync GPC4 2 VDEN Video Data Enable GPC5 1 Output GPC6 1 Output GPC7 1 Output GPC8:15 2 VD[0:7] Video Data[0:7]
Ein Großteil der Pins an den Ports C und D steuert das LCD an. Indem ich die Register des Display-Controllers im SoC auslese, erhalte ich die LCD-Konfiguration: Länge des Sync-Signals, Videotaktrate und so weiter.
Mit Port A funktioniert es genauso:
> mdw phys 0x56000000 0x56000000: 0f7f6f5c > mdw phys 0x56000004 0x56000004: 00010003 > mdw phys 0x56000008 0x56000008: 00000000
Jeder Pin benutzt aber nur ein Bit in 0x56000000 (GPACON). Die 0 steht für einen Output-Pin, 1 entspricht einer Spezialfunktion.
Die Pins GPA17 bis 22 dienen zur Ansteuerung des NAND-Flash-Speichers, wie er auch auf dem Mainboard verbaut ist. Allerdings scheinen andere, wie GPA 25 und 26, weniger sinnvoll. Sie sind für eine Spezialfunktion konfiguriert. Die Pins (DQM2 und 3) sollten mit 32 Bit breiten SDRAM verwendet werden, aber der verbaute Hynix SRAM ist nur 16 Bit breit. Entweder handelt es sich dabei um die Standardkonfiguration des Chips oder der Firmware-Code enthält Überbleibsel aus früheren Versionen.
Wenn Pins als Output konfiguriert sind, ist es auch lehrreich, einfach ihren Zustand zu ändern. Schalte ich GPA1 oder GPA2, höre ich ein Klickgeräusch im Inneren des Oszilloskops. Wahrscheinlich schalten sie Relais im Analog-Frontend. Das ist praktisch, wenn mit der Zustandsänderung ein Geräusch verbunden ist, die anderen Pins muss ich dagegen durchmessen, um zu sehen, was sie tatsächlich tun.
Der erste Versuch mit Linux
Praktisch habe ich jetzt alles, was notwendig ist, um Linux für das Oszilloskop zu portieren. Mit den Registerdaten dauert es nur drei Abende, Linux auf dem Oszilloskop mit einer seriellen Konsole und einer Busybox-Shell zu starten.
Linux unterstützt den SoC und die meisten seiner Funktionen bereits. Ich werde nicht zu tief in die Details gehen, aber im Prinzip geht es allein darum, die Werte aus den Registern in die existierenden Treiber einzubauen.
Oder nutzen Sie das Golem-pur-Angebot
und lesen Golem.de
- ohne Werbung
- mit ausgeschaltetem Javascript
- mit RSS-Volltext-Feed
Flash-Speicher auslesen | Trotzdem ist es nicht ganz einfach |
+1 Mehr davon und ich abonniere auch. Und wie laoladabamba sagt, die Weltraumartikel...
Aber ehrlich. Wenn's nur News über neue Grafikkarten gibt heulen die selben Leute über...
ich seh das ja auch immer mit einem zwinkernden Auge. Entwickler sollen entwickeln und...
Die Chancen dass es ein Linux ist sind relativ gross. Würde es mich interessieren hätte...
Hier kann man mal sehen, was Fachkraft wirklich bedeutet. *Davon* haben wir zu wenige.