Der Second-Stage-Bootloader ist als Nächstes dran

Ich erstelle eine zweite Medusa-Datenbank für den Second-Stage-Bootloader mit den bereits mir bekannten Speicheradressen und beginne, damit zu arbeiten.

Ich vergrabe mich aber auch nicht zu tief in diesen Bootloader. Selbst wenn der Maschinencode nur 75 KByte umfasst, ist das recht aufwendig, ich überfliege ihn ebenfalls nur. Ich stelle schnell fest, dass der Code Thumb-Befehle umfasst, mit denen Medusa größere Probleme hat. Ich folge dem Programmfluss, dabei werden vor allem Datenstrukturen initialisiert. Diesen Teil überspringe ich. Ich stoße aber auch auf interessante Anweisungen, die mit den SoC-Registern zu tun haben.

Es gibt einen Abschnitt im Code, der einen Zeiger auf die Zeichenkette "param" speichert, gefolgt vom Aufruf einer Funktion, die mit dem Flash-Speicher-Controller kommuniziert. Könnte das einer Datei-öffnen-Funktion entsprechen? Danach wird mit dem Rückgabewert der Datei-öffnen-Funktion ein Zeiger auf einen Speicherbereich außerhalb des Programmcodes erzeugt und ein Register mit dem Wert 460 beschrieben. Könnte das einer Datei-lesen-Funktion entsprechen? Vielleicht.

Nach einer Weile finde ich Code, der sich auf die Zeichenketten "Boot to load (Y/N)?" und "Wait for Enter" bezieht. Außerdem gibt es einen Codeaufruf im Zusammenhang mit der seriellen Schnittstelle und danach wird der Wert 0x75 geprüft. Dieser Wert entspricht dem ASCII-Code von "u". Deshalb probiere ich, "u" einzugeben, während das Oszilloskop bootet. Und tatsächlich erscheint darauf die Ausgabe "Enter USB-download Mode" und das Oszilloskop hält an. Wahrscheinlich wartet es jetzt auf einige Kommandos über USB.

Wenn während der Boot-Abfrage eine vorgegebene Zeit überschritten wird, lädt der Bootloader eine Datei namens "os" an die Adresse 0. Dann wird anscheinend eine Prüfsummen-Kalkulation durchgeführt. Stimmt der Wert nicht mit einem Wert an einer bestimmten Speicheradresse im RAM überein, dann versucht der Bootloader, eine Datei "oscp" zu laden und erneut die Prüfsumme zu ermitteln. Schlägt auch das fehl, wird die Meldung "open or read OS ERR" ausgegeben. An dieser Stelle wird offensichtlich versucht, das Betriebsystem zu laden, und dessen Zustand überprüft.

• 

Diasembler-Ausgabe (Bild: Christer Weinigel)

Ich versuche, herauszufinden, ob ich irgendwie die Kommandozeile des Bootloaders aufrufen kann. Ich vermute aber, dass der Zugriff in der Produktionsversion deaktiviert wurde. Die noch vorhandenen Kommandonamen waren einfach Überbleibsel davon.

Das Dateisystem untersuchen

Wenn ich mir die Datei-öffnen- und lesen-Funktion näher anschaue, könnte ich vielleicht das Dateisystem im Flash-Speicher näher bestimmen. Doch das scheint mir zu viel Arbeit zu sein. Ich probiere einen anderen Weg.

Yet Another Flash File System (Yaffs) ist ein Dateisystem speziell für NAND-Flash-Speicher. Es kann mit all den Besonderheiten von Flash-Speicher umgehen wie der Fehlerkorrektur, dem Umkopieren beschädigter Bereiche und dem gleichmäßigen Beschreiben aller Speicherbereiche (Wear leveling). Das Dateisystem ist Open Source und für den Einsatz in Linux und uBoot unter GPL lizenziert, es gibt aber auch kommerzielle Lizenzen für proprietäre Systeme.

Ich finde einige Zeichenketten im Speicherabbild des Oszilloskops, die auf Yaff hindeuten. Auch einige Kommentare im EEVblog-Forum sprechen davon. Ich suche nach Werkzeugen, die mit einem Yaff-Dateisystem umgehen können.

Ich verbringe einige Zeit damit und scheitere komplett. Keines der Werkzeuge kann etwas mit den Daten anfangen. Ich schäme mich fast dafür, aber es dauert einige Zeit, bevor ich anfange, nachzudenken und direkt auf die Daten zu schauen. Ich begreife dann schnell, dass es offensichtlich nicht Yaff war.