Zakładając, że nie możesz bezpośrednio uruchomić systemu linux, jak zrobić bootstrap?


0

Jakie są rzeczywiste kroki, zakładając, że masz zestaw plików nagłówkowych c, które opisywały zmapowane w pamięci urządzenia w twoim systemie, aby zrobić początkowe działające jądro? Wiem, że wszyscy startują z napędu CD / USB na żywo itp., Ale jak powstał ten pierwszy bootstrap?

EDIT: Powinienem podkreślić, że mówię o urządzeniach ARM naprawdę, mam podstawy ładowania poprzez BIOS na typowej maszynie, ale powiedzmy, że mówimy o niestandardowym urządzeniu?


BIOS jest tym, co sprawdza specyficzne urządzenie dla kodu rozruchowego, kod rozruchowy (boot loader) jest tym, co ładuje system operacyjny, który następnie zajmuje się resztą. BIOS „wie”, gdzie szukać ze względu na standardy branżowe. Niestandardowe urządzenie będzie zgodne ze standardami branżowymi lub będzie mieć niestandardowy BIOS, który definiuje własny proces rozruchu i gdzie szukać kodu rozruchowego. Czy pytasz, jak zrobić BIOS, program ładujący lub jądro?
txtechhelp

Właściwie to pracuję z FPGA serii Zynq 7000. Nie ma BIOSu i nw przeczytałem trochę więcej na ten temat, ma on podstawowy bootloader, który spodziewa się znaleźć flashowany program ładujący pierwszego stopnia, który ładuje ładowarkę drugiego stopnia do dram i wykonuje go. Trik polega na tym, że FSBL ma wystarczająco dużo informacji, aby uruchomić skompilowane jądro.
MrMowgli

Odpowiedzi:


1

jak powstało pierwsze ładowanie?

Budowanie (pisanie i kompilowanie) programu ładującego nie jest tak zniechęcające, jak sugerujesz.

Powinienem podkreślić, że naprawdę mówię o urządzeniach ARM, mam podstawy ładowania poprzez BIOS na typowej maszynie, ale powiedzmy, że mówimy o niestandardowym urządzeniu?

BIOS, do którego się odnosisz, jest w zasadzie konwencją PC. (CP / M miał także BIOS, ale niekoniecznie był w pamięci nieulotnej). Procesory ARM zazwyczaj nie mają ani nie używają BIOSu.

Typowy obecnie używany procesor ARM jest zintegrowany z urządzeniami peryferyjnymi w jednym układzie scalonym o nazwie a SoC , system na chipie. Pamięć główna, np. DRAM i pamięć nieulotna, np. Błysk NAND, typowo zewnętrzny względem SoC, zapewnia maksymalną elastyczność projektowania. Zazwyczaj jednak istnieje niewielka (być może 128 KB) wbudowana pamięć ROM (pamięć tylko do odczytu) do inicjowania minimalnych komponentów systemu w celu rozpoczęcia operacji ładowania początkowego. Resetowanie procesora zawsze spowoduje wykonanie tej boot ROM. (Ta pamięć ROM jest naprawdę tylko do odczytu i nie można jej modyfikować. Kod jest zamaskowany w krzemie podczas produkcji chipa).

Każdy dostawca SoC ma własną metodę bootstrap, aby załadować system operacyjny i wykonać go. Niektórzy używają opasek sprzętowych odczytywanych przez piny GPIO, aby określić źródło następnego etapu sekwencji ładowania początkowego. Inny dostawca może użyć uporządkowanej listy pamięci i urządzeń do sondowania programu ładowania początkowego. Inną techniką jest rozgałęzienie do oprogramowania układowego w pamięci flash NOR, które można bezpośrednio wykonać (tj. XIP, wykonać na miejscu).

Jednym z problemów związanych z ładowaniem systemu wykorzystującego pamięć DRAM do pamięci głównej jest inicjalizacja sprzętu. Kontroler pamięci DRAM musi zostać zainicjowany przed załadowaniem kodu do pamięci DRAM i wykonaniem. Więc gdzie znajduje się ten kod inicjujący, ponieważ nie może znajdować się w głównej pamięci?
Każdy sprzedawca ma własne rozwiązanie. Niektóre wymagają przechowywania danych konfiguracyjnych pamięci w pamięci nieulotnej, aby uzyskać dostęp do boot ROM. Niektóre SoC mają zintegrowaną pamięć SRAM (która nie wymaga inicjalizacji takiej jak DRAM), aby wykonać mały program ładujący. Niektóre SoC używają pamięci NOR do przechowywania programu ładującego XIP.

Gdy program ładujący zainicjuje pamięć DRAM, pamięć główna może zostać użyta do załadowania następnego etapu uruchamiania. Może to być zaawansowane narzędzie rozruchowe, takie jak U-Boot, lub (jeśli program ładujący jest w stanie) jądro Linuksa. Należy zauważyć, że może być kilka programów ładujących lub etapów, które zostały wykonane między resetowaniem procesora a wykonaniem systemu operacyjnego.

Wymagania dotyczące uruchomienia jądra Linux ARM są opisane w następującym dokumencie: http://www.simtec.co.uk/products/SWLINUX/files/booting_article.html
Starsze wersje Linux ARM używały listy ATAG do przekazywania podstawowych informacji konfiguracyjnych do jądra. Nowoczesne wersje zapewniają kompletną konfigurację płyty przy użyciu skompilowanego pliku binarnego drzewa urządzeń.

Oczywiście pytanie „jak zrobić bootstrap?” nie można odpowiedzieć bez pewnych kwalifikacji.

Podobnie jak BIOS komputera, ROM rozruchowy SoC jest zastrzeżony i nie jest wydany (chyba że podpiszesz NDA, jeśli w ogóle). Jednak większość kodu startowego jest wydana na licencji GPL lub podobnej i łatwo dostępna.


UZUPEŁNIENIE

Ponieważ wspominasz, że używasz Zynq 7000 (który używa Xilinx SoC), Xilinx ma samouczek wideo na temat Jak zbudować obraz rozruchowy systemu Linux .
Ten film potwierdza to, co już napisałem:
1. Xilinx SoC ma wbudowaną boot ROM (która jest technicznie pierwszym etapem, ale częściej jest ignorowana lub opisywana jako etap zero).
2. Istnieją „szpilki trybu”, które określają źródło programu ładowania początkowego dla następnego etapu.
3. Boot ROM ładuje program ładujący (który jest technicznie drugim etapem, ale często określany jako „pierwszy” etap), zwany FSBL, do wbudowanej pamięci SRAM. Ten program inicjuje DRAM i ładuje następny etap, U-Boot.
4. U-Boot wykonuje się z pamięci DRAM i ładuje jądro Linuksa.

Film pokazuje, że kod źródłowy FSBL można pobrać z witryny Xilinx i skompilować w kilku krokach. Nie ma "sztuczka" jak twierdzisz. Kompilacja jest prostą konfiguracją i kompilacją krzyżową, którą uważam za prostszą / łatwiejszą niż typowy pakiet aplikacji.

Być może twoje zamieszanie opiera się na niejednoznaczności nośnika rozruchowego, tj. Źródło (a) obrazów rozruchowych nie zostało (zostało) określone. Wideo wspomina o pamięci flash NAND i karcie SD jako możliwych urządzeniach rozruchowych.
ROM rozruchowy jest kierowany do odczytu obrazu FSBL z nośnika źródłowego skonfigurowanego za pomocą styków trybu.

FSBL (jeśli jest podobny do innych używanych bootstrapów) jest zbudowany do odczytu U-Boot ze skonfigurowanego nośnika źródłowego. Nie ma alternatywy dla środowiska wykonawczego.

U-Boot próbuje spełnić swoją nazwę („uniwersalny”) i może zostać skonfigurowany (za pomocą zmiennych środowiskowych) do ładowania obrazów (i skryptów) z różnych urządzeń. Istnieje również opcja interaktywna.

Zobacz także wiki Xilinx na Zynq Linux , który deklaruje, że „pełne informacje na temat uruchamiania Zynq można znaleźć w Podręcznik techniczny


Ok, link był bardzo pouczający, dzięki! Zdecydowanie wyjaśnił, jak ten obraz jest mapowany na adres pamięci nieskompresowany i uruchomiony. Sztuczka polega na kompilowaniu obrazu rozruchowego z odpowiednią lokalizacją pamięci, ładowaniu wystarczającej ilości wsparcia sprzętowego, aby uzyskać pełny obraz.
MrMowgli

Zamieszanie naprawdę ma związek z faktem, że FPGA w tym przypadku może definiować własne urządzenia sprzętowe, i istnieje plik mapy pamięci specyficzny dla logiki programowalnej. Pierwotne pytanie dotyczy idei polegającej na tym, że w oparciu o ogólną płytę innej firmy, z różnymi komponentami i urządzeniami pamięci, jak kompilacja krzyżowa ma miejsce w pierwszej kolejności. Myślę, że twój link dobrze to wyjaśnia. Jednak dla płyt Zynq potrzebne są również pliki DTB i pliki bitowe dla warstwy programowalnej.
MrMowgli
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.