Gute Tools 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 war, als ich sie gebaut hatte, sodass einige der Geräteregister falsch konfiguriert waren.

Jetzt, da ich das Problem herausgefunden habe, muss ich 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.

Das 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, mich in den Dateien umzusehen und den Code in der Nähe relevanter Bezeichner anzusehen. 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 mittlerweile ziemlich gut, wie der Bootloader funktioniert, aber ich hoffe, es gibt eine bessere Methode als meinen naiven Ansatz.

Haben Sie versucht, auf der Mailingliste der uboot-Entwickler nachzufragen?

Antworten (2)

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

  • Bessere Werkzeuge, um den Quellcode zu verstehen:

    • cscope ist ein Werkzeug zum Erkunden von C-Code, es ist wie grep, versteht aber 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 vor sich geht
    • Verwenden Sie die Instrumentierungsfunktionen von gcc, um beim Eintritt/Ende jeder Funktion einen guten Teil 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 nachzubilden

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

@Laufzeitanalyse - Auf einem separaten eingebetteten System nicht so praktikabel, insbesondere wenn kein zugrunde liegendes Betriebssystem gleichzeitig ausgeführt wird, z. B. ein Bootloader, was dies ist.
Sie können es immer noch mit einem Debugger durchlaufen, wie Joby vorschlägt. Je nach Komplexität kann es hilfreich sein oder auch nicht.
Cscope ist das, was ich mir vorgestellt habe. Ich hatte auf etwas glänzenderes gehofft, aber es ist ein guter Anfang. Vielen Dank.

Wie haben Sie es konfiguriert, um es für den AT91 zu bauen?

Der Codebaum scheint so konzipiert zu sein, dass sich alle architekturspezifischen Dinge im Baum „arch/(cpu class)/(cpu type)/...“ befinden. Ich habe den AT91-Code unter arch/arm/cpu/arm926ejs/at91 gefunden ... befindet sich das variantenspezifische Zeug, das Sie ändern möchten, nicht dort? In diesem Verzeichnis gibt es nicht allzu viel zu durchsuchen, zumal fast die Hälfte der Dateien individuell AT91-variantenspezifisch sind.

Tut mir leid, wenn das 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-Leiterplatte. 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.

Ja, ich habe einige Zeit mit arch/arm/cpu/arm926ejs/at91/* verbracht, aber danke für den Vorschlag. Es stellte sich heraus, dass der Code, nach dem ich suchte, tatsächlich im Boot-ROM des Prozessors war, auf das nur Atmel zugreifen kann. Die blutigen Details sind hier: at91.com/forum/viewtopic.php/f,9/t,19732/start,0/st,0/sk,t/sd,a
Übrigens, insgesamt war ich ziemlich beeindruckt von U-boot. Für die große Anzahl von Boards und CPUs, die es unterstützt, ist es ziemlich gut organisiert. Die Dokumentation ist spärlich, aber das scheint für Bootloader selbstverständlich zu sein.
@pingswept: Hey, Linux auf 4 Ebenen. Nett. Vielleicht sollte ich mir diesen Chip anstelle des iMX233 ansehen. Ich hatte eine Menge Zeit damit, meine ARM + zwei SDRAM-Chips auf 4 Schichten zu bringen, und habe sie zurückgestellt, um an anderen Projekten zu arbeiten. Ich bin auch ein Altium-Benutzer.
Das 9G20 und das iMX233 liegen ziemlich nah beieinander. Ich habe mich für den 9G20 entschieden, weil der Ethernet-MAC eingebaut ist und die Chips in geringer Menge etwas billiger sind, aber der iMX233 war ein knapper Zweiter.
Werfen Sie auch einen Blick auf das Chumby Hacker Board – könnte ein guter Ausgangspunkt sein, wenn Sie sich entscheiden, ein System um den iMX233 herum zu bauen. Die Altium-Dateien befinden sich auf dieser Wiki-Seite: wiki.chumby.com/mediawiki/index.php/Chumby_hacker_board_beta
Gute Tools oder Methoden zum Verständnis der Struktur des Bootloaders?
AntwortenHierDatenschutz-Bestimmungen1y, 0v