Im Kontext von Linux ist der Bootloader für einige vordefinierte Aufgaben zuständig. Da diese Frage mit Arm markiert ist, denke ich, dass das Booten von ARM eine nützliche Ressource sein könnte. Konkret war/ist der Bootloader für die Einrichtung eines ATAG zuständig Liste, die die Größe des Arbeitsspeichers, eine Kernel-Befehlszeile und andere Parameter beschreibt. Einer der wichtigsten Parameter ist der Maschinentyp . Mit Gerätebäumen , wird eine vollständige Beschreibung des Boards übergeben. Dies macht es unmöglich, ein Standard-ARM-Linux ohne Code zum Einrichten der Parameter wie beschrieben zu booten.
Die Parameter erlauben ein Generikum Linux zur Unterstützung mehrerer Geräte. Beispielsweise kann ein ARM-Debian-Kernel Hunderte verschiedener Board-Typen unterstützen. Ubooten oder andere Bootloader können diese Informationen dynamisch bestimmen oder sie können für das Board fest codiert werden.
Vielleicht möchten Sie sich auch die Bootloader-Infoseite hier bei Stapelüberlauf ansehen.
Ein einfaches System kann möglicherweise ATAGS einrichten und NOR-Flash in SRAM kopieren. Allerdings ist es in der Regel etwas komplexer. Linux benötigt eine RAM-Einrichtung, daher müssen Sie möglicherweise einen SDRAM-Controller initialisieren. Wenn Sie NAND-Flash verwenden, müssen Sie mit schlechten Blöcken umgehen und die Kopie kann etwas komplexer sein als memcpy() .
Linux hat oft einige latente Treiberfehler, bei denen ein Treiber davon ausgeht, dass eine Uhr initialisiert ist. Zum Beispiel, wenn Uboot immer eine Ethernet-Uhr für eine bestimmte Maschine initialisiert, hat der Linux-Ethernet-Treiber es möglicherweise versäumt, diese Uhr einzurichten. Dies kann insbesondere bei Uhrbäumen der Fall sein.
Einige Systeme erfordern Boot-Image-Formate, die von Linux nicht unterstützt werden; zum Beispiel ein spezieller Header, der Hardware sofort initialisieren kann; wie die Konfiguration von devices um den Anfangscode zu lesen. Außerdem gibt es oft Hardware, die sofort konfiguriert werden sollte; ein Bootloader kann dies schnell tun, während die normale Struktur von Linux dies erheblich verzögern kann, was zu E/A-Konflikten usw. führen kann.
Aus pragmatischer Sicht ist es einfacher, einen Bootloader zu verwenden. Nichts hindert Sie jedoch daran, den Quellcode von Linux zu ändern, um direkt davon zu booten; obwohl es vielleicht wie das Einfügen des Bootloaders ist Code direkt zum Start von Linux.
Siehe auch:Vergleich von Coreboot, Uboot und Wikipedia. Barebox ist ein weniger bekannter, aber gut strukturierter und moderner Bootloader für den ARM. RedBoot wird auch in einigen ARM-Systemen verwendet; RedBoot-Partitionen werden im Kernelbaum unterstützt.
Ein Bootloader ist ein Computerprogramm, das nach Abschluss der Selbsttests das Hauptbetriebssystem oder die Laufzeitumgebung für den Computer lädt.
^ Aus Wikipedia-Artikel
Der Bootloader macht also im Grunde genau das, was Sie wollten - das Kopieren von Daten aus dem Flash in den Arbeitsspeicher. Es ist wirklich so einfach.
Wenn Sie mehr über das Boostrapping des Betriebssystems erfahren möchten, empfehle ich Ihnen dringend, den verlinkten Artikel zu lesen. Die Boot-Phase besteht neben Tests auch aus der Überprüfung von Peripheriegeräten und einigen anderen Dingen. Sie zu überspringen ist nur auf sehr einfachen eingebetteten Geräten sinnvoll, und deshalb sind ihre Bootloader noch einfacher:
Einige eingebettete Systeme erfordern keine merkliche Startsequenz, um zu funktionieren, und können beim Einschalten einfach betriebsbereite Programme ausführen, die im ROM gespeichert sind.
Die gleiche Quelle
Warum können wir den Kernel ohne Bootloader nicht direkt aus dem Flash-Speicher in den RAM laden? Wenn wir es laden, was passiert? Tatsächlich wird der Prozessor dies nicht unterstützen, aber warum folgen wir dem Verfahren?
Bartek, Artless und Felipe geben alle Teile des Bildes wieder.
Jeder eingebettete Prozessortyp (z. B. 386EX, Coretex-A53, EM5200) wird irgendwas tun automatisch, wenn es zurückgesetzt oder eingeschaltet wird. Manchmal dieses etwas unterscheidet sich je nachdem, ob die Stromversorgung aus- und wieder eingeschaltet oder das Gerät zurückgesetzt wird. Bei einigen eingebetteten Prozessoren können Sie etwas ändern basierend auf Spannungen, die an verschiedene Pins angelegt werden, wenn das Gerät eingeschaltet oder zurückgesetzt wird.
Unabhängig davon gibt es eine begrenzte Menge von etwas die ein Prozessor ausführen kann, aufgrund des physischen Speicherplatzes auf dem Prozessor, der zum Definieren dieses etwas erforderlich ist , ob es sich um einen On-Chip-FLASH, einen Befehlsmikrocode oder einen anderen Mechanismus handelt.
Diese Grenze bedeutet, dass etwas ist
- fester Zweck, erledigt eine Sache so schnell wie möglich.
- in Umfang und Leistungsfähigkeit begrenzt, lädt normalerweise einen kleinen Codeblock (häufig einige Kilobyte oder weniger) in einen festen Speicherort und wird vom Anfang des geladenen Codes ausgeführt.
- unveränderbar.
Was ein Prozessor als Reaktion auf ein Zurücksetzen oder Aus- und Wiedereinschalten tut, kann also nicht geändert werden und kann nicht viel tun, und wir möchten nicht, dass er automatisch Hunderte von Megabyte oder Gigabyte in den Speicher kopiert, der möglicherweise nicht vorhanden ist oder nicht initialisiert wurde. und das könnte laaaange dauern.
Also...
Wir richten ein kleines Programm ein, das kleiner ist als die kleinste zulässige Größe für alle Geräte, die wir verwenden werden. Dieses Programm wird dort gespeichert, wo etwas muss es sein.
Manchmal ist das kleine Programm U-Boot. Manchmal ist sogar U-Boot zu groß für den anfänglichen Ladevorgang, sodass das kleine Programm dann wiederum U-Boot lädt.
Der Punkt ist, dass alles, was durch etwas geladen wird , ist veränderbar nach Bedarf für ein bestimmtes System. Wenn es U-Boot ist, großartig, wenn nicht, weiß es, wo das Hauptbetriebssystem oder U-Boot (oder ein anderer Bootloader) geladen werden soll.
U-Boot (allgemein von Bootloadern gesprochen) konfiguriert dann einen minimalen Satz von Geräten, Speicher, Chipeinstellungen usw., damit das Hauptbetriebssystem geladen und gestartet werden kann. Die Hauptinitialisierung des Betriebssystems kümmert sich um jede zusätzliche Konfiguration oder Initialisierung.
Die Reihenfolge ist also:
- Prozessor einschalten oder zurücksetzen
- Etwas lädt anfänglichen Boot-Code (oder eingebetteten Bootloader im U-Boot-Stil)
- Anfänglicher Boot-Code (möglicherweise nicht erforderlich)
- U-Boot (oder ein anderer allgemeiner eingebetteter Bootloader)
- Linux-Init
Der primäre Bootloader ist normalerweise in das Silizium integriert und führt das Laden des ersten USER-Codes durch, der im System ausgeführt wird.
Der Bootloader existiert, weil es kein standardisiertes Protokoll zum Laden des ersten Codes gibt, da es chipabhängig ist. Manchmal kann der Code über eine serielle Schnittstelle, einen Flash-Speicher oder sogar eine Festplatte geladen werden. Es ist die Bootloader-Funktion, um es zu finden.
Sobald der Benutzercode geladen ist und ausgeführt wird, wird der Bootloader nicht mehr verwendet und die Korrektheit der Systemausführung liegt in der Verantwortung des Benutzers.
In der eingebetteten Linux-Kette richtet der primäre Bootloader die Uboot ein und führt sie aus. Dann findet Uboot den Linux-Kernel und lädt ihn.