Buoni strumenti o metodi per comprendere la struttura del bootloader?

Di recente ho scoperto la causa di un brutto bug su cui ho lavorato con un SBC Atmel AT91SAM9G20 con U-boot , un bootloader open source. Il nocciolo del problema era che U-boot si aspettava che l'hardware fosse configurato diversamente da come l'avevo costruito, quindi alcuni dei registri dei dispositivi erano configurati male.

Ora che ho capito il problema, devo modificare U-boot per configurare correttamente i registri. Posso farlo alla cieca aggiungendo alcune righe di codice alla fine del programma, ma è disordinato.

Questo mi porta alla mia domanda: come posso capire come U-boot funziona in modo più efficiente rispetto a partire da main () e leggere tutti i possibili percorsi di codice su tutti i file? Ho provato a cercare nei file e guardare il codice vicino agli identificatori pertinenti. Ciò si è rivelato inefficace; sembra che la maggior parte del codice sia driver per sottosistemi di cui non mi interessa. In realtà capisco come il bootloader funzioni abbastanza bene ormai, ma spero che esista un metodo migliore del mio approccio ingenuo.

Esistono diversi strumenti / strategie che potrebbero aiutare:

• Strumenti migliori per dare un senso al codice sorgente:

  • cscope è uno strumento per esplorare il codice C, è come grep ma capisce la sintassi
  • Chiama i generatori di grafici per disegnare un'immagine della struttura di chiamata della funzione
  • Fenris sembra interessante anche se non l'ho provato

• Analisi di runtime

  • Scorri sezioni interessanti con un debugger e analizza cosa sta succedendo
  • Usa le funzionalità di strumentazione di gcc per chiamare un pezzo di buono all'entrata / uscita di ogni funzione. per esempio. http://ndevilla.free.fr/etrace/

• Scrivi il tuo mini bootloader

  • Trovo spesso che il modo migliore per capire qualcosa sia ricrearlo da solo

Sfortunatamente, non esiste una ricetta magica che funzioni per tutto.

Come lo hai configurato per costruire per l'AT91?

L'albero del codice sembra essere progettato in modo tale che qualsiasi elemento specifico dell'architettura si trovi nell'albero 'arch / (cpu class) / (cpu type) / ...'. Ho trovato il codice AT91 sotto arch / arm / cpu / arm926ejs / at91 ... la variante specifica della variante che stai cercando di modificare non si trova lì? Non c'è molto da guardare in quella directory, specialmente perché quasi la metà dei file è specifica per la singola variante AT91.

Scusa se questo è ovvio ... ma non hai menzionato il controllo di questo.

Non avevo ancora visto l'albero del codice uBoot, ma il tuo post mi ha spaventato a farlo. Un mio progetto di back burner prevede infine l'utilizzo di uBoot e Linux su un PCB iMX233 personalizzato. Sono molto interessato a ricevere questo tipo di feedback su quanto bene sia isolata l'architettura uBoot e le cose specifiche delle varianti e quanto sia grande il dolore che sarà.