W poprzednich wpisach pokazałem jak łatwo zbudować obraz systemu Linux na urządzenie FRDM i.MX91S od NXP. Co jeśli powiedziałbym, że można to samo osiągnąć jeszcze łatwiej – nawet jedną komendą?
Do tego typu rozwiązań powstało narzędzie kas od firmy Siemens. Firma natrafiła na następujący problem: mając wiele urządzeń i wiele różnych obrazów systemu – ciężko się w tym wszystkim połapać, a rekonfiguracja ustawień danego projektu nie jest tak prosta jak mogła by być. Kas jest rozwiązaniem, a dodatkowa konteneryzacja budowania pozwala uniezależnić się od systemu, na którym buduje się obrazy. Zaraz przedstawię Ci więcej na ten temat.
TL;DR
Może zacznijmy od przetestowania gotowego rozwiązania.
Wykonaj poniższe komendy u siebie w terminalu, a obraz zacznie się budować – będziesz mieć dużo czasu na przeczytanie reszty posta 🙂
git clone https://github.com/lewicki-pk/meta-leos/ && cd meta-leos
scripts/kas-container build kas-frdm-walnascar.yamlTo tyle – jeśli pominiemy linię klonującą repozytorium meta-leos to pozostaje nam jedna linijka, żeby zbudować projekt- do tego dążymy.
Czym właściwie jest kas
Kas to narzędzie, które pozwala opisać konfigurację projektu Yocto w jednym lub kilku plikach YAML.
Nie zastępuje ono BitBake ani Yocto.
Jego zadaniem jest przygotowanie środowiska i uruchomienie builda w powtarzalny sposób.
Rationale – po co nam to wszystko?
Wygodne przygotowanie meta warstw
Zaczynając pracę z Yocto – użycie repo tool’a wydaje się naturalnym krokiem, bo dzięki niemu masz dostęp do wszystkich interesujących cię meta warstw. Meta warstwy zdefiniowane w xml’owym manifeście używanym w repo toolu, de facto robią jedną rzecz- wołają git clone na wszystkich repozytoriach zawierających meta warstwy i umieszczają je w uzgodnionym miejscu. To jednak za mało.
Żeby zamknąć temat definiowania warstw – należy je jeszcze umieścić w pliku bblayers.conf a to nie dzieje się automatycznie – pomaga nam w tym zawołanie komendy source ./imx-setup-release.sh z odpowiednimi zmiennymi i parametrami.
Ustawienie maszyny i dystrybucji
W oryginalnym poście pokazałem, że skrypt imx-setup-release.sh należy zawołać w taki sposób:
MACHINE=imx91-11x11-lpddr4-frdm-imx91s DISTRO=fsl-imx-wayland source ./imx-setup-release.sh -b buildCzyli użytkownik musi wiedzieć jakie MACHINE go interesuje oraz jakie ustawić DISTRO, co nie zawsze jest oczywiste, zwłaszcza dla początkujących.
Powyższy kod przyjmuje też parametr -b build – to kolejny punkt, który nie jest oczywisty dla początkujących. Co on robi? Startuje budowanie? Nie. On tylko mówi, że budowanie ma się znaleźć w folderze build znajdującym się w miejscu, z którego wołany jest skrypt.
Dodatkowo- powyższy kod również wyświetla użytkownikowi EULA (End User License Agreement), które musi być potwierdzone.
Za każdym razem, gdy wracam do projektu po kilku miesiącach muszę przypominać sobie:
- jaką MACHINE wybrałem
- jakiego DISTRO używałem
- gdzie znajdował się katalog build
To właśnie ten problem rozwiązuje kas.
Dodatkowe ustawienia w local.conf
Wszystkie dodatkowe ustawienia, które chcielibyśmy, żeby znalazły się w konfiguracji projektu przy poprzednim podejściu musielibyśmy dodawać do pliku local.conf ręcznie, ale z kas nawet nie musimy o nich pamiętać – wystarczy, że dodamy je raz do pliku yaml.
W tym projekcie są to np. linie czyszczące dysk po zbudowaniu projektu – INHERIT+="rm_work" a także zapisujące w obrazie dane konfiguracji projektu INHERIT+="image-buildinfo".
Wniosek
Wszystkie te kroki mogą być przeniesione do jednego pliku w formacie yaml a następnie zinterpretowane przez narzędzie kas.
Przystępna konfiguracja w jednym pliku
Zajrzyj do tego pliku na githubie. Jest to plik yaml używany przez narzędzie kas. Mogą w nim znaleźć się wszystkie informacje potrzebne do:
- zrobienia
git clonena wszystkich meta warstwach - przygotowaniu pliku
conf/bblayers.conf - przygotowaniu pliku
conf/local.conf - wystartowania komendy
bitbakena odpowiednim obrazie
Możliwość podejścia modułowego
Narzędzie kas pozwala na wygodną modularyzację konfiguracji w plikach yaml. Gdy ma się mnóstwo buildów na różne urządzenia- w kas można poszczególne części konfiguracji podzielić na różne pliki i do budowania używać jednego, który include’uje pozostałe części.
Before & After
Spójrzmy jeszcze raz na to jak wyglądało przygotowanie budowania projektu przed wprowadzeniem konfiguracji kas, a potem zobaczymy jak to wygląda po jej wprowadzeniu.
Konfiguracja przed wprowadzeniem kas
repo init -u https://github.com/nxp-imx/imx-manifest.git -b imx-linux-walnascar -m imx-6.12.49-2.2.0.xml
repo sync -j4
MACHINE=imx91-11x11-lpddr4-frdm-imx91s DISTRO=fsl-imx-wayland source ./imx-setup-release.sh -b build # read EULA and confirm it with `y`
bitbake imx-image-corePo wprowadzeniu kas
git clone https://github.com/lewicki-pk/meta-leos/ && cd meta-leos
scripts/kas-container build kas-frdm-walnascar.yaml
