Wersja: 1.0.2
Ostatnia aktualizacja: 12.03.2025
TL;DR
Dokument ten ma na celu pokazanie, jak dostawcy mogą wdrażać fwupd w przyszłych projektach. Zawiera ona również opinie bezpośrednio od administratorów LVFS. Fwupd to framework do aktualizowania oprogramowania układowego typu open source, który może pomóc w centralizacji sposobu przeprowadzania aktualizacji oprogramowania układowego we współpracy z zewnętrznymi dostawcami.
Pierwszy krok – zbieranie informacji i udzielanie wskazówek
Dostawcy – najpierw zapytaj:
Pytania dotyczące komponentów, które można aktualizować
Rozmiar aktualizacji
Czas aktualizacji
Dotychczasowy typ aktualizacji (model A/B lub bootloadera/czasu wykonywania)
Co się dzieje z funkcjonalnością komponentu podczas aktualizacji?
Co musi się stać, aby system zaczął korzystać z aktualizacji?
Czy wiele komponentów musi być zainstalowanych w określonej kolejności?
znajomość narzędzia LVFS/fwupd lub jego działanie,
możliwość złożenia zasobu inżynierskiego w celu pomocy w implementacji wtyczki (więcej informacji poniżej);
Zobowiązanie się do udostępnienia kodu wtyczki na licencji LGPLv2+ (kodu, który zapisuje oprogramowanie na potrzeby komponentu) oraz umożliwienie rozpowszechniania oprogramowania za pomocą LVFS
Wskazówki dla dostawców:
Aktualizacja musi zminimalizować czas, przez który funkcje peryferyjne lub wewnętrzne są ograniczone, najlepiej do kilku sekund. Dłuższa część aktualizacji powinna odbywać się w tle bez zakłócania pracy użytkownika.
- Jeśli urządzenie peryferyjne w wyraźny sposób wpływa na wrażenia użytkownika (np.wyświetlacz przestaje działać), wymagania stają się jeszcze bardziej rygorystyczne.
Aby umożliwić tego typu aktualizacje, zdecydowanie zalecamy aktualizacje A/B.
- Aktualizacje A/B, które mogą aktywować odłączenie peryferyjnego, są idealne do minimalizowania zakłóceń dla użytkowników
Aktualizacja musi być odwracalna – jeśli wyłączysz zasilanie lub odłączysz urządzenie peryferyjne, aktualizacja nie powinna uszkodzić urządzenia ani urządzenia peryferyjnego. Powinien być odporny na ataki i umożliwiać odzyskanie bez udziału użytkownika.
- Zakładamy, że podczas całego procesu aktualizacji użytkownik nie podejmuje żadnych działań. Odpowiednie skrypty i etapy aktualizacji powinny być realizowane autonomicznie.
Drugi krok – użycie fwupd
Jeśli dostawca nigdy nie używał funkcji fwupd
Chrome OS przekazuje wymagania dotyczące aktualizacji oprogramowania układowego za pomocą fwupd do OEM. Producent OEM powinien przekazać te informacje bezpośrednio dostawcom układów i komponentów.
W niektórych przypadkach ODM może pomóc OEM w bezpośrednim kontaktowaniu się z dostawcami układów. OEM musi przekazać te wymagania odpowiednim podmiotom.
Pamiętaj, że jeśli udostępniasz kod źródłowy na licencji LGPLv2+, wyodrębnienie wtyczki z tego kodu jest zwykle niemożliwe (zbyt wiele zawiłości). W takim przypadku dostawca układów będzie musiał mieć osobę, która będzie współpracować z osobami utrzymującymi fwupd i inżynierami Google.
Producent OEM może działać proaktywnie i pomóc dostawcom chipów w ścisłej współpracy z utrzymawcami. Prośba o pomoc techniczną od zespołu inżynierów po stronie dostawcy musi spełniać te wymagania:
bardzo dobrze znać specyficzne cechy i problemy związane z oprogramowaniem układowym; najlepiej należeć do zespołu, który napisało oprogramowanie układowe;
zrozumieć różnice między popularnymi licencjami na oprogramowanie open source (np. LGPLv2 i MIT);
Znajomość języka C, podstawowa znajomość GLib i GObject, w szczególności GErrors
mieć konto na GitHubie i wiedzieć, jak otworzyć oraz zaktualizować żądanie pull, przeprowadzać przeglądy kodu na GitHubie oraz dowiedzieć się, jak działa fwupd wraz ze wszystkimi pomocnymi funkcjami (np.dzielenie na fragmenty, dołączanie/odłączanie, ponowne próby na urządzeniu, HID itp.);
Opcjonalnie: możliwość wysyłania próbek sprzętu do Wielkiej Brytanii – bardzo przydatna dla administratorów fwupd, aby pomóc dostawcy w rozwiązywaniu problemów, oraz do dodawania płyty do testów fwupd, które są przeprowadzane w przypadku każdej wersji. Ta ostatnia jest ważna, aby zapobiec regresjom w gałęzi rozwojowej.
Równocześnie OEM może zacząć współpracować z pomocą listy mailingowej fwupd lub bezpośrednio z Richardem Hughesem (hughsient@gmail.com) i przed napisaniem kodu wtyczki omówić plan.
Jeśli firma jest mała, ma niewiele lub w ogóle nie ma zasobów inżynieryjnych ani nie rozumie oprogramowania open source, może skorzystać z tych sugestii:
Dostawca komponentu może korzystać z usług firm konsultingowych, które znają się na pracy z oprogramowaniem open source (nie wiąże się to z dodatkowymi kosztami).
Ta sugestia może pomóc w rozwijaniu usługi, ale wartość, jaką daje dostawca, który wykonuje to wewnętrznie, polega na tym, że inżynierowie znają proces i mogą łatwo dodawać VID/PID w przyszłości do nowych urządzeń. Pozwala też szybciej rozwiązywać problemy i zadawać pytania dotyczące debugowania na sprzęcie.
Trzeci krok – ostatnie czynności
Ostatecznie kod jest refaktoryzowany na małe commity, które można sprawdzić, korzystając z całej współdzielonej funkcjonalności w fwupd.
Po zakończeniu procesu wtyczka zostaje scalona z głównym źródłem kodu.
Kod używany w upstreamie jest taki sam jak w ChromeOS.
Binarne pliki binarne aktualizacji oprogramowania układowego używane poza ChromeOS byłyby rozpowszechniane do LVFS.
W przypadku ChromeOS:
Producent OEM musi przesłać binarne oprogramowanie układowe na nasze serwery za pomocą CPFE.
Aby testy regresji sprzętowej mogły działać, w LVFS muszą nadal znajdować się archiwum z archiwami aktualizacji przeznaczonymi do ponownego rozpowszechniania.
Czwarty krok (opcjonalny) – dodawanie nowych komponentów
- Jeśli framework fwupd jest już dostępny, jedynym dodatkowym krokiem jest to, że dostawca komponentów z możliwością aktualizacji musi pracować nad żądaniami pull, aby dodać dziwactwa i VID/PID dla wariantów sprzętowych.
Inne wskazówki – praca nad LVFS
Utwórz nowe konto dostawcy (konfiguracja zajmie ok. 2 minut)
Dostawcy tworzą użytkowników w swojej domenie lub używają usługi takiej jak Azure AD, aby zsynchronizować konta użytkowników z LVFS. Mogą przesyłać oprogramowanie układowe do prywatnych i zablokowanych przez dostawcę obszarów całkowicie bezpłatnie z bardzo niewielką liczbą kontroli (często więc inżynierowie robią to od samego początku).
Przeniesienie do wersji testowej lub stabilnej wymaga przesłania przez dział prawny dokumentu, w którym wyraźnie stwierdza się, że LVFS może rozpowszechniać i analizować oprogramowanie układowe. Richard udostępnił plik PDF z wytycznymi. ● Jeśli dostawca jest tylko dostawcą komponentów półprzewodnikowych lub dostawcą OEM, może zostać „spółka zależną” producenta oryginalnego sprzętu i może przesyłać oprogramowanie układowe w jego imieniu, przy czym producent oryginalnego sprzętu ma pełną widoczność tego, co dzieje się z oprogramowaniem układowym oznaczonym jego nazwą.
Trzeba skonfigurować wiele innych rzeczy (np. identyfikator dostawcy ogranicza je do zbioru identyfikatorów PCI lub USB), ale większość dostawców ma już przypisany identyfikator i skonfigurowanie zajmuje 20 sekund.
Inne wskazówki – informacje dotyczące Chrome OS
W naszym przypadku binarne pliki aktualizacji oprogramowania nie są pobierane bezpośrednio z LVFS. Zamiast tego plik CAB zostanie zapisany w lokalnym systemie plików (rootfs).
- Przyszłe zadania: uwzględnij binarne oprogramowanie sprzętowe w DLC, tworząc ebuild portage na odpowiednim overlayu portage.
W odpowiednim momencie należy wywołać narzędzie wiersza poleceń fwupdtool. W przypadku każdego komponentu, który można aktualizować, należy utworzyć regułę udev (lub odpowiedni skrypt), która emituje zdarzenie fwuptool-update upstart. To zdarzenie zostanie obsłużone automatycznie, aby wykonać narzędzie fwupdtool z odpowiednimi argumentami i prawidłowym piaskownicą (minijail).
Kolejnym elementem jest decyzja, czy wymagane jest UI – tylko w pewnych okolicznościach, w zależności od charakteru aktualizowanego komponentu. Ocena przez zespół PM i Eng. Jak wspomniano w pierwszym kroku, ogólna wskazówka polega na minimalizowaniu działań po stronie użytkownika.
Dodatkowe materiały dla dostawców
Dokumentacja zewnętrzna: https://lvfs.readthedocs.io/
Informacje o umowach z zewnętrzymi dostawcami: fwupd.org/lvfs/docs/agreement
Samouczek dotyczący tworzenia wtyczek: https://fwupd.github.io/tutorial.html
Przewodnik po debugowaniu wtyczek: https://lvfs.readthedocs.io/en/latest/custom-plugin.html
Przykładowy plik quirk: https://github.com/fwupd/fwupd/blob/master/plugins/wacom-usb/wacom-usb.quirk
Historia zmian
| Data | Wersja | Uwagi |
|---|---|---|
| 2025-03-12 | 1.0.2 | Konwertowanie tekstu z pliku PDF na format Markdown |
| 2024-01-31 | 1.0.1 | Publikowanie ponownie na nowej platformie |
| 2023-10-12 | 1,0 | Pierwsza publikacja |