sjgallagher2/am335xbootromReverse engineering della boot ROM TI AM3358
Sono passati probabilmente diciotto mesi da quando ho messo le mani su alcune schede Beaglebone Black, salvate dalla spazzatura. Purtroppo, le schede non funzionavano subito. Ora, era la prima volta che lavoravo con una di queste schede, o con qualsiasi computer a scheda singola, quindi non ero sicuro se il problema fossi io o qualcosa di sbagliato nelle schede stesse (forse il motivo per cui erano state destinate alla spazzatura in primo luogo). Mi ci è voluto parecchio tempo e molto impegno per far avviare davvero queste schede, ma accidenti, ce l'ho fatta. Ed ecco cosa ho imparato lungo il percorso.
Ho incluso alcune utilità in questo repository, insieme a un file xml esportato da Ghidra che contiene tutti i simboli che ho ottenuto finora dal reversing. Ho usato questo post per esportare senza il firmware vero e proprio, per evitare problemi di copyright, per sicurezza. Se vuoi eseguire il debug della boot ROM da solo, avrai già il JTAG collegato, quindi puoi fare il dump della boot ROM (da 0x20000 a 0x2BFFF) da solo.
Per caricare i simboli:
0x20000 e di poter impostare il nome del blocco a bootrom.main(), o al boot handler della scheda MMC/SD.Per cominciare, sapevo che queste erano versioni personalizzate del beaglebone black standard, quindi all'inizio ho stabilito che poteva mancare qualcosa sulla scheda stessa, come un identificatore di scheda. Quello che ho visto quando avviavo una scheda SD standard formattata con balenaEtcher era semplicemente nulla. Mi aspettavo che i LED sulla scheda iniziassero a lampeggiare e mi aspettavo che collegando un cavo UART-USB avrei potuto vedere il processo di U-Boot. Tuttavia, la UART era silenziosa. Se rimuovevo la scheda SD, emetteva la lettera C in continuazione, che è il comportamento previsto per un boot UART/seriale. Stava decisamente provando ad avviarsi, e la scheda SD stava alterando questo comportamento, ma non avevo più visibilità. La maggior parte delle guide di risoluzione problemi sul web usava l'output di U-Boot come punto di partenza per diagnosticare i problemi. Immagino che non avrei avuto quel lusso.
A questo punto ho pensato che valesse la pena collegare una sonda di debug. Sfortunatamente, non avevo un connettore compatibile con il footprint esistente, così ne ho creato uno mio.
La scheda beaglebone ha un connettore con designazione P2 che riporta le connessioni JTAG. Ho collegato dei fili a questo connettore fino a un connettore femmina, così da poter comunicare tramite il mio J-Link.
Avviando Ozone (il debugger Segger) ho configurato il J-Link e ho iniziato semplicemente cercando di trovare il punto di ingresso. Avevo pensato che un reset-halt mi avrebbe portato dove serviva, ed è così che sono arrivato alla (errata) ipotesi che il punto di ingresso fosse 0x2148a, anche se sicuramente avevo notato che non era coerente. Più tardi, ho capito che le schede AM335x non vanno molto d'accordo con il reset-halt del J-Link, quindi in realtà c'era un ritardo di forse qualche centinaio di cicli di clock, che mi faceva finire da qualche parte all'interno di un boot handler, in modo indeterministico. (Alla fine ho risolto scrivendo un file GEL per Code Composer Studio di TI che supporta il debug via J-Link - al reset, il registro PC viene impostato sul reset handler, i registri vengono azzerati e la modalità istruzione viene forzata a ARM.)
Da un thread sui forum TI (AM335x: TI employees, where can I get the ROM Bootloader source code/symbols?) ho raccolto un paio di simboli di debug: SPI Initialize a 0x231e0, SPI ReadSectors a 0x23230, e 0x24bfa è una routine che esegue una lettura UART. È un aiuto carino, immagino. Ho notato che il boot falliva finendo in un loop infinito a 0x402f0440, un dead loop. Hmm, piuttosto lontano dal resto della boot ROM, probabilmente sarà in RAM o qualcosa del genere. È probabilmente il momento di passare al technical reference manual (TRM)!
Il Capitolo 26 del TRM contiene un sacco di informazioni sull'avvio. Otteniamo la seguente vista della boot ROM:
Descrizione:
L'architettura del Public ROM Code è mostrata nella Figura 26-1. È diviso in tre livelli principali con un approccio top-down: alto livello, driver e hardware abstraction layer (HAL). Un livello comunica con un livello inferiore tramite un'interfaccia unificata. Il livello ad alto livello è responsabile dei compiti principali del Public ROM Code: configurazione di watchdog e clock e routine principale di avvio. Il livello dei driver implementa i protocolli logici e di comunicazione per qualsiasi dispositivo di avvio in conformità con la specifica dell'interfaccia. Infine, l'HAL implementa il codice di livello più basso per interagire con gli IP dell'infrastruttura hardware. I dispositivi di avvio finali sono collegati ai pad IO del dispositivo.
La Figura 26-2 illustra il flusso ad alto livello della procedura di avvio del Public ROM Code. Su questo dispositivo, il Public ROM Code parte al completamento dell'avvio sicuro (eseguito dal Secure ROM Code). Il ROM Code esegue quindi la configurazione e l'inizializzazione della piattaforma come parte della procedura di avvio pubblico. L'elenco dei dispositivi di avvio viene creato in base ai pin SYSBOOT. Un dispositivo di avvio può essere un dispositivo di avvio di memoria (memoria flash saldata o dispositivo di avvio temporaneo come una memory card) o un'interfaccia periferica collegata a un host. Il loop principale della procedura di avvio scorre l'elenco dei dispositivi di avvio e cerca di trovare un'immagine dal dispositivo di avvio attualmente selezionato. Questo loop viene terminato se viene trovata un'immagine di avvio valida e viene eseguita con successo, oppure alla scadenza del watchdog. La procedura di autenticazione dell'immagine viene eseguita prima dell'esecuzione dell'immagine su un dispositivo HS. Un fallimento nella procedura di autenticazione porta al branching verso un "dead loop" nel Secure ROM (in attesa di un reset del watchdog).
Mappa di memoria! Vettori di eccezione! Diagrammi di flusso! Un sacco di informazioni in questa sezione. Il mio lavoro è diventato molto più facile.