Wie wurde dieser erste Bootstrap erstellt?
Das Erstellen (Schreiben und Cross-Compilieren) eines Bootstrap-Programms ist nicht so abschreckend, wie Sie vermuten.
Ich sollte darauf hinweisen, dass ich wirklich über ARM-Geräte spreche. Ich bekomme die Grundlagen des Ladens über das BIOS auf einem typischen Computer.
Das BIOS, auf das Sie sich beziehen, ist im Wesentlichen eine PC-Konvention. (CP / M hatte auch ein BIOS, ist aber nicht unbedingt in einem nichtflüchtigen Speicher.) ARM-CPUs haben oder verwenden normalerweise kein BIOS.
Der heutzutage verwendete typische ARM-Prozessor ist mit Peripheriegeräten auf einem einzigen IC, einem so genannten SoC- System, auf einem Chip integriert. Hauptspeicher (z. B. DRAM) und nichtflüchtiger Speicher (z. B. NAND-Flash) befinden sich normalerweise außerhalb des SoC, um maximale Designflexibilität zu gewährleisten. Normalerweise gibt es jedoch ein kleines (vielleicht 128 KB) Embedded ROM (Nur-Lese-Speicher), um die minimalen Systemkomponenten zu initialisieren, um Bootstrap-Vorgänge zu beginnen. Ein Prozessor-Reset führt immer zur Ausführung dieses Boot-ROMs. (Dieses ROM ist wirklich schreibgeschützt und kann nicht modifiziert werden. Der Code wird während der Chipherstellung in das Silizium eingeblendet.)
Jeder SoC-Anbieter verfügt über eine eigene Bootstrap-Methode, um das Betriebssystem zu laden und auszuführen. Einige verwenden Hardware-Umreifungslesevorgänge durch GPIO-Pins, um die Quelle der nächsten Stufe der Bootstrap-Sequenz zu bestimmen. Ein anderer Anbieter kann eine geordnete Liste von Speichern und Geräten verwenden, um nach einem Bootstrap-Programm zu suchen. Eine andere Technik besteht darin, zu Firmware in NOR-Flash zu verzweigen, die direkt ausgeführt werden kann (z. B. XIP, in Place ausführen).
Ein Problem beim Bootstrapping eines Systems, das DRAM als Hauptspeicher verwendet, ist die Hardware-Initialisierung. Der DRAM-Speichercontroller muss initialisiert werden, bevor Code in DRAM geladen und ausgeführt werden kann. Wo befindet sich dieser Initialisierungscode, da er sich nicht im Hauptspeicher befinden kann?
Jeder Anbieter hat seine eigene Lösung. Einige erfordern, dass Speicherkonfigurationsdaten in einem nichtflüchtigen Speicher gespeichert werden, damit das Boot-ROM darauf zugreifen kann. Einige SoCs verfügen über ein integriertes SRAM (das keine Initialisierung wie DRAM erfordert), um ein kleines Bootstrap-Programm auszuführen. Einige SoCs verwenden NOR-Flash, um ein XIP-Bootstrap-Programm aufzunehmen.
Sobald das Bootstrap-Programm den DRAM initialisiert hat, kann der Hauptspeicher zum Laden der nächsten Stufe des Bootens verwendet werden. Dies kann ein ausgeklügeltes Boot-Dienstprogramm wie U-Boot oder (falls das Bootstrap-Programm fähig ist) der Linux-Kernel sein. Beachten Sie, dass zwischen dem Zurücksetzen des Prozessors auf die Ausführung des Betriebssystems möglicherweise mehrere Bootstrap-Programme oder -Stufen ausgeführt werden.
Die Anforderungen für das Booten des Linux ARM-Kernels sind im folgenden Dokument beschrieben: http://www.simtec.co.uk/products/SWLINUX/files/booting_article.html
Ältere Versionen von Linux ARM verwendeten die ATAGs-Liste, um die Basiskonfiguration zu übergeben Informationen zum Kernel. Moderne Versionen bieten eine vollständige Platinen-Konfiguration unter Verwendung einer kompilierten Binärdatei eines Gerätebaums.
Offensichtlich ist die Frage "wie macht man einen Bootstrap?" kann nicht ohne Qualifikation beantwortet werden.
Wie beim PC-BIOS ist das Boot-ROM von SoCs proprietär und wird nicht veröffentlicht (es sei denn, Sie unterschreiben einen NDA, wenn überhaupt). Die meisten anderen Boot-Codes werden jedoch unter GPL oder ähnlichen Lizenzen veröffentlicht und sind leicht erhältlich.
NACHTRAG
Da Sie nun erwähnen, dass Sie einen Zynq 7000 (der einen Xilinx-SoC verwendet) verwenden, bietet Xilinx ein Video-Tutorial zum Erstellen eines Linux-Boot-Images .
Dieses Video bestätigt, was ich bereits geschrieben habe:
1. Der Xilinx-SoC verfügt über ein eingebettetes Boot-ROM (technisch gesehen die erste Stufe, wird aber öfter ignoriert oder als Stufe Null bezeichnet).
2. Es gibt "Modus-Pins", um die Quelle des Bootstrap-Programms für die nächste Stufe anzugeben.
3. Das Boot-ROM lädt ein Bootstrap-Programm (das technisch die zweite Stufe ist, aber häufig als "erste" Stufe bezeichnet wird), genannt FSBL, in den eingebetteten SRAM. Dieses Programm initialisiert DRAM und lädt die nächste Stufe, U-Boot.
4. U-Boot führt DRAM aus und lädt den Linux-Kernel.
Das Video zeigt, dass der FSBL-Quellcode von der Xilinx-Site heruntergeladen und in wenigen Schritten kompiliert werden kann. Es gibt keinen "Trick", wie Sie behaupten. Der Build ist eine unkomplizierte Konfiguration und Cross-Compile, die ich einfacher als das typische Anwendungspaket finde.
Möglicherweise beruht Ihre Verwirrung auf der Mehrdeutigkeit des Boot-Mediums, dh, die Quelle (n) der Boot-Images wurde (sind) nicht angegeben. Das Video nennt NAND-Flash und SD-Karte als mögliche Startgeräte.
Das Boot-ROM wird angewiesen, das FSBL-Image von einem Quellmedium zu lesen, wie es durch Modus-Pins konfiguriert ist.
Die FSBL (wenn es wie andere Bootstraps ist, die ich verwendet habe) ist so aufgebaut, dass U-Boot von einem konfigurierten Quellmedium gelesen wird. Es gibt keine Laufzeitalternative.
U-Boot versucht, seinem Namen gerecht zu werden ("universal") und kann (mithilfe von Umgebungsvariablen) so konfiguriert werden, dass Images (und Scripts) von verschiedenen Geräten geladen werden. Es gibt auch die interaktive Option.
Siehe auch das Xilinx-Wiki unter Zynq Linux, das erklärt, dass "vollständige Informationen zum Booten von Zynq im technischen Referenzhandbuch enthalten sind ".