Lewicki Engineering

Tag: kas

  • i.MX91S – prostsza konfiguracja projektu Yocto z narzędziem kas

    i.MX91S – prostsza konfiguracja projektu Yocto z narzędziem kas

    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.yaml

    To 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 build

    Czyli 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 clone na wszystkich meta warstwach
    • przygotowaniu pliku conf/bblayers.conf
    • przygotowaniu pliku conf/local.conf
    • wystartowania komendy bitbake na 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-core

    Po wprowadzeniu kas

    git clone https://github.com/lewicki-pk/meta-leos/ && cd meta-leos
scripts/kas-container build kas-frdm-walnascar.yaml