So. Es ist wieder einmal passiert. Ich habe mir Hardware zum Spielen gekauft.
Diesmal: Ein FreeAgent DockStar Network Adapter von Seagate.
Das Schätzchen hat 128MB Ram und 256MB Flash on Board, eine nette ARM CPU, Gigabit-Netzwerk und 4 USB-Ports. Details finden sich zu Hauf im Netz.
Was mich besonders interessiert hat, war die in der CPU vorhandene Crypto-Unit, die sha1, md5 und aes in Hardware berechnen kann.
Linuxkernel
Leider ist es mit der Unterstützung dieser Einheit im offiziellen Kernel noch nicht so wahnsinnig weit - bisher wird das ganze nur rudimentär angesprochen (z.B. kein DMA), so dass es nicht wirklich Spaß macht, das ganze zu nutzen. (1-2MB/s Gewinn)
Etwas mehr verspricht hier ein Kernel des Herstellers - und voilá, GPL-sei-dank gibt es da auch was passendes. Oder naja, etwas das man für passend halten kann.
Vorweg: Ja, ich habe den Kernel letztlich übersetzt bekommen, man darf nur nicht so wahnsinnig sein, und an der config großartig Dinge ändern wollen - weil dann knallt es. Und zwar richtig mit Compiler-Fehlern und Syntax-Errors in den Kernelquellen.
Letztlich habe ich jedenfalls 15MB/sec von einer verschlüsselten USB-Platte lesen können statt 6-7 ohne Hardwareunterstützung.
Details zum Kernel folgen, sobald ich einen stabilen build habe und das dokumentieren kann. Ausserdem will ich die LEDs aus dem Kernel heraus ansprechen können, die GPIO-Konfiguration habe ich im Prinzip bereits.
uBoot - der Bootloader
Damit ich dieses System bequemer booten kann, wollte ich dann einen neuen uBoot bauen.
Die Cross-compiler-chain war ja schon von kernel vorhanden - sollte also alles kein Problem sein. Dachte ich.
Die Konfiguration des DockStar unterscheidet sich leider etwas von der des Sheeva-Plugs. So ist nur die Hälfte des Rams vorhanden, ausserdem sind die beiden LEDs an andere GPIO-Pins angeschlossen.
Kaputtgeflasht
Was mir letztlich das Genick brach war aber ein dummer Fehler: Ich habe das uBoot-Binary direkt in den Flash des DockStar gebrannt - statt des kwb-Images, das die Hardwarekonfiguration enthält.
Letztlich habe ich nun 4 verschiedene Jtag-Adapter hier gehabt, davon zwei selbstgebaute. Der letzte, ein wiggler, funktionierte schließlich - wenn auch nur mit 50kHz statt 500. (Kabellänge)
Folgende Fallen begeneten mir dabei:
- 74HC244 falschrum im Sockel. Gute Heizwirkung, der Chip hats überlebt, mein Zeigefinger auch...
- Kabel zu lang und zu wenig abgeschirmt
- Ein funktionierender DockStar hat das JTAG deaktiviert und ist zum Testen ungeeignet!
Vor allem der letzte Punkt mit dem funktionierenden DockStar hat mich etliche Stunden gekostet. Aber wer rechnet schon damit -.-
Ausblick
Die folgenden Posts werden ausführlich das Wiederbeleben des DockStars, die korrekte Konfiguration des Bootloaders für diese Plattform und die Konfiguration des Kernels enthalten.
Der Bootloader kann hier jedenfalls schon die LED's ansprechen, dem Kernel werde ich das wohl auch noch beibringen. TODO's sind aber noch die Konfiguration des Speichers im uBoot.
4 Kommentare:
Was für einen JTAG hast Du verwendet? Ich sollte meine Dockstar auch neu flashen, habe jetzt schon den dritten JTAG Adapter gekauft und mit keinem komm ich auf den Dockstar
Ich habe nach etlichen Versuchen mit anderen Adaptern einen WIGGLER nachgebaut. Musste mir dann zwar noch einen Rechner mit Parallelport suchen, aber der funktionierte dann, wenn auch teilweise nur mit runtergesetzter Geschwindigkeit, wenn ich mich richtig erinnere.
Bei mir klappt das irgendwie nicht...
Habe ein paar JTAG Adapter versucht, inkl. einen gekauften WIGGLER und einem selbst gebauten.
Immer das gleiche bekomme keine Verbindung zum Dockstar. Was komisch ist, beim selbstgebauten kommt die Meldung: Error: JTAG scan chain interrogation failed: all ones
Und bei dem gekauften: Error: JTAG scan chain interrogation failed: all zeros
Habe es auch schon mit einem GoFlex Net und einem weiteren Dockstar versucht immer das gleiche.
ich hab fuer das Wiederbeleben einer GoFlex Home den einfachsten JTAG-Adapter verwendet, der beschrieben wurde mit 4x100 Ohm an Pins 3,4,5,6 und 1x4,7 kOhm an Pin 2(zu 3,3V), serielles Kabel war vorhanden - sie lebt wieder :)
zu openocd möchte ich noch bemerken, daß ich nirgends einen Hinweis auf "soft_reset_halt" fand, bei mir wurde das nand ohne nicht erkannt
vor "sheevaplug_init" zusätzlich "soft_reset_halt" aufrufen
Kommentar veröffentlichen