ARM Linux Neustartprozess

Question

Wie Neustartprozedur auf ARM SOCs unter Linux funktioniert, z. B. initialisieren Bootloader DDR-Speicher neu? Kann mir bitte irgendjemand den Neustart im Detail erklären.

Answer 1

Je nach SoC variiert es sehr. Ich werde etwas wie ein "typisches" beschreiben (Freescale iMX6) ...

Typischerweise wird ein On-Chip-Watchdog-Timer verwendet, um das SoC sauber zurückzusetzen. Manchmal kann ein externer Power Management IC provoziert werden, um einen boardweiten Reset durchzuführen (diese Methode ist möglicherweise besser, da das Risiko vermieden wird, dass externe Chips in einem unerwarteten Zustand "stecken bleiben", aber nicht von allen Board-Designs unterstützt wird).

Nach dem Zurücksetzen startet das SoC seinen normalen Startvorgang: Überprüfen der Optionspins, der Sicherungseinstellungen und der Initialisierung der Uhren und des Startgeräts (z. B. eMMC). Dies wird typischerweise durch einen CPU-Code gesteuert, der von einem kleinen On-Chip-ROM ausgeführt wird.

Entweder die interne Boot-ROM wird DDR-SDRAM-Initialisierung (Einstellungen von Sicherungen genommen mit oder aus einer Datei auf dem Boot-Gerät lesen), oder der Bootloader in den internen RAM-Speicher geladen wird, dann nimmt sie kümmert sich der DDR-Initialisierung (Und andere Dinge). Der U-Boot-Bootloader kann so konfiguriert werden, dass er in jeder Richtung funktioniert.

Schließlich werden der Kernel und DTB in den Speicher geladen und gestartet.

Answer 2

Das ist viel zu breit. Es ist nicht nur vom Hersteller abhängig, sondern auch von Hardware und Software abhängig.

jedoch die typische Einrichtung ist:

1. CPU führt Erststufen-Bootloader (FSB).

   FSB befindet sich auf dem Chip selbst in ROM oder EEPROM und ist sehr klein (AT91RM9200 FSB ist 10kB max, AFAIR). FSB initialisiert dann den minimalen Satz von Peripheriegeräten (Uhren, RAM, Flash), überträgt den Bootloader der zweiten Stufe (U-Boot) in den RAM und führt ihn aus.

2. U-Boot startet.

   U-Boot initialisiert einige andere Hardware (seriell, Ethernet, etc), transferiert den Linux-Kernel in den RAM, bereitet den Zeiger auf die Kernel-Eingabeparameter vor und springt in den Einstiegspunkt.

3. Linux-Kernel startet.

   Magie passiert hier. Das System kann Ihnen nun Cookies über die SSH-Konsole bereitstellen und/oder alles ausführen, was ausgeführt werden muss.

Ein bisschen tiefer gehende Informationen über Warmstart:

Warmstart ist ein Software-Reset, während Kaltstart Einschalten oder Hardware-Reset ist. Einige (meist?) SoCs können die Informationen an FSB/SSB über Warmstart weitergeben. Auf diese Weise können Bootloader die gesamte Bootzeit minimieren, indem die Neuinitialisierung bereits initialisierter Peripheriegeräte übersprungen wird.

Wieder ist dies der typischste Setup aus meiner Erfahrung.

Answer 3

Hinweis Uboot, etc sind nicht erforderlich, sie sind GROSS Overkill, sie sind Betriebssystemen in ihrem eigenen Recht. Um Linux zu laden und zu starten, muss der Speicher hochgefahren werden. Kopieren Sie den Kernel-Zweig mit einigen Registern, die auf Tabellen ausgerichtet sind, die Sie zusammen mit dem Kernel aus dem Flash erstellen oder kopieren.

Was Sie bei einem kalten Reset oder warm tun, liegt an Ihnen, der gleiche Chip und Board keinen Grund, warum zwei Lösungen genau das gleiche tun müssen, es sei denn, es wird von der Hardware angetrieben (wenn Sie einen Wdt zurücksetzen auf von vorne beginnen und das Reset löscht den ganzen Chip einschließlich des DDR-Controllers). Sie müssen nur das System in den Zustand versetzen, den Linux erwartet.

Answer 4

Wie Neustartprozedur funktioniert auf ARM SOCs unter Linux, ...?

Der typische ARM-Prozessor heute im Einsatz ist mit Peripheriegeräten integriert auf einem einzigen IC ein SoC, System auf einem Chip genannt. In der Regel ist der Neustartvorgang nahezu identisch mit einem Power-On-Startvorgang. Bei einem Reset springt der ARM-Prozessor typischerweise auf die Adresse 0.

Hauptspeicher, z.B. DRAM und nichtflüchtiger Speicher, z.B. NAND-Flash, sind in der Regel außerhalb des SoC (das ist Linux-fähig) für maximale Design-Flexibilität.
Aber typischerweise gibt es ein kleines (vielleicht 128 KB) eingebettetes ROM (Nur-Lese-Speicher), um die minimalen Systemkomponenten (z.B. Takte, externe Speicher) zu initialisieren, um Bootstrap-Operationen zu beginnen. Ein Prozessor-Reset führt zur Ausführung dieses Boot-ROMs. (Dieser ROM ist wirklich schreibgeschützt und kann nicht modifiziert werden. Der Code wird während der Chipherstellung in das Silizium maskiert.)
Der SoC kann eine Umreifungsoption haben, um stattdessen einen externen Boot-Speicher wie NOR-Flash oder EEPROM auszuführen. die direkt ausgeführt werden können (dh XIP, Ausführen an Ort und Stelle).
Das hervorstechende Merkmal eines beliebigen ROM, Flash und SRAM, das das Boot-Programm der ersten Stufe verwendet, besteht darin, dass diese Speicher unmittelbar nach einem Reset zugänglich sein müssen.

Eines der Probleme beim Bootstrapping eines Systems, das DRAM für den Hauptspeicher verwendet, ist die Hardware-Initialisierung. Der DRAM-Speichercontroller muss mit kartenspezifischen Parametern initialisiert werden, bevor der Code in den DRAM geladen und ausgeführt werden kann. Also woher kommt dieser boardspezifische Initialisierungscode, da er nicht im Hauptspeicher liegen kann?
Jeder Anbieter hat seine eigene Lösung.
Einige erfordern Speicherkonfigurationsdaten, die im nichtflüchtigen Speicher für den Zugriff auf das Boot-ROM gespeichert werden.
Einige SoCs haben SRAM integriert (das keine Initialisierung wie DRAM erfordert), um ein kleines Bootstrap-Programm der zweiten Stufe auszuführen.
Einige SoCs verwenden NOR-Flash, um ein XIP-Bootstrap-Programm (execute in place) zu halten (z. B. das SPL-Programm von U-Boot).

Jeder SoC-Hersteller verfügt über eine eigene Bootstrap-Methode, um das Betriebssystem zu laden und auszuführen.
Einige Hardware-Strapping lesen GPIO-Pins, um die Quelle der nächsten Stufe der Bootstrap-Sequenz zu ermitteln.
Ein anderer Anbieter kann eine geordnete Liste von Speichern und Geräten verwenden, um nach einem Bootstrap-Programm zu suchen.
Eine andere Technik ist die Verzweigung zu Firmware im NOR-Flash, die direkt ausgeführt werden kann (d. H. XIP, execute in place).

Sobald das Bootstrap-Programm den DRAM initialisiert hat, kann dieser Hauptspeicher verwendet werden, um die nächste Stufe des Bootens zu laden. Das könnte ein ausgefeiltes Boot-Utility wie U-Boot oder (wenn das Bootstrap-Programm in der Lage ist) der Linux-Kernel sein.Ein ROM-Boot-Programm könnte alles tun, um einen ARM-Linux-Kernel (z. B. ETRAX) zu laden, aber häufiger werden mehrere Bootstrap-Programme oder -Stufen zwischen dem Zurücksetzen des Prozessors auf die Ausführung des Betriebssystems ausgeführt.

Die Anforderungen an den Linux-ARM-Kernel sind in folgendem Dokument buchstabiert: Booting ARM Linux
ältere Versionen von Linux ARM verwendet, um die ATAGs Liste grundlegende Konfigurationsinformationen an den Kernel übergeben. Moderne Versionen bieten eine vollständige Board-Konfiguration unter Verwendung einer kompilierten Binärdatei eines Gerätebaums.

... z. B. Boot Loader DDR-Speicher neu initialisieren?

Von den wenigen Beispielen, die ich gesehen habe, konfigurieren die Boot-Programme unbedingt den dynamischen RAM-Controller.

PCs haben ein BIOS und Power On Self Tests, auch bekannt als POST. Die Ausführung von POST ist der Hauptunterschied zwischen einem Power-On-Reset (Kaltstart) und einem Software-Reset (Warmstart oder Neustart). ARM-Systeme führen normalerweise keinen POST aus, so dass Sie normalerweise nur minimale bis keine Unterschiede zwischen den Reset-Typen sehen.