sjgallagher2/am335xbootromReverse Engineering des TI AM3358 Boot-ROMs
Es ist wohl achtzehn Monate her, seit ich ein paar Beaglebone-Black-Boards in die Hände bekam, die aus dem Mülleimer gerettet wurden. Leider funktionierten die Boards nicht auf Anhieb. Nun war es mein erstes Mal, mit einem dieser Boards zu arbeiten – oder überhaupt mit einem Single-Board-Computer –, also war ich mir nicht sicher, ob das Problem an etwas lag, das ich tat, oder an den Boards selbst (vielleicht der Grund, warum sie überhaupt im Mülleimer gelandet waren). Es hat ziemlich lange gedauert und eine Menge Mühe gekostet, diese Boards tatsächlich zum Booten zu bringen, aber verdammt, ich habe es geschafft. Und hier ist, was ich dabei gelernt habe.
Ich habe ein paar Hilfsprogramme in dieses Repo gepackt, zusammen mit einer aus Ghidra exportierten XML-Datei, die alle Symbole enthält, die ich bisher durch das Reversing gewinnen konnte. Ich habe diesen Beitrag verwendet, um ohne die eigentliche Firmware zu exportieren, um Urheberrechtsprobleme zu vermeiden, nur für den Fall. Wenn du das Boot-ROM selbst debuggen willst, hast du den JTAG ohnehin angeschlossen und kannst das Boot-ROM (von 0x20000 bis 0x2BFFF) selbst auslesen.
So lädst du die Symbole:
0x20000 setzt; den Blocknamen kannst du auf bootrom setzen.main() oder zum MMC/SD-Karten-Boot-Handler springen.Zunächst wusste ich, dass es sich um kundenspezifische Versionen des Standard-Beaglebone-Black handelte, also habe ich früh festgestellt, dass auf der Platine selbst etwas fehlen könnte, etwa eine Board-Kennung. Als ich eine standardmäßige, mit balenaEtcher formatierte SD-Karte bootete, sah ich einfach nichts. Ich erwartete, dass die LEDs auf dem Board zu blinken beginnen, und ich erwartete, dass das Anschließen eines UART-zu-USB-Kabels mir erlauben würde, den U-Boot-Prozess zu sehen. Doch der UART blieb stumm. Wenn ich die SD-Karte entfernte, gab das Board immer wieder den Buchstaben C aus, was für einen UART/Seriell-Boot erwartetes Verhalten ist. Es hat definitiv versucht zu booten, und die SD-Karte veränderte dieses Verhalten, aber ich hatte keinen weiteren Einblick. Der Großteil der Fehlersuche im Internet nahm die U-Boot-Ausgabe als Ausgangspunkt, um Probleme zu diagnostizieren. Ich schätze, diesen Luxus würde ich nicht haben.
An diesem Punkt dachte ich, dass es sich lohnen würde, eine Debug-Probe anzuschließen. Leider hatte ich keinen passenden Header für den vorhandenen Footprint, also habe ich mir selbst einen gebaut.
Das Beaglebone-Board besitzt einen Header mit der Bezeichnung P2, über den die JTAG-Verbindungen herausgeführt werden. Ich habe ein paar Drähte von diesem Header zu einer Buchsenleiste verbunden, sodass ich über meinen J-Link darauf zugreifen kann.
Als ich Ozone (den Segger-Debugger) startete, konfigurierte ich den J-Link und begann damit, zunächst nur den Entry Point zu finden. Ich hatte gedacht, ein Reset-Halt würde mich an die gewünschte Stelle bringen; so kam ich zu der (falschen) Annahme, der Entry Point sei 0x2148a, obwohl mir durchaus auffiel, dass das nicht konsistent war. Später merkte ich, dass die AM335x-Boards nicht wirklich gut mit dem Reset-Halt des J-Links zusammenarbeiten, sodass es tatsächlich eine Verzögerung von vielleicht ein paar hundert Taktzyklen gab, die mich indeterministisch irgendwo in einem Boot-Handler landen ließ. (Ich habe das schließlich umgangen, indem ich eine GEL-Datei für TI Code Composer Studio geschrieben habe, das J-Link-Debugging unterstützt – beim Reset wird das PC-Register auf den Reset-Handler gesetzt, die Register werden gelöscht und der Befehlsmodus wird auf ARM erzwungen.)
Aus einem Thread in den TI-Foren (AM335x: TI-Mitarbeiter, wo bekomme ich den ROM-Bootloader-Quellcode/die Symbole?) habe ich ein paar Debug-Symbole mitgenommen: SPI Initialize bei 0x231e0, SPI ReadSectors bei 0x23230, und 0x24bfa ist eine Routine, die einen UART-Read durchführt. Das ist wohl eine ganz nette Hilfe, schätze ich. Mir fiel auf, dass der Boot fehlschlug, indem er in einer Endlosschleife bei 0x402f0440 landete, einer toten Schleife. Hmm, ziemlich weit entfernt vom Rest des Boot-ROMs, muss in RAM oder so sein. Es ist wohl an der Zeit, zum Technical Reference Manual (TRM) zu wechseln!
Kapitel 26 des TRM enthält jede Menge Informationen zum Booten. Wir erhalten die folgende Ansicht des Boot-ROMs:
Beschreibung:
Die Architektur des Public ROM Code ist in Abbildung 26-1 dargestellt. Sie ist in drei Hauptschichten unterteilt, im Top-down-Ansatz: High-Level, Treiber und Hardware-Abstraktionsschicht (HAL). Eine Schicht kommuniziert über eine einheitliche Schnittstelle mit einer darunterliegenden Schicht. Die High-Level-Schicht ist für die Hauptaufgaben des Public ROM Code zuständig: Watchdog- und Taktkonfiguration sowie die Haupt-Boot-Routine. Die Treiberschicht implementiert die logischen und Kommunikationsprotokolle für jedes bootende Gerät gemäß der Schnittstellenspezifikation. Schließlich implementiert das HAL den Code der untersten Ebene für die Interaktion mit den Hardware-Infrastruktur-IPs. Die bootenden Endgeräte sind an die Geräte-IO-Pads angeschlossen.
Abbildung 26-2 veranschaulicht den High-Level-Ablauf des Bootvorgangs des Public ROM Code. Auf diesem Gerät startet der Public ROM Code nach Abschluss des sicheren Startvorgangs (durchgeführt vom Secure ROM Code). Der ROM Code führt dann die Plattformkonfiguration und -initialisierung als Teil des öffentlichen Startvorgangs durch. Die Liste der Boot-Geräte wird basierend auf den SYSBOOT-Pins erstellt. Ein Boot-Gerät kann ein Speicher-Boot-Gerät sein (gelöteter Flash-Speicher oder ein vorübergehendes Boot-Gerät wie eine Speicherkarte) oder eine Peripherieschnittstelle, die mit einem Host verbunden ist. Die Hauptschleife des Bootvorgangs durchläuft die Liste der Boot-Geräte und versucht, ein Image vom derzeit ausgewählten Boot-Gerät zu finden. Diese Schleife wird verlassen, wenn ein gültiges Boot-Image gefunden und erfolgreich ausgeführt wird oder wenn der Watchdog abläuft. Die Image-Authentifizierung wird vor der Image-Ausführung auf einem HS-Device durchgeführt. Ein Fehler bei der Authentifizierung führt zu einer Verzweigung in eine „Dead Loop“ im Secure ROM (Warten auf einen Watchdog-Reset).