Gute Werkzeuge oder Methoden zum Verständnis der Struktur des Bootloaders?

Ich habe kürzlich die Ursache eines bösen Fehlers herausgefunden, an dem ich mit einem Atmel AT91SAM9G20 SBC gearbeitet habe, auf dem U-Boot , ein Open-Source-Bootloader, ausgeführt wird. Der Kern des Problems bestand darin, dass U-Boot erwartete, dass die Hardware anders konfiguriert sein würde als ich sie erstellt hatte, sodass einige der Geräteregister falsch konfiguriert waren.

Nachdem ich das Problem herausgefunden habe, muss ich den U-Boot optimieren, um die Register korrekt zu konfigurieren. Ich kann dies blind tun, indem ich am Ende des Programms ein paar Codezeilen hinzufüge, aber das ist chaotisch.

Dies bringt mich zu meiner Frage: Wie kann ich herausfinden, wie U-Boot effizienter funktioniert, als bei main () zu beginnen und alle möglichen Codepfade über alle Dateien hinweg zu lesen? Ich habe versucht, in den Dateien herumzusuchen und den Code in der Nähe der relevanten Bezeichner zu betrachten. Dies hat sich als unwirksam erwiesen; Es scheint, dass der größte Teil des Codes Treiber für Subsysteme sind, die mir egal sind. Eigentlich verstehe ich, wie der Bootloader mittlerweile ziemlich gut funktioniert, aber ich hoffe, dass es eine bessere Methode gibt als meinen naiven Ansatz.

Es gibt verschiedene Tools / Strategien, die helfen könnten:

• Bessere Tools, um den Quellcode zu verstehen:

  • cscope ist ein Tool zum Erkunden von C-Code. Es ähnelt grep, versteht jedoch die Syntax
  • Rufen Sie Graphgeneratoren auf, um ein Bild der Funktionsaufrufstruktur zu zeichnen
  • Fenris sieht interessant aus, obwohl ich es nicht ausprobiert habe

• Laufzeitanalyse

  • Gehen Sie mit einem Debugger durch interessante Abschnitte und analysieren Sie, was los ist
  • Verwenden Sie die Instrumentierungsfunktionen von gcc, um beim Ein- / Ausstieg jeder Funktion einen Teil des Guten aufzurufen. z.B. http://ndevilla.free.fr/etrace/

• Schreiben Sie Ihren eigenen Mini-Bootloader

  • Ich finde oft, dass der beste Weg, etwas zu verstehen, darin besteht, es selbst neu zu erstellen

Leider gibt es kein Zauberrezept, das für alles funktioniert.

Wie haben Sie es für den AT91 konfiguriert?

Der Codebaum scheint so gestaltet zu sein, dass sich alle architekturspezifischen Inhalte im Baum 'arch / (CPU-Klasse) / (CPU-Typ) / ...' befinden. Ich habe den AT91-Code unter arch / arm / cpu / arm926ejs / at91 gefunden. Befindet sich das variantenspezifische Material, das Sie ändern möchten, nicht dort? In diesem Verzeichnis gibt es nicht viel zu sehen, zumal fast die Hälfte der Dateien für einzelne AT91-Varianten spezifisch ist.

Entschuldigung, wenn dies offensichtlich ist ... aber Sie haben nicht erwähnt, dass Sie dies überprüfen.

Ich hatte mir den uBoot-Codebaum noch nicht angesehen, aber Ihr Beitrag hat mich dazu erschreckt. Ein Backburner-Projekt von mir beinhaltet schließlich die Verwendung von uBoot und Linux auf einer benutzerdefinierten iMX233-Platine. Ich bin sehr daran interessiert, diese Art von Feedback darüber zu erhalten, wie gut die uBoot-Architektur und variantenspezifische Dinge isoliert sind und wie groß der Schmerz sein wird.