Kategoria: Embedded Linux

  • FRDM i.MX91S – jak wgrać obraz na płytkę

    FRDM i.MX91S – jak wgrać obraz na płytkę

    Wprowadzenie- jak uruchomić FRDM i.MX91S po buildzie Yocto

    W poprzednim poście zbudowałem przykładowy obraz systemu w oparciu o Yocto, dlatego w tym wpisie zajmę się wgraniem tego systemu na płytkę FRDM i.MX91S od NXP.

    Dwie metody flashowania obrazu na kartę SD

    Istnieją 2 główne metody wgrywania obrazu sytemu kartę SD- bo płytka iMX91S właśnie z takiej karty się bootuje. Metody to

    1. użycie narzędzia bmaptool
    2. użycie narzędzia uuu

    Szybkie wgrywanie obrazu przez bmaptool

    Opcja pierwsza wymaga wyjęcia karty SD, włożenia jej do komputera z systemem linux i zawołania komendy copy w narzędziu bmaptool. Do komendy dodajemy plik z obrazem (rozszerzenie .wic.zst) oraz miejsce, gdzie znajdziemy naszą kartę SD- u mnie to /dev/sda.

    Jeśli poda się też plik imx-image-core-imx91-11x11-lpddr4-frdm-imx91s.rootfs.wic.bmap obok jego odpowiednika z rozszerzeniem zst to karta wgra się błyskawicznie.

    sudo bmaptool copy --bmap imx-image-core-imx91-11x11-lpddr4-frdm-imx91s.rootfs.wic.bmap imx-image-core-imx91-11x11-lpddr4-frdm-imx91s.rootfs.wic.zst /dev/sda

    U mnie 2.4 GB obraz wgrywal sie na karte około 37 sekund – łącznie z rozpakowaniem zstd.

    Wgrywanie obrazu przez NXP uuu (USB recovery)

    Druga opcja to uuu tool od NXP. Tak jak bmaptool użyjesz do płytek od innych vendorów tak uuu działa tylko dla NXP.

    Przygotowanie płytki do trybu Serial Download

    Żeby skorzystać z uuu należy go zainstalować. Następnie trzeba podpiąć kable USB do płytki – jeden jest do połączenia szeregowego i jest oznaczony jako DEBUG, a drugi, oznaczony jako TYPE-C USB1- właśnie do wgrywania. Potem trzeba przestawić zworki na płytce, żeby ustawić ją w tryb Serial Download. To ostatnie osiągam przez ustawienie DIP Switcha na 0001.

    Weryfikacja połączenia z płytką

    Po podłączeniu przestawieniu DIP Switcha na 0001, podłączeniu kabla USB-C oraz włączeniu urządzenia – można je wykryć na komputerze host. Do tego celu używamy uuu -lsusb.

    Znalazło płytkę! To przechodzimy do kolejnego kroku:

    Flashowanie obrazu

    Skoro płytka jest wykryta, możemy wgrać obraz na kartę SD przy użyciu uuu toola. Żeby tego dokonać wołamy komendę:

    sudo uuu -b sd_all ./imx-image-core-imx91-11x11-lpddr4-frdm-imx91s.rootfs-20260429200202.wic.zst

    Do komendy uuu przekazaliśmy parametr -b sd_all, który mówi żeby uuu skorzystał ze swojego wbudowanego skryptu do wypalenia całego obrazu na karcie SD. Jeśli Twoja płytka ma wbudowaną pamięć eMMC – wtedy korzystasz z innego wbudowanego skryptu, np. -b emmc_all.

    Na koniec podajesz obraz w formacie wic – może być spakowany – jak u mnie przy użyciu facebookowego Zstandard.

    Pierwsze uruchomienie systemu i dostęp przez UART

    Po zakończonym wgrywaniu przestawiam zworki z powrotem na oryginalną pozycję. Według tabelki z tyłu płytki powinno to być 0011, ale w rzeczywistości, przynajmniej w mojej płytce- jest to 1100. Możliwe, że to bug w dokumentacji.

    Podłączam zasilanie, żeby wystartować płytkę, startuję minicom albo screen, żeby podłączyć się do serial’a (ten drugi port USB-C oznaczony DEBUG- znajduje się obok portu do wgrywania systemu) i pyk – mamy ten system:

    Uwagi praktyczne i problemy ze zworkami

    Co wybrać – uuu czy bmaptool w przypadku i.MX91S?

    Po przetestowaniu obu narzędzi dla siebie wybieram bmaptool, bo jest po prostu szybszy. Wyjęcie karty SD i przełożenie jej do czytnika zajmuje o wiele mniej czasu niż czekanie aż uuu skończy działać.

    Gdyby istniała możliwość zautomatyzowania sterowania DIP Switchem to wtedy przestawiłbym się na uuu, ale w przypadku i.MX91S musiałbym przylutować dodatkowe kable albo w inny sposób zastąpić DIP Switch zwykłymi zworkami. Na ten moment jest to nieopłacalne.

    Błąd w dokumentacji

    Na tylnej części płytki PCB znajduje się mała tabela, mówiąca o trybach bootowania:

    SW1 [4-1]BOOT DEVICE
    0001Downloader
    0011SDHC
    0101FlexSPI NAND

    Oznacza to w skrócie, że ustawiając DIP Switch w pozycję 0001 – mamy tryb Serial Download, który pozwala na wykorzystanie uuu, następnie w pozycji 0011 – startujemy z karty SD, a w pozycji 0101 – z wbudowanej pamięci NAND Flash o rozmiarze 256MB.

    Niestety po ustawieniu DIP Switcha w pozycję 0011 czyli bootowania z karty SD – płytka nie działa. Działa natomiast po ustawieniu pozycji na 1100 – w takiej pozycji przyszła do mnie ta płytka i bootowanie z karty SD działało. Jest to moim zdaniem błąd, o którym warto pamiętać korzystając z tej płytki.

    Podsumowanie

    Po przestestowaniu dwóch możliwych sposobów na wgranie software’u na płytki mogę podjąć świadomą decyzję i korzystać z bmaptoola do wgrywania nowych obrazów na i.MX91S.

    Gdybym miał potrzebę zautomatyzowania tego wgrywania – na pewno przestawiłbym się na korzystanie z uuu toola, ale przez brak możliwości łatwego zautomatyzowania sterowania DIP Switchem – rezygnuję z tej możliwości.

    Na koniec warto pamiętać o tym, że wgrywanie nowego obrazu w przyszłości nie będzie zdarzało się często, bo chcę opracować system aktualizacji – w oparciu o jedno ze znanych narzędzi jak np. swupdate, Mender lub RAUC. Gdy już takie rozwiązanie powstanie to na pewno znajdzie się tutaj link do tego posta.

  • Jak zbudować obraz Yocto dla FRDM i.MX91S

    Jak zbudować obraz Yocto dla FRDM i.MX91S

    Ten tekst jest częścią serii o FRDM imx91s.

    Postawienie własnego systemu operacyjnego na płytce ewaluacyjnej przy użyciu Yocto jest względnie proste. Zaraz zbudujesz ze mną obraz takiego systemu, czyli bootujący Linux na FRDM i.MX91S zbudowany przy użyciu Yocto.

    Instrukcje prosto od NXP

    Najlepszym sposobem na zbudowanie systemu to skorzystanie z instrukcji przygotowanej przez NXP. Znajduje się ona m.in. w repozytorium meta-imx, jest po angielsku i dotyczy naprawdę wielu płytek ewaluacyjnych. Skoro posiłkuję się NXP iMX91S to skupmy się właśnie na niej.

    Wybrana wersja SDK od NXP

    Domyślny branch repozytorium meta-imx wskazuje na walnascar-6.12.34-2.1.0 ale widzę, że jest dostępny też walnascar-6.12.49-2.2.0 i wybieram właśnie ten branch do dalszej pracy. O wersjach Yocto – LTS, non-LTS oraz tym jak podchodzą do tego vendorzy (jak np. NXP, TI, itd) będzie w osobnym poście. Z nazwy brancha można wyciągnąć takie informacje:

    • Wersja Yocto (przynajmniej teoretycznie): 5.2, codename: Walnascar
    • Wersja kernela Linuxa: 6.12.49
    • Wersja SDK od NXP: 2.2.0

    Samo mięso – komendy do kopiuj/wklej 

    mkdir -p ~/builds/frdm-build 
    
    cd ~/builds/frdm-build/
    
    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 krótce co tu się dzieje:

    Tworzenia katalogu nie trzeba tłumaczyć.

    Potem narzędziem repo od Google pobieram meta warstwy zdefiniowane w repo imx-manifest.

    Następnie wołam skrypt przygotowujący środowisko do budowania. Zmienna MACHINE- wybiera płytkę ewaluacyjną, a zmienna DISTRO- tryb dystrybucji.

    Na koniec komendą bitbake buduję obraz imx-image-core. Ten ostatni krok z reguły trwa długo, zwłaszcza przy pierwszym jego uruchomieniu. Zależnie od maszyny do budowania – nawet kilka godzin.

    Upieczone artefakty

    Całe Yocto ma wiele odniesień do książki kucharskiej. Dlatego po upieczeniu obrazu imx-image-core zaglądam z ~/builds/frdm-build/build do tmp/deploy/images/imx91-11x11-lpddr4-frdm-imx91s/. Znajduję w nim kilka istotnych plików:

    • imx-image-core-imx91-11x11-lpddr4-frdm-imx91s.rootfs.wic.zst – mój docelowy obraz systemu
    • imx-image-core-imx91-11x11-lpddr4-frdm-imx91s.rootfs-20260513212841.wic.bmap – plik ułatwiający szybkie flashowanie obrazu
    • imx-image-core-imx91-11x11-lpddr4-frdm-imx91s.rootfs.manifest – lista wszystkich paczek software’u, które są zainstalowane w obrazie – 1696 linii- trochę dużo. Naprawię to później
    • imx-boot – obraz bootloadera – będący częścią obrazu wic
    • Image – surowy obraz kernela linuxa

    Wystarczy mi w zupełności ten pierwszy, bo można go użyć do wgrania systemu na płytkę.

  • FRDM imx91s – seria z Yocto i Home Assistantem – intro

    FRDM imx91s – seria z Yocto i Home Assistantem – intro

    Ostatnio odkryłem, że NXP Semiconductors zaczął sprzedawać budżetowe wersje swoich płytek ewaluacyjnych pod szyldem FRDM (freedom?). Postanowiłem więc kupić jedną z nich i zrobić na niej coś fajnego.

    Dlaczego FRDM i.MX91S

    Celowałem w płytkę i.MX91 z dwoma portami ethernetowymi, ale padłem ofiarą firmy Farnell, która użyła zdjęcia płytki i.MX91 do produktu i.MX91S. W ten sposób mam inną niż planowałem, ale wciąż całkiem fajną płytkę prototypową – patrz zdjęcie powyżej.

    Co chcę zbudować?

    Akurat grzebałem w Home Assistant i pomyślałem, że fajnie byłoby wystawić do niego kilka prostych czujników. Dodatkowo zawodowo jestem Yocto’wcem (stawiam systemy operacyjne oparte o Linuxa), więc zdecydowałem się na napisanie serii, w której pokażę jak z użyciem Yocto zbudować system operacyjny, który będzie zawierał prostą aplikację, która korzystając z MQTT Discovery pokaże w Home Assistancie wartość czujnika temperatury właśnie z płytki i.MX91S.

    Plan serii

    Skoro zdanie opisujące co chcę zrobić zajęło kilka linijek, to dobrze będzie rozbić to na części. Więc oto co zrobimy:

    1. zbudujemy obraz systemu operacyjnego z użyciem Yocto, który będzie dedykowany dla płytki FRDM i.MX91S – zobacz wpis
    2. wgramy ten obraz na płytkę ewaluacyjną – zobacz wpis
    3. Wytłumaczę Ci jak działa MQTT Discovery (pisząc tą listę sam jeszcze nie wiem)
    4. Napiszemy wspólnie prosty program, który wyeksponuje wartość temperatury z systemu na płytce FRDM do Home Assistanta

    Może tyle wystarczy na początek.

    Zobaczmy dokąd to nas zaprowadzi.

  • Sprawdzanie CVE z Yocto Kirkstone i Scarthgap

    Sprawdzanie CVE z Yocto Kirkstone i Scarthgap

    W świetle nadchodzących zmian związanych z wchodzącym Cyber Resilience Act organizacje kładą coraz większy nacisk na sprawdzanie i rozwiązywanie CVE (Common Vulnerability and Exposures). Jeśli budujesz swoje obrazy Linuxa korzystając z Yocto to możesz skorzystać z wbudowanych mechanizmów pozwalających na sprawdzenie bazy NIST (National Institute of Standards and Technology) i wykrycie które CVE dotyczą aplikacji w twojej dystrybucji.

    Włączenie cve-check w Yocto

    Samo włączenie sprawdzania CVE w Yocto jest bardzo proste. Wystarczy, że do swojego pliku local.conf dodasz następującą linię:

    INHERIT+="cve-check"

    a następnie zbudujesz paczkę lub obraz komendą bitbake. Poza standardową procedurą budowania dodany zostanie jeden task- do_cve_check, który pobierze bazę danych o CVE ze strony NIST, a następnie sprawdzi wersje twoich aplikacji w bazie.
    Efektem tego będzie plik z listą CVE. W Yocto 3.1 (Dunfell) był to zwykły plik tekstowy, a w Yocto 4.0 (Kirkstone) dodano również odpowiednik tego raportu w formacie JSON.

    Jak łatać CVE w Yocto?

    Opcja 1: Aktualizowanie meta warstw

    Najprostszym sposobem naprawy luk jest aktualizacja meta warstw (np. meta-openembedded, meta-oe, poky). W wielu przypadkach nowe wersje warstw zawierają poprawki na CVE i ich aktualizacja może rozwiązać problem. Jednak aktualizacja całej warstwy może wprowadzić zmiany w innych pakietach, co wymaga testów kompatybilności.

    Opcja 2: korzystanie z patchy

    Gdy aktualizacja meta warstw nie jest możliwa lub pożądana, można ręcznie dodawać patche naprawiające konkretne podatności. W Yocto można to zrobić poprzez dodanie patchy do katalogu files/ w warstwie BSP i modyfikację SRC_URI w pliku recipe.

    Opcja 3: allowlisting

    Jeśli dany CVE nie stanowi realnego zagrożenia w kontekście projektu, można go dodać do allowlisty, aby uniknąć fałszywych alarmów. Aby to zrobić w Dunfell, można dodać numer CVE do pliku cve-check-exclude.txt.

    W Kirkstone…

    TODO

    Minusy korzystania z bazy NIST

    Baza NIST zawiera wiele wpisów, ale nie zawsze odzwierciedla rzeczywisty poziom ryzyka dla konkretnego projektu. Może też zawierać opóźnione aktualizacje, co powoduje, że niektóre podatności mogą być zgłaszane jako aktywne, mimo że są już załatane w upstreamie.

    W lutym 2024 rozwiązywanie CVE przez NIST znacznie zwolniło i taki stan utrzymał się przez około 3 miesiące. Instytut nie wytłumaczył co było powodem tej zmiany zachowania.

    Z kolei w grudniu 2024 znacznie zwolniła prędkość pobierania bazy NIST przy użyciu API- pobranie jednej bazy trwało czasem nawet ponad 24h.

    Dlatego też warto pamiętać, że NIST i jego NVD (National Vulnerability Database) nie jest jedynym miejscem, gdzie mamy do czynienia z listą vulnerabilities. Alternatywą może być baza MITRE, wewnętrzna baza BluckDuck i inne.

    Co dalej z tymi CVE?

    Korzystanie z BlackDuck

    TODO

    Nowsze rozwiązania – yocto-vex-check

    Yocto-vex-check