Linux Boot na platformie ARM

Omówimy na platformach ramienia. Jakie są elementy składowe takich platform. Kiedy zasilamy na płycie, a Linux jest instalowany w systemie, jak wyzwalano zasilanie płyty w sekwencjonowaniu. Jakie są inne komponenty potrzebne do uruchomienia Linuksa na dowolnej platformie ARM?

Opis

Platforma ARM to płyta oparta na architekturze ARM. Na rynku istnieje wielu producentów, którzy projektują platformy na podstawie tej architektury. Zasadniczo platforma ramienia ma następujące elementy składowe:

1. CPU/SOC: To jest główna jednostka przetwarzania na platformie. Komponenty mają wewnętrzne elementy, takie jak pamięć podręczna, SCU itp.
2. Wewnętrzne S-RAM: To jest pamięć RAM, która jest obecna w SOC. Rozmiar tej pamięci jest ograniczony i będzie kilka KBS.
3. Zewnętrzny DDR: To jest zewnętrzny pamięć RAM, która ma znaczącą wielkość w porównaniu z wewnętrznym pamięcią RAM. Ta pamięć działa jak pamięć wykonania dla procesora. Ogólnie rzecz biorąc, jest to kilka GBS, w oparciu o projekt systemu.
4. Urządzenie rozruchowe: Jest to zewnętrzne stałe urządzenie pamięci używane do przechowywania obrazów oprogramowania potrzebnych przez system do uruchomienia. Kilka przykładów komponentów to Bootloaders, Linux Image, Root FileSystem. Te 3 komponenty są podstawowymi komponentami potrzebnymi przez każdy system do uruchomienia Linuksa. Przykładem urządzeń rozruchowych są EMMC, NV Flash Memory Devices, SD Card, USB Memory Stick itp. Te urządzenia można użyć do uruchamiania tylko wtedy, gdy system obsługuje uruchamianie z tym multimedią. Niewiele systemów ma wiele opcji rozruchu, które można kontrolować za pomocą pasków lub przełączników DIP. Każdy wymagany typ rozruchu można wybrać, a obrazy można zaprogramować do nośnika rozruchowego. Programowanie obrazów rozruchowych można wykonać za pomocą jakiegoś zewnętrznego programisty, takich jak narzędzie Dediprog.

Obrazy dla systemu do uruchomienia

Pierwszym i najważniejszym elementem potrzebnym do rozruchu Linux na platformie ARM jest potrzebne obrazy kompilacji ładowników rozruchowych, jądra Linux i systemów plików root. Obrazy te można skompilować, jeśli płyta jest zaprojektowana wewnętrzna dla organizacji, ale jeśli urządzenie jest zakupione za pośrednictwem jakiegoś dostawcy, powinien podać instrukcje dotyczące generowania obrazu. Nawet w niektórych przypadkach, jeśli nie podają kodu źródłowego do kompilacji lub budowy, wówczas dostarczają wstępnie zbudowane obrazy.

Programowanie obrazów na urządzenie rozruchowe

Po przygotowaniu obrazów do rozruchu na platformie musimy spalić/zaprogramować obrazy na urządzeniu rozruchowym. Do zaprogramowania obrazów na urządzenie rozruchowe powinny być dostępne instrukcje dotyczące dostawcy lub dowolnego programatora HW. Przykładem takiego programisty jest Dediprog.

Dediprog to narzędzie, którego można użyć do zaprogramowania obrazu Flash na NV Flash. Tak jest w przypadku trybu uruchamiania flash. Skoczki lub konfiguracja są potrzebne, aby włączyć rozruch flash, jeśli obecnych jest wiele urządzeń rozruchowych.

Migawka Dediprog:

W końcu obrazy są zaprogramowane w nośniku rozruchowym, a cała konfiguracja rozruchu jest wykonywana, aby włączyć typ rozruchu, w którym przechowyliśmy obrazy do uruchamiania.

Uruchamianie Linuksa można rozważyć na wielu etapach:

1. Faza ROM ROM
2. Booting pierwszej scenicznej ładowarki
3. Uruchamianie modułu ładującego drugiego etapu, jest to ogólnie U-Boot.
4. Uruchamianie Linuksa
5. Montaż korzeni i wykonywanie scenariuszy Linux Init, dopóki nie nadejdzie konsola logowania.

Omówmy teraz wszystkie te etapy uruchamiania.

Faza ROM ROM

Na tym etapie nie ma dostępu do zewnętrznego DDR, wszystkie wykonanie należy wykonać w wewnętrznym S-RAM. Gdy tylko system jest włączony, kod rozruchu inicjuje interfejs rozruchu, a następnie pobiera ładowarkę rozruchową pierwszego etapu. Gdy ładowarka rozruchowa będzie dostępna w wewnętrznej pamięci RAM i jest gotowa do wykonania, wówczas kontrola jest przenoszona do ładowacza rozruchowego pierwszego stopnia.

Booting pierwszej scenicznej ładowarki

Zaraz po włączeniu płyty nie ma dostępu do zewnętrznego pamięci RAM dostępnej dla procesora. Wykonanie rozpoczyna się od wektora resetowania. Reset wektor to lokalizacja, z której procesor zaczyna wykonywać pierwsze instrukcje programowania. Na tym etapie dostępny jest tylko wewnętrzny pamięć RAM. Później zewnętrzny DDR jest inicjalizowany, a następnie pobierany z drugiego etapu z nośnika rozruchowego i ładowany do zainicjowanego zewnętrznego DDR, a kontroler jest przekazywany do ładowarki z drugim etapem i moduł ładowania rozruchowego I.mi., U-boot.

Booting drugiego etapu ładowarki lub u-boot

Jest to minimalne oprogramowanie potrzebne do konfiguracji środowiska potrzebnego przez jądro Linux przed uruchomieniem. Różne sterowniki i interfejsy HW są włączone w środowisku U-Boot. Ten bootloader zapewnia wiersz poleceń, a zatem możemy zmodyfikować kilka konfiguracji w czasie wykonywania. Głównym celem tego etapu jest przygotowanie konfiguracji/płyty dla jądra Linux. Na tym etapie obraz Linux można pobrać z wielu dostępnych opcji. Obraz Linux można załadować przez dowolny interfejs z różnych interfejsów. Ten etap pobiera obraz jądra Linux i przekazuje kontrolę wykonania do bootloadera.

Uruchamianie Linuksa

Po drugim etapie ładowarka rozruchowa skopiowała obraz Linuksa do zewnętrznego DDR. Przekaże kontrolę wykonania na obraz Linux. Gdy obraz Linux zacznie się uruchamiać, rozpocznie inicjowanie wszystkich urządzeń/peryferyjów na płycie. Inicjuje wszystkie podrzędne systemy, w tym wszystkie kontrolery i urządzenia. Po tym, jak wszystkie sterowniki i urządzenia zostaną zainicjowane na tym etapie, a jądro Linux działa z maksymalną możliwą pojemnością.

Po zakończeniu uruchamiania lub inicjalizacji sterowników jest wyszukiwanie urządzenia rootfs. Lokalizacja urządzenia rootfs można również skonfigurować lub modyfikować z parametrów wiersza poleceń Linux. Parametry wiersza poleceń dla Linux to zmienne środowiskowe w środowisku U-Boot, dlatego w celu aktualizacji lokalizacji urządzenia Rootsfs to tylko modyfikacja zmiennej środowiska w U-Boot. W środowisku U-Boot dostępne są inne informacje.

Kilka przykładów to lokalizacja procesu init, rozmiar pamięci, umożliwiający DevMem, zwiększając logowanie jądra itp. Dostępnych jest kilka innych opcji zmiennej środowiska U-BOOT, aby ułatwić inne przypadki użytkowników w U-Boot. Na przykład przypisanie adresu IP w U-Boot odbywa się za pomocą zmiennej środowiskowej.

Montaż korzeni i wykonywanie scenariuszy Linux Init:

Urządzenie rootfs jest wyszukiwane i montowane, a następnie proces inicjowania jest wyszukiwany w urządzeniu rootfs. Po zlokalizowaniu obrazu inicjowego kontrola jest przekazywana do init po wywołaniu procesu inicjowego. To pierwszy proces użytkownika, który rozpoczyna wykonywanie. Gdy init otrzyma kontrolę, inicjuje usługi przestrzeni użytkowników, uruchamiając skrypty init inicja.

Wszystkie demony są uruchamiane, a usługi na poziomie systemowym są uruchamiane albo wykonywanie usług inicjowych obecnych w / etc / lub jeśli systemem jest system oparty na systemCTL, to wszystkie usługi są uruchamiane zgodnie z wytycznymi wymienionymi dla systemu SystemCtl. Po uruchomieniu wszystkich usług jest wywoływany program Shell, który tworzy monit sesji logowania dla użytkownika.

Użytkownik może użyć tej konsoli poleceń, aby żądać różnych usług z jądra Linux.

Teraz zobaczmy dzienniki rozruchu systemu Linux, które zademonstrują etap rozruchu, który do tej pory omówiliśmy. Uwaga Nie są to kompletne dzienniki. Usunąłem kilka linii pomiędzy nimi, ponieważ są to ogromne dzienniki. Niezbyt istotne dla tego tematu, dlatego właśnie dostarczyłem dzienniki istotne dla naszej dyskusji.

Uwaga: Faza ROM rozruchu nie można zaobserwować w dziennikach, ponieważ UART nie jest dostępny na tym etapie.
Booting pierwszej scenicznej ładowarki:
U-Boot SPL 2019.04 (17 sierpnia 2021 - 18:33:14 +0000)
Próbuję uruchomić RAM
Booting drugiego etapu ładowarki lub u-boot:
U-Boot 2019.04 (17 sierpnia 2021 - 18:33:14 +0000)
SOC: AST2600-A1
RST: Power on
Tryb LPC: SIO: Włącz: Superio-2E
ETH: MAC0: RMII/NCSI, MAC1: RMII/NCSI, MAC2: RMII/NCSI, MAC3: RMII/NCSI
Model: BMC dostawcy
DRAM: już zainicjowany, 1008 MIB (pojemność: 1024 MIB, VGA: 16 MIB), ECC Off
PCIE-0: Link Down
MMC: EMMC_SLOT0@100: 0
Środowisko ładowania z SPI Flash… SF: Wykryty N25Q256A z rozmiarem strony 256 bajtów, rozmiar usuwania 4 kib, całkowita 32 MIB
*** OSTRZEŻENIE - Zły CRC, przy użyciu domyślnego środowiska
W: Serial@1E784000
OUT: Serial@1E784000
Err: serial@1E784000
Model: BMC dostawcy
EEPROM ETH2ADDR: EA = AA: BB: CC: DD: DE: E0
BMC ETH2ADDR = AA: BB: CC: DD: DE: E3
Netto: ftgmac100_probe - wykryty NCSI
ETH2: FTGMAC@1E670000ftGMAC100_PROBE - Wykryto NCSI
OSTRZEŻENIE: FTGMAC@1E690000 (ETH3) Za pomocą losowego adresu MAC - FA: 12: FB: CA: BC: FF
, ETH3: ftgmac@1E690000
Naciśnij dowolny klawisz, aby zatrzymać autoboot: 2 1 0
## Ładowanie jądra z obrazu dopasowania na 20100000…
Korzystanie z konfiguracji „Conf-1”
Próbuję podsumowania jądra „jądro-1”
Opis: jądro Linux
Typ: obraz jądra
.
.
.
.
Kompresja: nieskompresowany
Uruchomienie danych: 0x2067e1c4
Rozmiar danych: 54387 bajtów = 53.1 kib
Architektura: ramię
Weryfikacja integralności skrótu… OK
Uruchamianie za pomocą Blob FDT przy 0x2067e1c4
Ładowanie obrazu jądra… OK
Ładowanie Ramdisk do 8fbe0000, koniec 8ffffbf0… OK
Ładowanie drzewa urządzenia do 8FBCF000, END 8FBDF472… OK
Uruchamianie Linux:
Rozpoczęcie jądra…
[0.000000] uruchamianie Linuksa na fizycznym procesorze 0xf00
[0.000000] Linux wersja 5.1.3.SDK-V00.05.07 (cinauser@haxv-sathore-2) (wersja 8 GCC.3.0 (Buildroot 2019.05-RC2)) #3 SMP Sun 29 sierpnia 14:19:01 UTC 2021
[0.000000] CPU: Procesor Armv7 [410FC075] Rewizja 5 (ARMV7), CR = 10C5387D
[0.000000] CPU: Dostępne instrukcje DIV: Patrzenie Kod podziału
[0.000000] CPU: PIPT / VIPT Nonaliasing Data Cache, Vipt Aliasing Insiving Cache
[0.000000] OF: FDT: Model maszyny: AST2600 A1 EVB
[0.000000] Polityka pamięci: pamięć podręczna danych WritealLoc
[0.000000] Pamięć zarezerwowana: utworzono pulę pamięci CMA przy 0xBB000000, rozmiar 64 MIB
[0.000000] OF: Zarezerwowany MEM: zainicjowane wideo węzła, kompatybilny identyfikator udostępniony-DMA-POOL
[0.000000] Pamięć zarezerwowana: utworzono pulę pamięci CMA przy 0xb7000000, rozmiar 64 MIB
[0.000000]: Zastrzeżone MEM: zainicjowane RVA węzła, kompatybilny identyfikator udostępniony-DMA-POOL
[0.000000] Pamięć zarezerwowana: utworzono pulę pamięci DMA przy 0xb6e00000, rozmiar 2 MIB
[0.000000] OF: Reserved MEM: zainicjowany węzeł SSP_Memory, kompatybilny identyfikator Shared-DMA-POOL
[0.000000] Pamięć zarezerwowana: utworzono pulę pamięci DMA przy 0xb6d00000, rozmiar 1 MIB
.
.
.
.
[1.184367] 0x000000000000-0x0000000f0000: „U-boot”
[1.191246] 0x0000000f0000-0x000000100000: „U-boot-env”
[1.198363] 0x000000100000-0x000002060000: „Fit”
[1.203661] MTD: PARTITION „FIT” rozciąga się poza koniec urządzenia „BMC” - rozmiar obcięty na 0x1f00000
[1.215347] Sprzedawca-SMC 1E620000.SPI: bus_width 2, przy użyciu częstotliwości SPI 50 MHz
[1.223375] Sprzedawca-SMC 1E620000.SPI: N25Q256A (32768 KBYTES)
[1.229723] Sprzedawca-SMC 1E620000.SPI: okno CE1 [0x22000000 - 0x24000000] 32 MB
[1.237996] Sprzedawca-SMC 1E620000.SPI: okno CE2 [0x24000000 - 0x30000000] 192 MB
[1.246357] Sprzedawca-SMC 1E620000.SPI: Przeczytaj rejestr kontroli: [203C0441]
[1.316884] Sprzedawca-SMC 1E630000.SPI: bus_width 2, przy użyciu częstotliwości SPI 50 MHz
[1.324821] Sprzedawca-SMC 1E630000.SPI: nierozpoznane bajty ID Jedek: 00 00 00 00 00 00
[1.333384] Sprzedawca-SMC 1E630000.SPI: Chip 0 nie istnieje.
.
.
.
[1.631342] UHCI_HCD: USB Universal Host Controller Driver
[1.638622] Platform-UHCI 1E6B0000.USB: wykryte 2 porty z drzewa urządzenia
[1.646217] Platform-UHCI 1E6B0000.USB: Włączane obejścia dostawcy
[1.664722] Platform-UHCI 1E6B0000.USB: ogólny kontroler hosta UHCI
[1.671844] Platform-UHCI 1E6B0000.USB: Nowa autobus USB zarejestrowany, przypisany autobus nr 2
[1.680671] Platform-UHCI 1E6B0000.USB: IRQ 42, IO MEM 0x1E6B0000
[1.687977] USB USB2: Znaleziono nowe urządzenie USB, idvendor = 1d6b, idproduct = 0001, bcddevice = 5.01
[1.697237] USB USB2: Nowe ciągi urządzenia USB: MFR = 3, produkt = 2, SerialNumber = 1
[1.705311] USB USB2: Produkt: ogólny kontroler hosta UHCI
[1.711542] USB USB2: Producent: Linux 5.1.3.SDK-V00.05.07 Uhci_hcd
[1.718824] USB USB2: SerialNumber: 1E6B0000.USB
[1.724589] Hub 2-0: 1.0: Znaleziono hub USB
[1.728830] Hub 2-0: 1.0: 2 wykryte porty
[1.734689] USBCORE: Zarejestrowany nowy sterownik interfejsu Storage USB
[1.753347] Vendor_vhub 1E6A0000.USB-VHUB: Zainicjowane wirtualne piasty w trybie USB2
[1.762327] I2C /Dev Wpisy sterownik
[1.767491] i2c_new_vendor 1E78A080.I2C-BUS: NEW-I2C: I2C-BUS [0]: Adapter [100 kHz] Tryb [2]
.
.
.
[2.960181] Uwolnienie nieużywanej pamięci jądra: 1024k
[2.970760] MMCBLK0: MMC0: 0001 R1J57L 27.5 gib
[2.976119] MMCBLK0BOOT0: MMC0: 0001 R1J57L PARTICY 1 16.0 MIB
[2.983067] MMCBLK0BOOT1: MMC0: 0001 R1J57L PARTICY 2 16.0 MIB
[2.989980] MMCBLK0RPMB: MMC0: 0001 R1J57L PARTICY 3 128 KIB, Chardev (246: 0)
[2.999275] MMCBLK0: P1
[3.012035] Sprawdzone W+X Wstąpki: Przekazano, nie znaleziono stron W+X
Montaż korzeni i wykonywanie scenariuszy Linux Init
[3.018367] RUN /SBIN /INIT jako proces init init

Wniosek

Widzieliśmy pełny proces rozruchu Linux w szczegółach z przykładowymi dziennikami. Omówiliśmy również różne elementy budulcowe uruchamiania Linux. Omówiono również kilka innych wymagań wstępnych do rozruchu Linux. Istnieją różne etapy biorące udział w rozruchu Linux na dowolnej płycie procesora ARM, wszystkie etapy zostały szczegółowo omówione i są mapowane z przykładowymi dziennikami rozruchu. Ta dyskusja wystarczy, aby zapewnić podstawowe zrozumienie uruchamiania Linux w systemach ARM.