Linux Boot auf der Armplattform

Wir werden auf den ARM -Plattformen diskutieren. Was sind die Bausteine ​​solcher Plattformen?. Wenn wir auf der Platine einschalten und Linux auf dem System installiert ist. Was sind die anderen Komponenten, die für die Startung von Linux auf jeder ARM -Plattform benötigt werden??

Beschreibung

Die ARM -Plattform ist das Board, das auf der Armarchitektur basiert. Es gibt viele Hersteller auf dem Markt, die die Plattformen basierend auf dieser Architektur entwerfen. Im Allgemeinen hat eine Armplattform die folgenden Bausteine:

1. CPU/SOC: Dies ist die Hauptverarbeitungseinheit auf der Plattform. Komponenten haben auch die internen Komponenten wie Cache, SCU usw.
2. Interner S-RAM: Dies ist der RAM, der im SOC vorhanden ist. Die Größe dieses Speichers ist begrenzt und wird nur wenige KBs sein.
3. Externer DDR: Dies ist der externe RAM, der im Vergleich zu internem RAM erheblich groß ist. Dieser Speicher fungiert als Ausführungsspeicher für CPU. Im Allgemeinen basiert dies nur wenige GBs, basierend auf dem Systemdesign.
4. Start Gerät: Dies ist das externe dauerhafte Speichergerät, mit dem die vom System zum Booten benötigten Softwarebilder gespeichert werden können. Nur wenige Beispiele für die Komponenten sind Bootloader, Linux -Bild, Root -Dateisystem. Diese 3 Komponenten sind grundlegende Komponenten, die von jedem System zum Booten von Linux benötigt werden. Beispiel für Boot -Geräte sind EMMC, NV Flash -Speichergeräte, SD -Karte, USB -Speicherstick usw. Diese Geräte können nur zum Booten verwendet werden, wenn das System den Booting mit diesen Medien unterstützt. Nur wenige Systeme verfügen über mehrere Startoptionen, die entweder durch Träger oder Dip -Switches gesteuert werden können. Jeder erforderliche Boot -Typ kann ausgewählt werden und Bilder können im Boot -Medium programmiert werden. Die Programmierung der Bootsbilder kann mit Hilfe eines externen Programmierers wie Dediprog -Tool durchgeführt werden.

Bilder für das System zum Booten

Das erste und wichtigste Element, das für den Booten von Linux auf der ARM -Plattform benötigt wird, ist die Build -Bilder von Bootloader-, Linux -Kernel- und Root -Dateisystemen. Diese Bilder können kompiliert werden, wenn das Board in der Organisation intern angelegt ist, wenn das Gerät über einen Anbieter gekauft wird. Selbst in einigen Fällen stellen sie den Quellcode zum Kompilieren oder Erstellen nicht an.

Programmierung der Bilder mit dem Boot -Gerät

Nachdem wir Bilder auf der Plattform bereit haben, müssen wir die Bilder auf dem Boot -Gerät verbrennen/programmieren. Es sollte Anweisungen beim Anbieter oder einem HW -Programmierer zur Verfügung stehen, um die Bilder auf dem Boot -Gerät zu programmieren. Beispiel eines solchen Programmierers ist Dediprog.

Dediprog ist das Tool, mit dem das Flash -Bild auf den NV -Flash programmiert werden kann. Dies ist der Fall im Flash -Booting -Modus. Jumper oder Konfiguration werden benötigt, um den Flash -Boot zu aktivieren, wenn mehrere Boot -Geräte vorhanden sind.

Schnappschuss von Dediprog:

Schließlich werden die Bilder in die Startmedien programmiert und die gesamte Boot -Konfiguration erfolgt, um den Startyp zu aktivieren, in dem wir die Bilder zum Booten aufbewahrt haben.

Das Booten des Linux kann in mehreren Phasen berücksichtigt werden:

1. Boot -ROM -Phase
2. Booten des Starteladers der ersten Stufe
3. Booten des Bootloaders der zweiten Stufe, das ist im Allgemeinen U-Boot.
4. Booting von Linux
5. Montage von RootFs und Ausführung von Linux -Init -Skripten bis zur Anmeldekonsole.

Lassen Sie uns jetzt all diese Bootsbühnen detailliert diskutieren.

Boot -ROM -Phase

In diesem Stadium gibt es keinen Zugriff auf das externe DDR, die gesamte Ausführung muss im internen S-RAM erfolgen. Sobald das System eingeschaltet ist, initialisiert Start -ROM -Code die Boot -Schnittstelle und holt dann den Startload der ersten Stufe ab. Sobald der Bootloader im internen RAM verfügbar ist und ausgeführt wird, wird die Steuerung auf den Startlader der ersten Stufe übertragen.

Booten des Starteladers der ersten Stufe

Unmittelbar nach dem Einschalten des Boards gibt es keinen Zugriff auf einen externen RAM für CPU. Die Ausführung beginnt mit dem Reset -Vektor. Reset -Vektor ist der Ort, an dem die CPU mit der Ausführung der ersten Programmieranweisungen beginnt. Zu diesem Zeitpunkt ist nur interner RAM verfügbar. Später wird der externe DDR initialisiert und dann wird der Bootloader der zweiten Stufe aus dem Startmedium abgerufen und an den initialisierten externen DDR geladen und der Controller wird an den Startlader der zweiten Stufe weitergeleitet.e., U-Boot.

Booting des Bootloaders oder U-Bootes der zweiten Stufe

Dies ist eine minimale Software, die für das von Linux Kernel vor dem Booten benötigte Umgebungsaufbau benötigt wird. Verschiedene Treiber und HW-Schnittstellen sind in der U-Boot-Umgebung aktiviert. Dieser Bootloader stellt die Befehlszeile bereit und können die verschiedenen Konfigurationen zur Laufzeit ändern. Der Hauptzweck dieser Phase besteht darin, das Setup/die Platine für den Linux -Kernel vorzubereiten. Zu diesem Zeitpunkt kann Linux -Bild aus mehreren verfügbaren Optionen abgerufen werden. Linux -Bild kann über jede Schnittstelle von den verschiedenen Schnittstellen geladen werden. Diese Stufe holt das Linux -Kernel -Bild ab und übergibt die Ausführungssteuerung an den Bootloader.

Linux booten

Nach der zweiten Stufe hat Boot Loader das Linux -Bild an den externen DDR kopiert. Es wird die Ausführungssteuerung an das Linux -Bild übergeben. Sobald das Linux -Bild mit dem Booten beginnt, startet es die Initialisierung aller Geräte/Peripheriegeräte auf der Platine. Es initialisiert das gesamte Subsystem, einschließlich aller Controller und Geräte. Nachdem alle Treiber und Geräte in diesem Stadium initialisiert werden und Linux -Kernel maximal möglich ist.

Sobald der Booting oder die Initialisierung der Treiber abgeschlossen ist, wird das RootFS -Gerät durchsucht. Der Standort des RootFS -Geräts kann auch aus den Befehlszeilenparametern von Linux konfiguriert oder geändert werden. Befehlszeilenparameter für Linux sind die Umgebungsvariablen in der U-Boot-Umgebung. Damit der Standort des RootsFS-Geräts nur eine Änderung der Umgebungsvariablen in U-Boot ist. In der U-Boot-Umgebung sind andere Informationen sowie andere Informationen verfügbar.

Nur wenige Beispiele sind Init -Prozessort, Speichergröße, Aktivieren des DevMems, Erhöhen der Kernel -Loblevels usw. Es stehen nur wenige andere Optionen für U-Boot-Umgebungsvariablen zur Verfügung, um andere Benutzerfälle im U-Boot zu erleichtern. Beispielsweise erfolgt die IP-Adresszuweisung im U-Boot mit Hilfe der Umgebungsvariablen.

Montage von RootFs und Ausführung von Linux -Init -Skripten:

Das RootFS -Gerät wird durchsucht und montiert und dann wird der Init -Prozess im RootFS -Gerät durchsucht. Nachdem das Init -Bild gefunden wurde, wird die Steuerung nach dem Aufrufen des Init -Prozesses an den Init weitergeleitet. Dies ist der erste Userland -Prozess, der die Ausführung beginnt. Sobald Init die Kontrolle erhält, initialisiert es die UserSpace -Dienste, indem die Init -Skripte ausgeführt werden.

Alle Dämonen werden gestartet und die Dienste der Systemebene werden entweder mit der Ausführung der in / usw. vorhandenen Init -Dienste gestartet. Nachdem alle Dienste gestartet wurden, wird das Shell -Programm aufgerufen, wodurch eine Eingabeaufforderung für die Login -Sitzung für den Benutzer erstellt wird.

Der Benutzer kann diese Befehlskonsole verwenden, um verschiedene Dienste aus dem Linux -Kernel anzufordern.

Lassen Sie uns nun die Startprotokolle des Linux -Systems sehen, die die Startphase demonstrieren, die wir bisher diskutiert haben. Beachten Sie, dass dies keine vollständigen Protokolle sind. Ich habe nur wenige Zeilen dazwischen entfernt, da es sich um große Protokolle handelt. Nicht relevant für das Thema, daher habe ich gerade die für unsere Diskussion relevanten Protokolle bereitgestellt.

Hinweis: Die Boot -ROM -Phase kann in Protokollen nicht beobachtet werden, da UART zu diesem Zeitpunkt nicht verfügbar ist.
Booten des Startladers der ersten Stufe:
U-Boot SPS 2019.04 (17. August 2021 - 18:33:14 +0000)
Der Versuch, vom RAM zu booten
Booten des Bootloaders der zweiten Stufe oder des U-Bootes:
U-Boot 2019.04 (17. August 2021 - 18:33:14 +0000)
SOC: AST2600-A1
RST: Macht auf
LPC-Modus: SIO: Enable: Superio-2E
ETH: MAC0: RMII/NCSI, MAC1: RMII/NCSI, MAC2: RMII/NCSI, MAC3: RMII/NCSI
Modell: Verkäufer BMC
DRAM: Bereits initialisiert, 1008 MIB (Kapazität: 1024 MIB, VGA: 16 MIB), ECC aus
PCIE-0: Link Down
MMC: EMMC_SLOT0@100: 0
Ladeumgebung von SPI Flash… SF: Erkennt N25Q256A mit Seitengröße 256 Bytes, Löschgröße 4 KIB, Gesamt 32 MIB
*** WARNUNG - Bad CRC, verwendete die Standardumgebung
In: serial@1e784000
Aus: serial@1e784000
ERR: serial@1e784000
Modell: Verkäufer BMC
EEPROM ETH2ADDR: EA = AA: BB: CC: DD: DE: E0
BMC ETH2ADDR = AA: BB: CC: DD: DE: E3
NET: FTGMAC100_PROBE - NCSI erkannt
ETH2: ftgmac@1e670000ftgmac100_Probe - NCSI erkannt
WARNUNG: FTGMAC@1E690000 (ETH3) mit zufälliger MAC -Adresse - FA: 12: FB: CA: BC: FF
, ETH3: ftgmac@1e690000
Schlagen Sie eine beliebige Taste, um Autoboot zu stoppen: 2 1 0
## Kernel von Fit Image bei 20100000…
Verwenden der Konf-1-Konfiguration
Versuch von Kernel-1-Kernel-Subimage
Beschreibung: Linux -Kernel
Typ: Kernelbild
.
.
.
.
Komprimierung: unkomprimiert
Daten beginnen: 0x2067e1c4
Datengröße: 54387 Bytes = 53.1 Kib
Architektur: Arm
Überprüfung der Hash -Integrität… ok
Booten mit dem FDT -Blob unter 0x2067e1c4
Kernbild laden… ok
Laden von Ramdisk auf 8fbe0000, Ende 8ffffbf0… OK
Ladegerätebaum auf 8FBCF000, Ende 8FBDF472… OK
Booting Linux:
Kernel starten…
[0.000000] linux auf der physischen CPU 0xf00 Booten
[0.000000] Linux Version 5.1.3.SDK-V00.05.07 (cienauser@haxv-shrathore-2) (GCC Version 8.3.0 (Buildroot 2019.05-RC2)) #3 SMP Sun 29. August 14:19:01 UTC 2021
[0.000000] CPU: ARMV7 -Prozessor [410FC075] Revision 5 (ARMV7), CR = 10C5387D
[0.000000] CPU: DIV -Anweisungen verfügbar: Patching Division Code
[0.000000] CPU: PIPT / Vipt -Nicht -Aliasing -Daten -Cache, VIPT -Aliasing -Befehls -Cache
[0.000000] von: FDT: Maschinenmodell: AST2600 A1 EVB
[0.000000] Speicherrichtlinie: Datencache WriteAlloc
[0.000000] Reservierter Speicher: CMA -Speicherpool unter 0xBB000000, Größe 64 MIB
[0.000000] von: reserviertem mem: initialisiertes Knotenvideo, kompatible ID Shared-DMA-Pool
[0.000000] Reserved Speicher: CMA -Speicherpool unter 0xB7000000, Größe 64 MIB
[0.000000] von: reserviertem MEM: Initialisierte Knoten-RVAs, kompatible ID Shared-DMA-Pool
[0.000000] Reserved Speicher: Erstellt DMA -Speicherpool unter 0xb6e00000, Größe 2 MIB
[0.000000] von: reserviertem mem: initialisierter Knoten ssp_memory, kompatible ID Shared-DMA-Pool
[0.000000] Reserved Speicher: Erstellt DMA -Speicherpool unter 0xb6d00000, Größe 1 MIB
.
.
.
.
[1.184367] 0x000000000000-0x00000f0000: "U-Boot"
[1.191246] 0x00000f0000-0x0000100000: "U-Boot-Env"
[1.198363] 0x000000100000-0x000002060000: "Fit"
[1.203661] MTD: Partition "Fit" erstreckt sich über das Ende von Geräte "BMC" - Größe, die auf 0x1f00000 verkürzt wird
[1.215347] Hersteller-SMC 1E620000.SPI: BUS_WIDTH 2, mit einer 50 -MHz -SPI -Frequenz
[1.223375] Hersteller-SMC 1E620000.SPI: N25Q256A (32768 KBYTES)
[1.229723] Hersteller-SMC 1E620000.SPI: CE1 -Fenster [0x22000000 - 0x24000000] 32MB
[1.237996] Hersteller-SMC 1E620000.SPI: CE2 -Fenster [0x24000000 - 0x30000000] 192 MB
[1.246357] Hersteller-SMC 1E620000.SPI: Lesen Sie das Kontrollregister: [203c0441]
[1.316884] Hersteller-SMC 1E630000.SPI: BUS_WIDTH 2, mit einer 50 -MHz -SPI -Frequenz
[1.324821] Hersteller-SMC 1E630000.SPI: Nicht anerkannte JEDEC ID -Bytes: 00 00 00 00 00 00
[1.333384] Hersteller-SMC 1E630000.SPI: Chip 0 existiert nicht.
.
.
.
[1.631342] UHCI_HCD: USB Universal Host Controller Interface -Treiber
[1.638622] Plattform-UHCI 1E6B000000.USB: Erkennete 2 Ports aus Gerätebaum
[1.646217] Plattform-UHCI 1E6B000000.USB: Aktivierungsumgehungsumgehungsantriebsanbieter -Implementierung
[1.664722] Plattform-UHCI 1E6B000000.USB: Generisches UHCI -Host -Controller
[1.671844] Plattform-UHCI 1E6B0000.USB: Neuer USB -Bus registriert, zugewiesene Busnummer 2
[1.680671] Plattform-UHCI 1E6B000000.USB: IRQ 42, IO MEM 0x1E6B0000
[1.687977] USB USB2: Neues USB -Gerät gefunden, idvendor = 1D6B, IDPRODUCT = 0001, BCDDEVICE = 5.01
[1.697237] USB USB2: Neue USB -Gerätezeichenfolgen: MFR = 3, Produkt = 2, SerialNumber = 1
[1.705311] USB USB2: Produkt: Generisches UHCI -Host -Controller
[1.711542] USB USB2: Hersteller: Linux 5.1.3.SDK-V00.05.07 UHCI_HCD
[1.718824] USB USB2: SerialNumber: 1E6B0000.USB
[1.724589] Hub 2-0: 1.0: USB -Hub gefunden
[1.728830] Hub 2-0: 1.0: 2 erfasste Ports
[1.734689] USBCORE: Registrierter neuer Schnittstellen-Treiber USB-Storage
[1.753347] VENDOR_VHUB 1E6A0000.USB-VHUB: Initialisierter virtueller Hub im USB2-Modus initialisiert
[1.762327] I2C /Dev Entries Treiber
[1.767491] I2C_New_Vendor 1E78A080.I2C-Bus: New-I2C: I2C-Bus [0]: Adapter [100 kHz] Modus [2]
.
.
.
[2.960181] Befreiung unbenutzter Kernel -Speicher: 1024k
[2.970760] MMCBLK0: MMC0: 0001 R1J57L 27.5 Gib
[2.976119] MMCBLK0BOOT0: MMC0: 0001 R1J57L Partition 1 16.0 MIB
[2.983067] MMCBLK0BOOT1: MMC0: 0001 R1J57L Partition 2 16.0 MIB
[2.989980] MMCBLK0RPMB: MMC0: 0001 R1J57L Partition 3 128 KIB, Chardev (246: 0)
[2.999275] mmcblk0: p1
[ 3.012035] überprüft w+x Mappings: bestanden, keine W+x Seiten gefunden
Montage von RootFs und Ausführung von Linux -Init -Skripten
[ 3.018367] run /sbin /init als Init -Prozess

Abschluss

Wir haben den vollständigen Linux -Startvorgang in Details mit Beispielprotokollen gesehen. Wir haben auch die verschiedenen Bausteine ​​des Linux -Bootings besprochen. Nur wenige andere Voraussetzungen, die für Linux zum Booten benötigt wurden, wurden ebenfalls diskutiert. An dem Linux -Start auf einer ARM -Prozessorplatte sind verschiedene Phasen beteiligt. Alle Stufen wurden ausführlich erörtert und mit den Beispielstartprotokollen abgebildet. Diese Diskussion reicht aus, um das grundlegende Verständnis für das Linux -Booting auf ARM -Systemen zu vermitteln.