Avvio Linux sulla piattaforma ARM
Descrizione
La piattaforma ARM è la tavola in base all'architettura ARM. Ci sono molti produttori sul mercato che progettano le piattaforme basate su questa architettura. In generale, una piattaforma ARM ha i seguenti elementi costitutivi:
- CPU/SOC: Questa è la principale unità di elaborazione sulla piattaforma. I componenti hanno i componenti interni oltre alla cache, alla scu ecc.
- S-RAM interno: Questa è la RAM che è presente all'interno del SOC. La dimensione di questa memoria è limitata e saranno pochi KB.
- DDR esterno: Questa è la RAM esterna, che è di dimensioni significative rispetto alla RAM interna. Questa memoria funge da memoria di esecuzione per la CPU. In generale, questo è di pochi GB, in base alla progettazione del sistema.
- Dispositivo di avvio: Questo è il dispositivo di archiviazione permanente esterno utilizzato per archiviare le immagini del software necessarie al sistema per l'avvio. Pochi esempi dei componenti sono bootloader, immagine Linux, filesystem root. Questi 3 componenti sono componenti di base necessari per qualsiasi sistema per avvio di Linux. Esempio di dispositivi di avvio sono EMMC, dispositivi di memoria flash NV, scheda SD, memoria USB, ecc. Questi dispositivi possono essere utilizzati solo per l'avvio se il sistema supporta l'avvio con quel supporto. Pochi sistemi hanno più opzioni di avvio, che possono essere controllate da cinghie o switch di immersione. Qualsiasi tipo di avvio richiesto può essere selezionato e le immagini possono programmare sul supporto di avvio. La programmazione delle immagini di avvio può essere eseguita con l'aiuto di un programmatore esterno come Dediprog Strumento.
Immagini per il sistema da avviare
Il primo e più importante elemento necessario per avviare Linux sulla piattaforma ARM è che abbiamo bisogno delle immagini di build di boot loader, kernel Linux e filesystem di root. Queste immagini possono essere compilate se la scheda è progettata interna all'organizzazione ma se il dispositivo viene acquistato tramite un fornitore, dovrebbe fornire le istruzioni sulla generazione di immagini. Anche in alcuni casi, se non forniscono il codice sorgente per compilare o costruire, forniscono le immagini predefinite.
Programmazione delle immagini sul dispositivo di avvio
Dopo che abbiamo immagini pronte per l'avvio sulla piattaforma, dobbiamo bruciare/programmare le immagini sul dispositivo di avvio. Dovrebbero esserci istruzioni disponibili dal fornitore o qualsiasi programmatore HW può essere utilizzato per programmare le immagini sul dispositivo di avvio. L'esempio di tale programmatore è dediprog.
Dediprog è lo strumento che può essere utilizzato per programmare l'immagine flash al flash NV. Questo è il caso della modalità di avvio flash. I saltatori o la configurazione sono necessari per abilitare l'avvio flash se sono presenti più dispositivi di avvio.
Snapshot di Dediprog:
Dopotutto, le immagini sono programmate nel supporto di avvio e tutta la configurazione di avvio viene eseguita per abilitare il tipo di avvio in cui abbiamo mantenuto le immagini per l'avvio.
L'avvio di Linux può essere considerato in più fasi:
- Fase rom di avvio
- Avvio del primo caricatore di avvio
- Avvio del caricatore di avvio del secondo stadio, questo è in generale.
- Avvio di Linux
- Montaggio di rootfs e esecuzione di script Init Linux fino alla console di accesso.
Discutiamo ora di tutte queste fasi di avvio in dettaglio.
Fase rom di avvio
In questa fase, non c'è accesso al DDR esterno, tutta l'esecuzione deve essere eseguita nell'S-RAM interno. Non appena il sistema è acceso, il codice di avvio inizializza l'interfaccia di avvio e quindi recupera il primo caricatore di avvio stadio. Una volta che il caricatore di avvio è disponibile nella RAM interna ed è pronto per essere eseguito, il controllo viene trasferito al primo caricatore di avvio.
Avvio del primo caricatore di avvio
Immediatamente dopo l'accensione della scheda, non è disponibile alcun accesso alla RAM esterna per la CPU. L'esecuzione inizia dal vettore di ripristino. Resect Vector è la posizione da dove la CPU inizia a eseguire le prime istruzioni di programmazione. In questa fase, è disponibile solo RAM interno. Successivamente, il DDR esterno viene inizializzato e quindi il bootloader del secondo stadio viene recuperato dal supporto di avvio e caricato sul DDR esterno iniziale e il controller viene passato al caricatore di avvio del secondo stadio I.e., U-boot.
Avvio del caricatore di avvio o a U-boot del secondo stadio
Questo è un software minimo necessario per la configurazione dell'ambiente necessario da Linux Kernel prima di avviare. Vari driver e interfacce HW sono abilitati in ambiente U-boot. Questo bootloader fornisce la riga di comando e quindi possiamo modificare le diverse configurazioni in fase di esecuzione. Lo scopo principale di questa fase è preparare l'installazione/scheda per il kernel Linux. In questa fase, l'immagine Linux può essere recuperata da più opzioni disponibili. L'immagine Linux può essere caricata su qualsiasi interfaccia dalle diverse interfacce. Questa fase prende l'immagine del kernel Linux e passa il controllo di esecuzione al bootloader.
Avvio di Linux
Dopo la seconda fase, Boot Loader ha copiato l'immagine Linux sul DDR esterno. Passerà il controllo dell'esecuzione all'immagine Linux. Una volta che l'immagine Linux inizia l'avvio, inizia l'inizializzazione di tutti i dispositivi/periferiche sulla scheda. Inizializza tutto il sottosistema, inclusi tutti i controller e i dispositivi. Dopo che tutti i driver e i dispositivi sono stati inizializzati in questa fase e il kernel Linux è in funzione al massimo possibile.
Una volta terminato l'avvio o l'inizializzazione dei driver, c'è una ricerca del dispositivo rootfs. La posizione del dispositivo rootfs può anche essere configurata o modificata dai parametri della riga di comando di Linux. I parametri della riga di comando per Linux sono le variabili di ambiente nell'ambiente a U-boot, quindi per aggiornare la posizione del dispositivo Rootsfs è solo una modifica della variabile di ambiente in U-boot. Ci sono altre informazioni disponibili anche in ambiente U-boot.
Pochi esempi sono la posizione del processo INIT, la dimensione della memoria, che consentono il devMEM, aumentando i loghi del kernel ecc. Sono disponibili poche altre opzioni di variabile dell'ambiente U-boot per facilitare altri casi utente in U-boot. Ad esempio, l'assegnazione dell'indirizzo IP nell'u-boot viene eseguita con l'aiuto della variabile di ambiente.
Montaggio di rootfs e esecuzione di script di Linux init:
Il dispositivo rootfs viene cercato e montato e quindi il processo INIT viene cercato all'interno del dispositivo rootfs. Dopo che l'immagine Init si trova il controllo viene trasmesso all'inizio dopo aver invocato il processo INIT. Questo è il primo processo di Userland che inizia l'esecuzione. Una volta che init ottiene il controllo, inizializza i servizi di spazio utenti eseguendo gli script INIT.
Tutti i demoni vengono avviati e i servizi a livello di sistema vengono avviati eseguendo i servizi INIT presenti in / etc / o se il sistema è basato sul sistema SystemCtl, tutti i servizi vengono avviati secondo le linee guida menzionate per il sistema SystemCtl. Dopo aver avviato tutti i servizi, il programma Shell viene invocato che crea un prompt della sessione di accesso per l'utente.
L'utente può utilizzare questa console di comando per richiedere vari servizi dal kernel Linux.
Ora, vediamo i registri di avvio del sistema Linux che dimostreranno la fase di avvio di cui abbiamo discusso finora. Nota questi non sono registri completi. Ho rimosso poche linee tra come sono tronchi enormi. Non pertinente all'argomento, quindi ho appena fornito i registri rilevanti per la nostra discussione.
Nota: la fase di avvio ROM non può essere osservata nei registri, poiché UART non è disponibile in questa fase.
Avvio del primo caricatore di avvio in fase:
U-boot SPL 2019.04 (17 agosto 2021 - 18:33:14 +0000)
Cercando di avviare da Ram
Avvio del caricatore di avvio o boot a U al secondo stadio:
U-Boot 2019.04 (17 agosto 2021 - 18:33:14 +0000)
SOC: AST2600-A1
RST: Accendi
Modalità LPC: SIO: Abilita: superio-2e
ETH: Mac0: RMII/NCSI, MAC1: RMII/NCSI, MAC2: RMII/NCSI, MAC3: RMII/NCSI
Modello: fornitore BMC
DRAM: già inizializzato, 1008 MIB (capacità: 1024 MIB, VGA: 16 MIB), ECC OFF
PCIE-0: collegamento verso il basso
MMC: EMMC_SLOT0@100: 0
Ambiente di caricamento da SPI Flash ... SF: rilevato N25Q256A con dimensione della pagina 256 byte, Cancella dimensione 4 KIB, totale 32 MIB
*** AVVERTENZA - Bad CRC, utilizzando l'ambiente predefinito
In: serial@1e784000
Fuori: serial@1e784000
Err: serial@1e784000
Modello: fornitore BMC
EEPROM ETH2ADDR: EA = AA: BB: CC: DD: DE: E0
BMC ETH2ADDR = AA: BB: CC: DD: DE: E3
NET: FTGMAC100_PROBE - NCSI rilevato
ETH2: ftgmac@1e670000ftgmac100_probe - NCSI rilevato
ATTENZIONE: FTGMAC@1E690000 (ETH3) Utilizzo dell'indirizzo MAC casuale - FA: 12: FB: CA: BC: FF
, ETH3: FTGMAC@1E690000
Premi qualsiasi chiave per fermare l'autoboot: 2 1 0
## Caricamento del kernel dall'immagine Fit a 20100000 ..
Utilizzo della configurazione "conf-1"
Provando la sottopimazione del kernel "kernel-1"
Descrizione: Kernel Linux
Tipo: immagine del kernel
.
.
.
.
Compressione: non compressa
Avvio dei dati: 0x2067e1c4
Dimensione dei dati: 54387 byte = 53.1 kib
Architettura: braccio
Verificare l'integrità hash ... OK
Avvio utilizzando FDT BLOB a 0x2067E1C4
Caricamento dell'immagine del kernel ... OK
Caricamento di Ramdisk su 8fbe0000, fine 8ffffbf0 ... ok
Caricamento dell'albero del dispositivo su 8fbcf000, fine 8fbdf472… ok
Avvio di Linux:
Iniziare il kernel ..
[0.000000] Avvio di Linux su CPU fisica 0xf00
[0.000000] Linux versione 5.1.3.SDK-V00.05.07 (cienauser@haxv-sratore-2) (GCC versione 8.3.0 (Buildroot 2019.05-RC2)) #3 SMP Sun 29 agosto 14:19:01 UTC 2021
[0.000000] CPU: processore ARMV7 [410fc075] revisione 5 (ARMV7), CR = 10C5387D
[0.000000] CPU: istruzioni DIV disponibili: codice di divisione patching
[0.000000] CPU: cache dei dati non aliasing PIPT / VIPT, cache di istruzioni di aliasing VIPT
[0.000000] di: FDT: Modello macchina: AST2600 A1 EVB
[0.000000] Politica di memoria: dati cache writealloc
[0.000000] Memoria riservata: pool di memoria CMA creata a 0xbb000000, dimensione 64 MIB
[0.000000] di: MEM riservato: video nodo inizializzato, ID compatibile condiviso-dma-pool
[0.000000] Memoria riservata: pool di memoria CMA creata a 0xB7000000, dimensione 64 MIB
[0.000000] di: MEM riservato: RVA del nodo inizializzato, ID compatibile condiviso-dma-pool
[0.000000] Memoria riservata: pool di memoria DMA creata a 0xB6E00000, dimensione 2 MIB
[0.000000] di: MEM riservato: nodo inizializzato ssp_memory, ID compatibile condiviso-dma-pool
[0.000000] Memoria riservata: pool di memoria DMA creata a 0xb6d00000, dimensione 1 MIB
.
.
.
.
[1.184367] 0x0000000000-0x0000000f0000: "U-boot"
[1.191246] 0x0000000f0000-0x000000100000: "U-boot-env"
[1.198363] 0x000000100000-0x000002060000: "Fit"
[1.203661] MTD: partizione "adattamento" si estende oltre la fine del dispositivo "BMC" - dimensioni troncate su 0x1f00000
[1.215347] fornitore-SMC 1E620000.SPI: BUS_WIDTH 2, usando la frequenza SPI a 50 MHz
[1.223375] fornitore-SMC 1E620000.SPI: N25Q256A (32768 KBytes)
[1.229723] fornitore-SMC 1E620000.SPI: finestra CE1 [0x22000000 - 0x240000] 32 MB
[1.237996] fornitore-SMC 1E620000.SPI: finestra CE2 [0x24000000 - 0x30000000] 192 MB
[1.246357] fornitore-SMC 1E620000.SPI: Leggi Registro di controllo: [203C0441]
[1.316884] fornitore-SMC 1E630000.SPI: BUS_WIDTH 2, usando la frequenza SPI a 50 MHz
[1.324821] fornitore-SMC 1E630000.SPI: byte ID jedec non riconosciuti: 00 00 00 00 00
[1.333384] fornitore-SMC 1E630000.SPI: Chip 0 non esiste.
.
.
.
[1.631342] UHCI_HCD: driver interfaccia del controller host universale USB
[1.638622] Platform-UHCI 1E6B0000.USB: 2 porte rilevate dall'albero del dispositivo
[1.646217] Platform-UHCI 1E6B0000.USB: soluzioni alternative per l'implementazione del fornitore abilitato
[1.664722] Platform-UHCI 1E6B0000.USB: controller host generico UHCI
[1.671844] piattaforma-uhci 1e6b0000.USB: nuovo bus USB registrato, numero di autobus assegnato 2
[1.680671] Platform-UHCI 1E6B0000.USB: IRQ 42, IO MEM 0x1E6B0000
[1.687977] USB USB2: nuovo dispositivo USB trovato, IdVendor = 1D6B, IdProduct = 0001, BCDDEVICE = 5.01
[1.697237] USB USB2: Nuove stringhe del dispositivo USB: MFR = 3, Prodotto = 2, SerialNumber = 1
[1.705311] USB USB2: Prodotto: Controller host UHCI generico
[1.711542] USB USB2: produttore: Linux 5.1.3.SDK-V00.05.07 uhci_hcd
[1.718824] USB USB2: serialnumber: 1e6b0000.USB
[1.724589] Hub 2-0: 1.0: hub USB trovato
[1.728830] Hub 2-0: 1.0: 2 porte rilevate
[1.734689] USBCORE: nuovo driver di interfaccia registrato USB-STORAGE
[1.753347] VENDOR_VHUB 1E6A0000.USB-VHUB: hub virtuale inizializzato in modalità USB2
[1.762327] driver di voci i2c /dev
[1.767491] i2c_new_vendor 1e78a080.I2C-BUS: NEW-I2C: I2C-BUS [0]: modalità adattatore [100 kHz] [2]
.
.
.
[2.960181] Memoria del kernel inutilizzata: 1024K
[2.970760] MMCBLK0: MMC0: 0001 R1J57L 27.5 Gib
[2.976119] MMCBLK0BOOT0: MMC0: 0001 R1J57L Partizione 1 16.0 mib
[2.983067] MMCBLK0BOOT1: MMC0: 0001 R1J57L Partizione 2 16.0 mib
[2.989980] MMCBLK0RPMB: MMC0: 0001 R1J57L Partizione 3 128 Kib, Chardev (246: 0)
[2.999275] MMCBLK0: P1
[3.012035] Mappings controllati W+X: Passato, nessuna pagine W+X trovate
Montaggio di rootfs e esecuzione di script di Linux init
[3.018367] run /sbin /init come processo init
Conclusione
Abbiamo visto il processo di avvio Linux completo in dettaglio con i registri di esempio. Abbiamo anche discusso dei vari elementi costitutivi del boot Linux. Sono stati discussi anche pochi altri prerequisiti necessari per Linux per l'avvio. Ci sono varie fasi coinvolte nello stivale Linux su qualsiasi scheda di processore ARM, tutte le fasi sono state discusse in dettaglio e sono mappate con i registri di avvio del campione. Questa discussione è sufficiente per fornire la comprensione di base sull'avvio Linux sui sistemi ARM.