[pepepanpatryk]

Kurde powiem wam, że na pewne tematy czasem ciężko znaleźć coś sensownego w necie, a i podsykutować nie ma z kim (na mailing listach czasem odpiszą, czasem nie). A potrzebuję dowiedzieć się coś na temat "jak inni to robią produkcyjnie", zarzucę więc temat na wykop a nuż ktoś coś powie ciekawego na ten temat.

Robię aktualnie firmware oraz software update na naszej płytce i zastanawiam się jak do tego podejść.
SoC którego używam posiada następujący stos fw / sw:
Firmware:
- Boot ROM (brak możliwośći aktualizacji)
- BL2 (TF-A BL2) (brak możliwości aktualizacji)
- BL31 (TF-A BL31) (część FIP)
- BL32 (OPTEE) (część FIP)
- BL33 (u-boot) (część FIP)
Software:
- kernel
- rootfs

Jak widać cały ten stos można podzielić na dwie kategorie:
- firmware który zapakowany jest w Firmware Image Package (BL31, BL32, BL33)
- software czyli kernel oraz rootfs

Aktualizacje chce robić na zasadzie A/B. Jeżeli chodzi o firmware, to TF-A BL2 umożliwia uruchomienie fwupdate zgodnie ze specyfikacja PSA Firmware Update, gdzie mam dwa banki firmware np. fip-a oraz fip-b, na podstawie informacji zawartych w metadanych bl2 wybiera wlaściwy bank i go bootuje. To trzbea było doimplementować w TF-A ofc dla naszej płytki (bo jedyny vendor który udostępnia gotowe rozwiązanie to ST...) co już zrobiłem. Podobnie w u-boocie, dwa banki na bootfs z image kernela, + dwa banki rootfs.

Czego akurat nie jestem pewien to jak podejść hmm koncepcyjnie do aktualizacji bo widzę kilka możliwości. Najczęściej wymienianym elementem będzie rootfs zawierający aplikacje, które będa zapewne aktualizowane dość często. Rzadziej aktualizowany będzie kernel, a zapewne najrzadziej FIP choć na pewno i tu akutalizacje się pojawia bo mamy kilka pomysłów gdzie chcielibyśmy wykorzystać optee, ale to zapewne w dalszej fazie projektu.

W związku z tym widzę następujące scenariusze:
1) jeżeli użytkownik będzie chciał zaktualizować firmware to instaluje paczkę która zawiera cały stos sw + fw
2) jeżeli użytkownk będzie chciał zaktualizować kernel to instaluje paczkę która zawiera kernel + obowiązkowo rootfs
3) jeżeli użytkownik będzie chciał zaktualizować rootfs to instaluje paczkę, która zawiera tylko rootfs

I o ile scenariusze 1 oraz 2 wydaja mi się sensowne, tak obawiam się troszkę scenariusza nr. 3, który w teorii jest najmniej inwazyjny. Generalnie posiadam na rootfs również moduły kernela i tak się zastanawiam czy może dojść do sytuacji gdzie dostarczony sam rootfs będzie zawierał moduły, które w jakiś sposób będą niekompatybilne z aktualnym kernelem. Rozwiązaniem potencjalnie byłaby obligatoryjna aktualizacja kernela przy aktualizacji rootfs. Czyli użytkownik chce zaktualizować nowe aplikacje (czyli de facto wymienić rootfs) ale paczka zawiera rootfs oraz obowiązkowo kernel.
Potencjalnie też mógłbym wywalić moduły do ramdisk (który i tak używam bo w initramfs uruchamiam dm-crypt do [de]szyfrowania rootfs), tylko to też niesie ze sobą pewne konsekwencje chociażby w postaci zwiększonego zużycia RAM na rzeczy, których aktualnie nie potrzebuje - np. moduły które są ładowane na X wariancie płyty a na Y nie, mimo to będą zajmować miejsce w RAM.

Kojarzy ktoś może jak to jest na androidzie? Podejrzłem sobie trochę jak wygląda impementacja bootowania androida zaimplementowana w u-boot ale ofc to jest już po etapie ładowania u-boota przez firmware...

#embedded

[kacpervfr]

Taktyk

[Oo-oO]

@pepepanpatryk: Wiesz, do dyskusji trzeba (przynajmniej) dwojga - a z tego co pamiętam, w kilku twoich wpisach nie było dialogu, a czasem było wręcz narzekanie, że nikt nie pisze; więc w temacie napiszę tylko krótko - z moich doświadczeń wynika że aktualizacja całego rootfs nie jest wcale taka konieczna - w wielu przypadkach można spokojnie poradzić sobie z dodatkową niewielką partycją squashfs, z której w trakcie aktualizacji można wypakować sobie faktyczne

[pepepanpatryk]

@Oo-oO szczerze mówiąc zaskoczyłeś mnie z tym "narzekaniem" bo nie przypominam sobie czegoś takiego.

yagni - tzn, życzę żeby się wam udało, ale pozwolę sobie być sceptyczny

@Oo-oO: To sprecyzuję - już korzystamy z OPTEE chociażby do obsługi Secure Storage z wykorzystaniem RPMB na eMMC. Bardzo możliwe, że wykorzystamy go jeszcze do autoryzacji offline ale to jeszcze zobaczymy, nie jest to priorytet.

Swoją drogą im dłużej się nad tym

[QBA__]

Cześć mireczku

Sam u siebie w projektach nie stosuję optee ani arm-tf i znam te technologie tylko z nazwy, ale opisze Ci jak u mnie wygląda to na urządzeniach. Korzystam z swupdate do aktualizacji
Głównie zajmuję się płytkami z imx6ULL i imx7D. Domyślam się że używasz Yocto, bo kilka razy kiedyś coś tam pisaliśmy.
Mam zdefiniowane pliki .wks z partycjami:
I tak mniej więcej to u mnie wygląda pamięć eMMC:

[pepepanpatryk]

@QBA__: Cześć dzięki wielkie za odpowiedz, swupdate znam bo już integrowałem to w innym projekcie i generalnie ten bootflow mam koncepcyjnie podobnie jak opisałeś włącznie z overlay na /etc. Jedyne co się tak naprawdę w tym momencie zastanawiam to czy separować aktualizacje firmware od aktualizacji software, gdzie de facto może dojść do tego, że fw będzie startował z banku A a sw z banku B. Technicznie nie jest to problem,

[QBA__]

@pepepanpatryk u mnie też urządzenia nie mają kontaktu ze światem. Co do mojej opinii to chyba oddzielna aktualizacja firmware będzie ok z 2 powodów:
1. Rzadko jest wymagana
2. Potencjał na zbrickowanie urządzenia np. przy nagłej utracie zasilania spory

[Oo-oO]

@pepepanpatryk: no to może się zaraziłem od SI i halucynuję ;) tak mi się jakoś zapamiętało, ale może jeśli coś było - to było coś jednorazowego. Na plus też pamiętałem, że technicznie wpisy były bardzo spoko ;)

W każdym razie samych takich aplikacji robiących aktualizację A/B jest więcej, rauc, mender i inne. Oczywiście coś za coś - licencje i koszty. Jeśli - jak piszesz, nie masz żadnych ograniczeń co do