Linux Boot på ARM -plattformen

Linux Boot på ARM -plattformen
Vi vil diskutere på armplattformene. Hva er byggesteinene til slike plattformer. Når vi kjører på brettet og Linux er installert på systemet, er det utløses tavlekraft på sekvensering. Hva er de andre komponentene som trengs for å starte Linux på hvilken som helst ARM -plattform?

Beskrivelse

Armplattform er brettet basert på armarkitekturen. Det er mange produsenter i markedet som designer plattformene basert på denne arkitekturen. Generelt har en ARM -plattform følgende byggesteiner:

  1. CPU/SOC: Dette er hovedbehandlingsenheten på plattformen. Komponenter har de interne komponentene så vel som hurtigbuffer, SCU osv.
  2. Intern S-Ram: Dette er rammen som er til stede i SOC. Størrelsen på dette minnet er begrenset og vil være få KB.
  3. Ekstern DDR: Dette er den eksterne RAM, som er av betydelig størrelse sammenlignet med intern RAM. Dette minnet fungerer som utførelsesminnet for CPU. Generelt er dette av få GB -er, basert på systemdesign.
  4. Oppstartsenhet: Dette er den eksterne permanente lagringsenheten som brukes til å lagre programvarebildene som trengs av systemet for å starte opp. Få eksempler på komponentene er bootloaders, Linux -bilde, rotfilsystem. Disse 3 komponentene er grunnleggende komponenter som trengs av ethvert system for å starte linux. Eksempel på oppstartsenheter er EMMC, NV Flash Memory -enheter, SD -kort, USB -minnepinne, etc. Disse enhetene kan bare brukes til å starte opp hvis systemet støtter oppstart med det mediet. Få system har flere oppstartsalternativer, som kan kontrolleres av enten stropper eller DIP -brytere. Enhver nødvendig oppstartstype kan velges og bilder kan programmeres til oppstartsmediene. Programmering av oppstartsbildene kan gjøres ved hjelp av noen eksterne programmerer som Dediprog Tool.

Bilder for systemet å starte opp

Første og viktigste element som trengs for å starte opp Linux på ARM -plattformen, er at vi trenger byggbilder av oppstartslastere, Linux -kjerne og rotfilsystemer. Disse bildene kan utarbeides hvis styret er designet internt for organisasjonen, men hvis enheten er kjøpt gjennom en eller annen leverandør, bør han gi instruksjonene på bildegenerasjonen. Selv i noen tilfeller, hvis de ikke gir kildekoden for å kompilere eller bygge, gir de de forhåndsbygde bildene.

Programmering av bildene til oppstartsenheten

Etter at vi har bilder klare til å starte opp på plattformen, må vi brenne/programmere bildene på oppstartsenheten. Det skal være instruksjon tilgjengelig fra leverandøren eller hvilken som helst HW -programmerer kan brukes til å programmere bildene til oppstartsenheten. Eksempel på slik programmerer er dediprog.

Dediprog er verktøyet som kan brukes til å programmere flash -bildet til NV -blitsen. Dette er tilfelle av blitzoppstartsmodus. Hoppere eller konfigurasjon er nødvendig for å aktivere Flash -oppstarten hvis flere oppstartsenheter er til stede.

Øyeblikksbilde av dediprog:

Tross alt er bildene programmert inn i oppstartsmediene, og all oppstartkonfigurasjonen gjøres for å aktivere oppstartstypen der vi har beholdt bildene for oppstart.

Oppstart av Linux kan vurderes i flere stadier:

  1. Boot ROM -fase
  2. Oppstart av den første trinns oppstartslasteren
  3. Oppstart av andre trinns oppstartslaster, dette er u-boot generelt.
  4. Oppstart av Linux
  5. Montering av rootfs og utførelse av Linux init -skript til påloggingskonsollen kommer.

La oss diskutere alle disse oppstartstadiene i detaljer nå.

Boot ROM -fase

På dette stadiet er det ingen tilgang til den eksterne DDR, all utførelse må gjøres i det interne S-RAM. Så snart systemet er slått på, initialiserer Boot ROM -koden oppstartsgrensesnittet og henter deretter den første trinns oppstartslasteren. Når oppstartslasteren er tilgjengelig i intern RAM og er klar til å utføre, blir kontrollen overført til den første trinns oppstartslasteren.

Oppstart av den første trinns oppstartslasteren

Umiddelbart etter at styret er slått på, er det ingen tilgang til ekstern RAM tilgjengelig for CPU. Utførelse starter fra tilbakestillingsvektoren. Tilbakestill vektor er stedet der CPU begynner å utføre første programmeringsinstruksjoner. På dette stadiet er det bare internt RAM som er tilgjengelig. Senere blir den eksterne DDR initialisert, og deretter hentes andre trinns bootloader fra oppstartsmediet og lastes til den initialiserte eksterne DDR og kontrolleren blir sendt videre til den andre trinns oppstartslaster I.e., u-boot.

Oppstart av andre trinns oppstartslaster eller u-boot

Dette er minimal programvare som trengs for miljøoppsettet som er nødvendig av Linux -kjernen før oppstart. Ulike drivere og HW-grensesnitt er aktivert i U-Boot-miljøet. Denne bootloaderen gir kommandolinjen, og vi kan derfor endre de flere konfigurasjonene ved kjøretid. Hovedformålet med dette stadiet er å utarbeide oppsettet/brettet for Linux -kjernen. På dette stadiet kan Linux -bildet hentes fra flere tilgjengelige alternativer. Linux -bilde kan lastes over et hvilket som helst grensesnitt fra de forskjellige grensesnittene. Denne scenen henter Linux -kjernebildet og gir utførelseskontrollen til bootloader.

Starting av Linux

Etter andre trinn har Boot Loader kopiert Linux -bildet til den eksterne DDR. Det vil gi utførelseskontrollen til Linux -bildet. Når Linux -bildet begynner å starte opp, starter det initialiseringen av alle enhetene/periferiutstyr på tavlen. Det initialiserer alt undersystemet inkludert alle kontrollere og enheter. Etter at alle driverne og enhetene er initialisert på dette stadiet og Linux -kjernen kjører med maksimal kapasitet mulig.

Når oppstart eller initialisering av driverne er ferdig, er det et søk i rootfs -enheten. Rootfs enhetsplassering kan også konfigureres eller endres fra kommandolinjeparametrene til Linux. Kommandolinjeparametere for Linux er miljøvariablene i U-Boot-miljøet, og dermed for å oppdatere RootFS-enhetens plassering er bare en modifisering av miljøvariabelen i U-Boot. Det er annen informasjon også tilgjengelig i U-Boot-miljøet.

Få eksempler er init -prosessplassering, minnestørrelse, muliggjør Devmem, øker kjernen LoGLevels osv. Få andre U-Boot Environment Variable Options er tilgjengelige for å lette andre brukersaker i U-Boot. For eksempel gjøres IP-adresseoppgaven i U-Boot ved hjelp av miljøvariabel.

Montering av rootfs og utførelse av Linux init -skript:

Rootfs -enheten blir søkt og montert, og deretter blir initprosessen søkt i rootfs -enheten. Etter at INIT -bildet er lokalisert, blir kontrollen videre til INIT etter å ha påkalt INIT -prosessen. Dette er den første brukerlandsprosessen som starter utførelse. Når INIT får kontrollen, initialiserer den brukerområdet tjenester ved å kjøre init -skriptene.

Alle demonene startes og System Level Services start. Etter at alle tjenestene er startet, påkalles Shell -programmet som oppretter en påloggingsøkt for brukeren.

Bruker kan bruke denne kommandokonsollen til å be om forskjellige tjenester fra Linux -kjernen.

La oss nå se oppstartsloggene til Linux -systemet som vil demonstrere oppstartstadiet vi har diskutert så langt. Merk at dette ikke er komplette logger. Jeg har fjernet få linjer i mellom da de er enorme tømmerstokker. Ikke relevant for emnet, og derfor har jeg nettopp gitt loggene som er relevante for diskusjonen vår.

Merk: Boot ROM -fase kan ikke observeres i logger, da UART ikke er tilgjengelig på dette stadiet.
Oppstart av den første trinns oppstartslasteren:
U-Boot SPL 2019.04 (17. august 2021 - 18:33:14 +0000)
Prøver å starte opp fra RAM
Oppstart av andre trinns oppstartslaster eller u-boot:
U-boot 2019.04 (17. august 2021 - 18:33:14 +0000)
SOC: AST2600-A1
RST: Power on
LPC-modus: SIO: Aktiver: Superio-2E
ETH: Mac0: RMII/NCSI, Mac1: RMII/NCSI, Mac2: RMII/NCSI, Mac3: RMII/NCSI
Modell: leverandør BMC
DRAM: Allerede initialisert, 1008 MIB (kapasitet: 1024 MIB, VGA: 16 MIB), ECC OFF
PCIE-0: Link ned
MMC: EMMC_SLOT0@100: 0
Lastingsmiljø fra SPI Flash ... SF: oppdaget N25Q256A med side størrelse 256 byte, slett størrelse 4 kib, totalt 32 mib
*** Advarsel - Dårlig CRC, ved hjelp av standardmiljø
I: Serial@1E784000
Ut: seriell@1e784000
Feil: Serial@1E784000
Modell: leverandør BMC
Eeprom eth2Addr: EA = AA: BB: CC: DD: DE: E0
BMC eth2Addr = AA: BB: CC: DD: DE: E3
Nett: FTGMAC100_PROBE - NCSI oppdaget
eth2: ftgmac@1e670000ftgmac100_probe - NCSI oppdaget
ADVARSEL: FTGMAC@1E690000 (ETH3) Bruke tilfeldig MAC -adresse - FA: 12: FB: CA: BC: FF
, eth3: ftgmac@1e690000
Treff hvilken som helst nøkkel for å stoppe Autoboot: 2 1 0
## Lastekjerner fra Fit Image på 20100000 ..
Ved hjelp av 'Conf-1' konfigurasjon
Prøver 'Kernel-1' kjerne-subimage
Beskrivelse: Linux -kjerne
Type: Kjernebilde
.
.
.
.
Komprimering: Ukomprimert
Data start: 0x2067e1c4
Datastørrelse: 54387 byte = 53.1 Kib
Arkitektur: Arm
Bekreftelse av hash integritet ... ok
Oppstart ved hjelp av FDT BLOB på 0x2067E1C4
Laster inn kjernebilde ... ok
Laster Ramdisk til 8fbe0000, slutt 8ffffbf0 ... ok
Last inn enheten tre til 8fbcf000, slutt 8fbdf472 ... ok
Starting av Linux:
Startkjerne ..
[0.000000] oppstart Linux på fysisk CPU 0xf00
[0.000000] Linux versjon 5.1.3.SDK-V00.05.07 (Cienauser@HAXV-Srathore-2) (GCC versjon 8.3.0 (Buildroot 2019.05-rc2)) #3 SMP Sun 29 august 14:19:01 UTC 2021
[0.000000] CPU: ARMV7 -prosessor [410FC075] Revisjon 5 (ARMV7), CR = 10C5387D
[0.000000] CPU: DIV -instruksjoner tilgjengelig: Patching Division Code
[0.000000] CPU: PIPT / VIPT Nonaliasing Data Cache, VIPT aliasing Instruksjonsbuffer
[0.000000] av: FDT: Maskinmodell: AST2600 A1 EVB
[0.000000] Minnepolicy: Data Cache Writealloc
[0.000000] Reservert minne: Opprettet CMA Memory Pool på 0xbb000000, størrelse 64 MIB
[0.000000] av: Reservert MEM: Initialisert nodevideo, kompatibel ID delt-DMA-pool
[0.000000] Reservert minne: Opprettet CMA Memory Pool på 0xb7000000, størrelse 64 MIB
[0.000000] av: reservert mem: initialisert node rvas, kompatibel ID delt-dma-pool
[0.000000] Reservert minne: Opprettet DMA Memory Pool på 0xb6e00000, størrelse 2 MIB
[0.000000] av: Reservert MEM: Initialisert node SSP_Memory, Compatible ID Shared-DMA-Pool
[0.000000] Reservert minne: Opprettet DMA Memory Pool på 0xb6d00000, størrelse 1 MIB
.
.
.
.
[ 1.184367] 0x000000000000-0x0000000F0000: "U-boot"
[ 1.191246] 0x0000000F0000-0x000000100000: "U-Boot-ENV"
[ 1.198363] 0x000000100000-0x000002060000: "Fit"
[ 1.203661] MTD: Partisjon "Fit" strekker seg utover slutten av enheten "BMC" - Størrelse avkortet til 0x1F00000
[ 1.215347] leverandør-SMC 1E620000.SPI: BUS_WIDTH 2, bruker 50 MHz SPI -frekvens
[ 1.223375] leverandør-SMC 1E620000.SPI: N25Q256A (32768 KBYTES)
[ 1.229723] leverandør-SMC 1E620000.SPI: CE1 -vindu [0x22000000 - 0x24000000] 32MB
[ 1.237996] leverandør-SMC 1E620000.SPI: CE2 -vindu [0x24000000 - 0x30000000] 192MB
[ 1.246357] leverandør-SMC 1E620000.SPI: Les kontrollregister: [203C0441]
[ 1.316884] Selger-SMC 1E630000.SPI: BUS_WIDTH 2, bruker 50 MHz SPI -frekvens
[ 1.324821] Selger-SMC 1E630000.SPI: ukjente Jedec ID -byte: 00 00 00 00 00 00
[ 1.333384] leverandør-SMC 1E630000.SPI: Chip 0 eksisterer ikke.
.
.
.
[ 1.631342] UHCI_HCD: USB Universal Host Controller Interface Driver
[ 1.638622] Platform-UHCI 1E6B0000.USB: oppdaget 2 porter fra enhet-treet
[ 1.646217] Platform-UHCI 1E6B0000.USB: Aktivert leverandørimplementering
[ 1.664722] Platform-UHCI 1E6B0000.USB: Generisk UHCI -vertskontroller
[ 1.671844] Platform-UHCI 1E6B0000.USB: Ny USB -buss registrert, tildelt buss nummer 2
[ 1.680671] Platform-UHCI 1E6B0000.USB: IRQ 42, IO MEM 0x1E6B0000
[ 1.687977] USB USB2: Ny USB -enhet funnet, IdVendor = 1D6B, IDProduct = 0001, BCDDevice = 5.01
[ 1.697237] USB USB2: Nye USB -enhetsstrenger: MFR = 3, Produkt = 2, SerialNumber = 1
[ 1.705311] USB USB2: Produkt: Generisk UHCI vertskontroller
[ 1.711542] USB USB2: Produsent: 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 -huben funnet
[ 1.728830] Hub 2-0: 1.0: 2 porter oppdaget
[ 1.734689] USBCORE: Registrert ny grensesnittdriver USB-lagring
[ 1.753347] VENDOR_VHUB 1E6A0000.USB-VHUB: Initialisert virtuell hub i USB2-modus
[ 1.762327] I2C /DEV -oppføringer Driver
[ 1.767491] I2C_NEW_VENDOR 1E78A080.I2C-Bus: New-I2C: I2C-Bus [0]: Adapter [100 kHz] Mode [2]
.
.
.
[2.960181] Å frigjøre ubrukt kjerneminne: 1024k
[2.970760] MMCBLK0: MMC0: 0001 R1J57L 27.5 Gib
[2.976119] MMCBLK0BOOT0: MMC0: 0001 R1J57L Partisjon 1 16.0 Mib
[2.983067] MMCBLK0BOOT1: MMC0: 0001 R1J57L Partisjon 2 16.0 Mib
[2.989980] MMCBLK0RPMB: MMC0: 0001 R1J57L PARTITION 3 128 KIB, CHARDEV (246: 0)
[2.999275] MMCBLK0: P1
[3.012035] Sjekket w+x kartlegginger: bestått, ingen w+x sider funnet
Montering av rootfs og utførelse av Linux init -skript
[3.018367] Kjør /SBIN /INIT AS INIT PROSESS

Konklusjon

Vi har sett den komplette Linux -oppstartsprosessen i detaljer med prøvelogger. Vi har også diskutert de forskjellige byggesteinene i Linux -oppstart. Få andre forutsetninger som trengs for Linux å starte opp ble også diskutert. Det er forskjellige stadier involvert i Linux -støvelen på et hvilket. Denne diskusjonen er nok til å gi den grunnleggende forståelsen av Linux -oppstart på ARM -systemer.