Wstęp

Po co jest bootloader? Bootloader służy do wstępnej inicjalizacji niezbędnych peryferiów i do załadowania systemu operacyjnego. To w zasadzie tyle co trzeba wiedzieć aby przejść dalej, ale rozwinę nieco temat aby wprowadzić pewne teoretyczne podstawy. Więc co się dzieje krok po kroku?

Po uruchomieniu płytki pierwszym programem, który się uruchamia jest tzw. boot ROM a.k.a. IPL(initial program loader). Kod IPLa jest wgrywany na płytkę podczas produkcji, nie może on zostać podmieniony i jest on charakterystyczny dla każdego urządzenia. IPL może załadować inny program do pamięci RAM z pamięci nieulotnej jak np. pamięć flash więc musi on również umieć zainicjalizować jakiś interfejs komunikacyjny jak np. SPI. IPL ładuje do RAMu tzw. SPL czyli secondary program loader.

SPL może mieć dwa zastosowania- albo załadowanie rozbudowanego bootloadera(tzw. tretiary program loader, TPL) jak np. U-Boot, który umożliwia bardzo rozbudowaną konfiguracje uruchamiania systemu albo może załadować kernel systemu operacyjnego. Z pierwszym przypadkiem mamy do czynienia w przypadku BBB, natomiast w przypadku RPi4 SPL może załadować bezpośrednio kernel. SPL w przeciwieństwie do IPL może zostać podmieniony. Oczywiście SPL musi zainicjalizować niezbędne peryferia aby załadować TPL lub kernel.

No i ostatni krok czyli TPL. Na tym etapie mamy już dostępny prosty interfejs użytkownika. Tutaj mamy możliwość wczytania interesującego nas systemu operacyjnego czy przekazania odpowiednich parametrów systemowi operacyjnemu.

I to tyle tytułem wstępu, zainteresowani tematyką bootloaderów mogą rzucić okiem na rozdział poświęcony bootloaderom książki „Linux inside”.

A teraz przechodzimy do tego co tygryski lubią najbardziej czyli do zabawy z płytkami. W tej lekcji użytkownicy BBB będą mieli najwięcej pracy do wykonania, użytkownicy RPi4 będą musieli zrobić niewiele, a użytkownicy QEMU nic nie będą musieli zrobić, ale mimo to zachęcam ich do rzucenia okiem na tę lekcje.

U-Boot i BeagleBone Black

U-Boot, a właściwie Das U-Boot jest jednym z popularniejszych, jeśli nie najpopularniejszym bootloaderem na systemy wbudowane. Kod U-Boota jest otwarty i jest on dostępny na githubie. Udostępnia on interfejs w postaci prostej konsoli. Został on stworzony przez firmę Denx, zainteresowanych odsyłam na stronę projektu po więcej informacji.

A teraz do rzeczy, jak zbudować i uruchomić tego całego U-Boota? Przede wszystkim musimy pobrać jego kod źródłowy:

git clone --depth 1 https://github.com/u-boot/u-boot.git

Parametr –depth 1 informuje gita, że ma pobrać jedynie najświeższą wersje plików z repozytorium, nie pobiera on wtedy historii zmian. W tym przypadku zastosowaliśmy tę opcje aby przyspieszyć proces pobierania kodu.

Gdy już mamy kod źródłowy to możemy go przebudować. Katalog configs/ zawiera konfiguracje dla dostępnych architektur sprzętowych. Nas interesuje konfiguracja am335x_evm_defconfig. Aby ustawić tę konfigurację sprzętową wykonujemy następującą komendę:

make am335x_evm_defconfig

Po wykonaniu tej komendy program make będzie wiedział co ma zbudować.

Zanim przejdziesz do budowania przypominam, że ścieżka do kompilatorów arm-linux-gnueabihf musi się znajdować w zmiennej PATH. Jeśli nie wiesz o co chodzi to zapraszam do lekcji pierwszej- przygotowanie środowiska pracy.

Aby zbudować U-Boota wykonujemy komendę:

make CROSS_COMPILE=arm-linux-gnueabihf- -j4

Zmienna CROSS_COMPILE informuje, która rodzina kompilatorów ma zostać użyta, zwróć uwagę na myślnik na końcu, jest on bardzo ważny, bez niego kompilacja nie przejdzie. Wynika to z tego, że program make po prostu skleja zawartość zmiennej CROSS_COMPILE z nazwą kompilatora jak np. gcc, g++ albo linkera np. ld.

Parametr -j informuje program make ile wątków może jednocześnie uruchomić i dzięki temu przyspieszyć proces kompilacji. Są różne podejścia do tego ile ta liczba powinna wynosić, ja osobiście ustawiam tyle wątków ile mam fizycznych rdzeni w procesorze. Kompilacja U-Boota trwa bardzo krótko.

Po zbudowaniu zobaczysz kilka nowych plików, nas interesują pliki MLO i u-boot.img. MLO jest naszym SPL, a U-Boot to TPL. Oba pliki musimy umieścić na karcie uSD używanej przez BBB. Pliki te muszą się znaleźć na pierwszej FATowskiej partycji karty. My tej partycji nadaliśmy etykietę uboot. Skopiuj więc te pliki na kartę:

cp MLO /media/user/uboot/
cp u-boot.img /media/user/uboot/

Pamiętaj aby MLO było zawsze zapisane jako pierwszy plik na tę partycję po sformatowaniu karty, inaczej mogą wystąpić problemy z działaniem. Gdy już zapiszesz wymagane pliki na karcie to odmontuj ją i przełóż ją do BBB:

sudo umount /media/user/*

Zanim uruchomimy nasz bootloader musimy mieć możliwość komunikacji z nim. Do tego celu użyjemy interfejsu UART. BBB posiada specjalnie wyprowadzone piny i dedykowany konwerter UART-USB, ale jeśli posiadasz zwykłą przejściówkę UART-USB to podłącz ją do następujących pinów:

Pamiętaj aby podłączyć pin TX konwertera do pinu RX płytki oraz pin RX konwertera do pinu TX płytki, w skrócie wykonaj połączenie krzyżowe.

Potrzebujemy jeszcze programu do komunikacji z BBB, możesz w tym celu użyć programu screen. Po podłączeniu konwertera do płytki i komputera(nie uruchamiaj jeszcze BBB) możesz wykonać komendę:

sudo screen /dev/ttyUSB0 115200

Tak, musisz uruchamiać ten program jako użytkownik root. Podłącz teraz BBB do prądu, w konsoli powinieneś zobaczyć logi podobne do poniższych:

U-Boot SPL 2021.10-rc3 (Sep 03 2021 - 20:40:26 +0200)
Trying to boot from MMC1


U-Boot 2021.10-rc3 (Sep 03 2021 - 20:40:26 +0200)

CPU  : AM335X-GP rev 2.1
Model: TI AM335x BeagleBone Black
DRAM:  512 MiB
WDT:   Started with servicing (60s timeout)
NAND:  0 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... <ethaddr> not set. Validating first E-fuse MAC
Net:   eth2: ethernet@4a100000
Hit any key to stop autoboot:  2

Naciśnij jakikolwiek klawisz aby przerwać proces automatycznego startowania systemu, który się nie powiedzie w tym przypadku przede wszystkim z powodu braku systemu operacyjnego do użycia.

Po przerwaniu procesu automatycznego bootowania powinieneś ujrzeć znak zachęty powszechnie zwany promptem, który wygląda następująco:

=>

Aby zobaczyć jakie są dostępne komendy wpisz help, jak widzisz trochę ich, daje to duże pole do konfiguracji uruchamiania systemu. Nas w kolejnych lekcjach będą interesowały komendy:

1. bootz- startuje system operacyjny wykorzystując obraz zImage
2. ext4ls- sprawdza zawartość partycji z systemem plików ext4
3. ext4load- ładuje plik z partycji z systemem plików ext4 do pamięci RAM
4. printenv- wyświetla zmienną lub zmienne środowiskowe
5. setenv- ustawia zmienną środowiskową
6. saveenv- zapisuje wartości zmiennych środowiskowych na karcie uSD
7. help- wyświetla opis dla wszystkich komend lub pomoc dla przekazanej komendy

Kolejnym ważnym elementem U-Boota są zmienne środowiskowe. Jeśli chcesz wyświetlić wszystkie zmienne środowiskowe wpisz komendę printenv. Znowu wyświetliło się sporo tekstu, ale nas interesować będą następujące zmienne:

1. bootcmd- zmienna przechowująca sekwencje komend potrzebną do automatycznego uruchomienia systemu
2. bootargs- zmienna przechowująca parametry przekazywane do systemu operacyjnego podczas jego uruchamiania
3. fdt_addr_r- zmienna przechowująca adres pod który należy wczytać device-tree
4. kernel_addr_r- zmienna przechowująca adres pod który należy wczytać kernel
5. ramdisk_addr_r- zmienna przechowująca adres pod który należy wczytać ramdisk(initramfs)

I to tyle co nas interesuje ze zmiennych. Jako zadanie bojowe możesz poeksperymentować ze zmiennymi środowiskowymi za pomocą komend printenv, setenv oraz saveenv. Pamiętaj, że jeśli namieszasz coś ze zmiennymi środowiskowymi to możesz przywrócić ich domyślną wartość poprzez usunięcie pliku uboot.env, który powstaje po wykonaniu polecenia saveenv na tej samej partycji na której znajduje się obraz U-Boota.

I to tyle z najważniejszych funkcjonalności U-Boota, będziemy korzystać z tej wiedzy w kolejnej lekcji podczas uruchamianiu kernela.

Raspberry Pi 4

W przypadku RPi4 nie będziemy używać U-Boota pomimo że istnieje plik konfiguracyjny dla niej w źródłach U-Boota. Wynika to z tego, że jest problem z konfiguracją UARTa i nie można się dostać do konsoli U-Boota(a przynajmniej ja nie ogarnąłem jak to zrobić póki co).

W przypadku RPi4 użyjemy tylko SPL, który to będzie ładował bezpośrednio system. Firmware RPi4 jest dostępny na githubie, pobierzmy zatem odpowiednie repozytorium:

git clone --depth 1 https://github.com/raspberrypi/firmware.git

Jeśli nie czytałeś sekcji o BBB to tam w trzecim akapicie jest wytłumaczone co oznacza opcja –depth.

Stety bądź niestety kod firmware’u RPi4 jest zamknięty i nie mamy do niego dostępu, repozytorium to przechowuje pliki binarne. W katalogu boot/ wewnątrz repozytorium znajduje się kilkanaście plików, nas interesują pliki start4.elf oraz fixup4.dat. Skopiuj oba te pliki na FATowską partycje karty uSD używanej przez RPi4(dla przypomnienia w poprzedniej lekcji nadaliśmy tej partycji etykietę boot):

cp boot/{start4.elf,fixup4.dat} /media/user/boot

Moglibyśmy już uruchomić naszą płytkę jednak byśmy nie mogli nic zobaczyć na konsoli, jedynie byśmy widzieli świecącą się diodę na płycie i migający kursor w konsoli. Aby móc odebrać dane z bootloadera musimy utworzyć plik z konfiguracją o nazwie config.txt o następującej zawartości:

arm_64bit=1
enable_uart=1
uart_2ndstage=1

Plik ten informuje RPi4, że ma ona pracować w trybie 64-bitowym, ma włączyć UART i przekierować logowanie SPL na UART. Oczywiście umieść ten plik na pierwszej partycji karty pamięci:

cp config.txt /media/user/boot

Gdy już wgrałeś wymagane pliki na kartę uSD to odmontuj ją i przełóż ją do RPi4:

sudo umount /media/user/*

Teraz podłączymy konwerter UART-USB do RPi4. Podłącz konwerter do pinów wskazanych przez czerwoną ramkę:

Tak samo jak w przypadku BBB pamiętaj aby pin TX RPi4 podłączyć do pinu RX konwertera, a pin RX płytki do pinu TX konwertera. Po podłączeniu konwertera do RPi4 podłącz go do komputera, ale nie uruchamiaj jeszcze płytki. Następnie wydaj komendę:

sudo screen /dev/ttyUSB0 115200

Teraz uruchom RPi4. W konsoli powinieneś ujrzeć sporo logów z błędami odnośnie HDMI, a na samym dole powinny być widoczne błędy o braku możliwości znalezienia pliku z device-tree, cmdline.txt oraz kernela:

recover4.elf not found (6)
recovery.elf not found (6)
Read start4.elf bytes  2240352 hnd 0x00000003 hash 'd298436679a008f8'
Read fixup4.dat bytes     5407 hnd 0x00000226 hash '33dee5d007b097b2'
0x00d03114 0x00000000 0x00000fff
MEM GPU: 76 ARM: 948 TOTAL: 1024
Starting start4.elf @ 0xfec00200 partition 0

MESS:00:00:04.834808:0: arasan: arasan_emmc_open
MESS:00:00:05.123531:0: brfs: File read: /mfs/sd/config.txt
MESS:00:00:05.126212:0: brfs: File read: 42 bytes
MESS:00:00:05.180392:0: HDMI0:EDID error reading EDID block 0 attempt 0
MESS:00:00:05.189902:0: HDMI0:EDID error reading EDID block 0 attempt 1
MESS:00:00:05.199417:0: HDMI0:EDID error reading EDID block 0 attempt 2
MESS:00:00:05.208927:0: HDMI0:EDID error reading EDID block 0 attempt 3
MESS:00:00:05.218441:0: HDMI0:EDID error reading EDID block 0 attempt 4
MESS:00:00:05.227948:0: HDMI0:EDID error reading EDID block 0 attempt 5
MESS:00:00:05.237462:0: HDMI0:EDID error reading EDID block 0 attempt 6
MESS:00:00:05.246972:0: HDMI0:EDID error reading EDID block 0 attempt 7
MESS:00:00:05.256486:0: HDMI0:EDID error reading EDID block 0 attempt 8
MESS:00:00:05.265994:0: HDMI0:EDID error reading EDID block 0 attempt 9
MESS:00:00:05.270499:0: HDMI0:EDID giving up on reading EDID block 0
…
MESS:00:00:06.891971:0: hdmi: HDMI1:EDID error reading EDID block 0 attempt 3
MESS:00:00:06.902009:0: hdmi: HDMI1:EDID error reading EDID block 0 attempt 4
MESS:00:00:06.912039:0: hdmi: HDMI1:EDID error reading EDID block 0 attempt 5
MESS:00:00:06.922076:0: hdmi: HDMI1:EDID error reading EDID block 0 attempt 6
MESS:00:00:06.932109:0: hdmi: HDMI1:EDID error reading EDID block 0 attempt 7
MESS:00:00:06.942147:0: hdmi: HDMI1:EDID error reading EDID block 0 attempt 8
MESS:00:00:06.952177:0: hdmi: HDMI1:EDID error reading EDID block 0 attempt 9
MESS:00:00:06.957206:0: hdmi: HDMI1:EDID giving up on reading EDID block 0
MESS:00:00:06.962804:0: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead
MESS:00:00:06.971568:0: HDMI0: hdmi_pixel_encoding: 300000000
MESS:00:00:06.977039:0: HDMI1: hdmi_pixel_encoding: 300000000
MESS:00:00:06.987239:0: dtb_file 'bcm2711-rpi-4-b.dtb'
MESS:00:00:06.989313:0: Failed to load Device Tree file '?'
MESS:00:00:06.994609:0: Failed to open command line file 'cmdline.txt'
MESS:00:00:07.001148:0: No compatible kernel found

No i fajnie, RPi4 jest już gotowe aby wystartować kernel Linuksa, a tym zajmiemy się już w kolejnej lekcji.

Wstęp

W tej lekcji przygotujemy sobie środowisko pracy czyli:

1. Pobierzemy toolchain
2. Przygotujemy kartę uSD(dla osób używających BBB i RPi4)
3. Skompilujemy QEMU

Toolchain

Zacznijmy może od wytłumaczenia czym jest ten toolchain. Najprościej mówiąc jest to zbiór narzędzi potrzebnych do zbudowania oprogramowania czyli jest to po prostu zbiór niezbędnych kompilatorów, linkerów i tego typu programów.

Z pojęciem toolchaina łączy się jeszcze pojęcie cross-kompilacji czyli budowania programu na inną architekturę docelową niż architektura maszyny budującej. Mówiąc obrazowo, gdy standardowo piszesz program np. w C++ i kompilujesz go następnie za pomocą kompilatora g++ wykonujesz proces kompilacji- kompilujesz program na swoim komputerze i na nim go uruchamiasz. Z cross-kompilacją mamy do czynienia gdy ten sam program budujesz na swoim komputerze, a uruchamiasz np. na RPi4.

Ale do rzeczy, musimy mieć jakiś toolchain, którym będziemy mogli zbudować oprogramowanie na interesujące nas platformy. My będziemy używać toolchaina dostarczanego przez Linaro. Pobierz toolchain odpowiedni dla twojej platformy:

# BeagleBone Black
wget https://releases.linaro.org/components/toolchain/binaries/latest-7/arm-linux-gnueabihf/gcc-linaro-7.5.0-2019.12-x86_64_arm-linux-gnueabihf.tar.xz
# QEMU
wget https://releases.linaro.org/components/toolchain/binaries/latest-7/arm-linux-gnueabi/gcc-linaro-7.5.0-2019.12-x86_64_arm-linux-gnueabi.tar.xz
# Raspberry Pi 4 i opcjonalnie QEMU
wget https://releases.linaro.org/components/toolchain/binaries/latest-7/aarch64-linux-gnu/gcc-linaro-7.5.0-2019.12-x86_64_aarch64-linux-gnu.tar.xz

Gdy już pobrałeś interesujący Cię toolchain rozpakuj pobraną paczkę:

tar xf toolchain.tar.xz

Polecam rozpakować toolchain do jakiegoś sensownego miejsca ponieważ będzie on nam później potrzebny.

Następnie musimy dodać lokalizację kompilatorów do zmiennej środowiskowej PATH aby były one łatwo dostępne z każdego miejsca w systemie. Aby to zrobić wywołaj komendę:

export PATH=$PATH:/ścieżka/do/toolchain/bin

Teraz możesz wywołać kompilatory Linaro z jakiegokolwiek miejsca w systemie. Aby ta zmiana zmiennej PATH była stała dodaj ten wpis w pliku ~/.basrc. Jeśli nie dodasz ustawienia zmiennej PATH do tego pliku będziesz musiał ją ustawiać za każdym razem gdy uruchamiasz konsolę.

Przygotowanie karty uSD

Jeśli zamierzasz używać QEMU możesz pominąć tę sekcje.

Bootloader, firmware, kernel czy pliki systemowe Linuksa będą się znajdować na karcie uSD, którą będziemy umieszczać w BBB lub RPi4, przygotujmy więc sobie odpowiednio karty pamięci. Do przygotowania posłużą nam programy parted oraz mkfs. Zanim przejdziesz do operacji na karcie upewnij się, że zgrałeś z niej wszystkie istotne dla Ciebie pliki. Po drugie upewnij się, że wykonujesz wszystkie operacje na karcie uSD, a nie np. na podłączonym do komputera dysku. Karty pamięci są zazwyczaj reprezentowane w systemie przez pliki /dev/mmcblkX gdzie X to liczba naturalna, ewentualnie jeśli używasz czytnika kart SD, który podłącza się do komputera za pomocą USB wtedy może zostać ona wykryta jako /dev/sdX gdzie X to litera z alfabetu. Jeśli masz wątpliwości co do tego jak została twoja karta nazwana w systemie możesz użyć programu dmesg i zobaczyć ostatnie logi po podłączeniu karty.

BeagleBone Black

W przypadku BBB kartę podzielimy na trzy partycje:

1. Pierwsza partycja będzie zawierać bootloader i będzie używała systemu plików FAT32
2. Druga partycja będzie przechowywać kernel i device-tree, będzie używała systemu plików ext4
3. Trzecia partycja będzie zawierała rootfs Linuksa, też będzie używać systemu plików ext4

Aby tak sformatować kartę pamięci wykonaj następujące komendy:

sudo parted --script /dev/kartaSD mklabel msdos \
                      mkpart primary fat32 0% 100MiB \
                      mkpart primary ext4 100MiB 1100MiB \
                      mkpart primary ext4 1100MiB 100% \
                      set 1 boot on

sudo mkfs.vfat /dev/kartaSD1 -n uboot
sudo mkfs.ext4 /dev/kartaSD2 -L kernel
sudo mkfs.ext4 /dev/kartaSD3 -L rootfs

Raspberry Pi 4

W przypadku RPi4 kartę podzielimy na dwie partycje:

1. Pierwsza partycja będzie zawierać firmware, kernel i device-tree, będzie używała systemu plików FAT32
2. Druga partycja będzie przechowywać rootfs i będzie używała systemu plików ext4

Aby tak sformatować kartę pamięci wykonaj następujące komendy:

sudo parted --script /dev/kartaSD mklabel msdos \
                     mkpart primary fat32 0% 1GiB \
                     mkpart primary ext4 1GiB 100% \
                     set 1 boot on
sudo mkfs.vfat /dev/kartaSD1 -n boot
sudo mkfs.ext4 /dev/kartaSD2 -L rootfs

W obu przypadkach za pomocą programu parted stworzyliśmy nową tablicę partycji typu MS-DOS z czego pierwsza partycja jest partycją rozruchową. Za pomocą programów mkfs sformatowaliśmy partycje do odpowiednich formatów i nadaliśmy im etykiety wyjaśniające ich przeznaczenie.

QEMU

Jeśli jesteś bardzo leniwy to możesz pobrać QEMU z repozytoriów np. Ubuntu za pomocą dobrze wszystkim znanej komendy apt install, nie polecam jednak takiego podejścia ponieważ są tam dosyć stare wersje tego oprogramowania.

My przejdziemy tutaj trochę trudniejszą ścieżką, ale będziemy mieli za to niemalże najnowszą wersje QEMU 6.0.0 z bieżącego roku czyli z 2021, która działa znacznie lepiej niż to co jest dostępne w repozytoriach w repozytoriach Ubuntu.

Paczkę z kodem QEMU 6.0.0 możesz pobrać tutaj:

wget https://download.qemu.org/qemu-6.0.0.tar.xz

Po pobraniu rozpakuj paczkę:

tar xf qemu-6.0.0.tar.xz

Przejdź do rozpakowanego katalogu. Zanim zaczniemy budować musimy najpierw uruchomić skrypt configure. Aby nie budować emulatorów dla wszystkich dostępnych architektur podamy skryptowi configure parametr mówiący żeby zbudował emulatory dla ARM, ARM64 oraz x86_64:

./configure –target-list=arm-softmmu,aarch64-softmmu,x86_64-softmmu

Skrypt configure może krzyczeć, że brakuje mu jakiś pakietów, w takim przypadku należy doinstalować brakujący pakiet. Nie będę podawać, które pakiety trzeba doinstalować, niech to będzie Twoje zdanie bojowe 🙂

Gdy już mamy skonfigurowane wszystko możemy przystąpić do budowania QEMU, aby to zrobić wykorzystamy standardową komendę make:

make # tak, bez żadnych parametrów

Kompilacja może chwilę zająć(u mnie trwała prawie 8 i pół minuty) więc możesz pójść sobie zrobić herbatkę, kawkę czy co tam lubisz.

Po zbudowaniu wszystkie wygenerowane pliki znajdują się w katalogu build. Nas z tego katalogu oczywiście interesują emulatory czyli pliki qemu-system-arm, qemu-system-aarch64 oraz qemu-system-x86_64.

Możesz zainstalować QEMU na swoim komputerze za pomocą narzędzia make:

make install

Ale nie musisz tego robić, jak chcesz to możesz uruchamiać pliki z katalogu build.

I dewolaj! Jak to mawiają Francuzi. Masz gotowe środowisko pracy aby zacząć stawiać pierwsze kroki w tworzeniu własnej dystrybucji Linuksa.