Udostępnij za pośrednictwem

Specyfikacja protokołu aktualizacji składnika oprogramowania układowego (CFU)

  • Artykuł

Ta specyfikacja opisuje ogólny protokół HID do aktualizowania oprogramowania układowego dla składników znajdujących się na komputerze lub akcesoriach. Specyfikacja umożliwia składnikowi akceptowanie oprogramowania układowego bez przerywania operacji urządzenia podczas pobierania. Specyfikacja obsługuje konfiguracje, w których składnik akceptujący oprogramowanie układowe może mieć podskładniki, które wymagają oddzielnych obrazów oprogramowania układowego. Specyfikacja umożliwia osobie odpowiedzialnej za komponent podjęcie decyzji, czy zaakceptować oprogramowanie układowe. Działa również jako optymalizacja, ponieważ obraz firmware'u jest wysyłany tylko do składnika, jeśli może go zaakceptować lub jest na to gotowy.

Notatka

CfU jest dostępny w systemie Windows 10 w wersji 2004 (Windows 10 maj 2020 Update) i nowszych wersjach.

Treść

Tabele

Tabela 5.1–1 Układ odpowiedzi na GET_FIRMWARE_VERSION

Tabela 5.1–2 Odpowiedź GET_FIRMWARE_VERSION — układ nagłówka

Tabela 5.1–3, odpowiedź „GET_FIRMWARE_VERSION” — nagłówkowe bity

Tabela 5.1-4: Odpowiedź GET_FIRMWARE_VERSION — wersja składnika i układ właściwości

Tabela 5.1-5 - Odpowiedź GET_FIRMWARE_VERSION - wersja komponentu i bity właściwości

Tabela 5.2-1 Układ polecenia FIRMWARE_UPDATE_OFFER

polecenie Table 5.2-2 FIRMWARE_UPDATE_OFFER — układ informacji o składniku

Polecenie Tabela 5.2-3 FIRMWARE_UPDATE_OFFER — bity informacji o składnikach

Tabela 5.2-4 Polecenie FIRMWARE_UPDATE_OFFER — układ wersji oprogramowania układowego

Table 5.2-5 FIRMWARE_UPDATE_OFFER Command — Bity wersji oprogramowania układowego

polecenie Table 5.2-6 FIRMWARE_UPDATE_OFFER — układ specyficzny dla dostawcy

polecenie Tabela 5.2-7 FIRMWARE_UPDATE_OFFER — różne tematy i wersja protokołu

Tabela 5.2-8 FIRMWARE_UPDATE_OFFER Układ tokenu odpowiedzi

Tabela 5.2-9 Odpowiedź FIRMWARE_UPDATE_OFFER — Układ tokenu

Odpowiedź Tabeli 5.2-10 FIRMWARE_UPDATE_OFFER — bity tokenu

Układ powodu odrzucenia odpowiedzi Tabela 5.2-11 FIRMWARE_UPDATE_OFFER

Tabela 5.2–12 FIRMWARE_UPDATE_OFFER — Bity Powodu Odrzucenia

Tabela 5.2-13 Odpowiedź FIRMWARE_UPDATE_OFFER wartości kodu RR

Tabela 5.2-14 FIRMWARE_UPDATE_OFFER Układ statusu odpowiedzi

Odpowiedź Table 5.2-15 FIRMWARE_UPDATE_OFFER — bity stanu

tabela 5.2–16 FIRMWARE_UPDATE_OFFER wartości stanu odpowiedzi

Tabela 5.3-1 FIRMWARE_UPDATE_OFFER — układ poleceń informacji

Table 5.3-2 FIRMWARE_UPDATE_OFFER — Information Command — Component Layout

Table 5.3-3 FIRMWARE_UPDATE_OFFER — Information Command — Component Bits

Tabela 5.3-4 FIRMWARE_UPDATE_OFFER — polecenie informacyjne — wartości kodu informacji

Tabela 5.3–5 FIRMWARE_UPDATE_OFFER — układ odpowiedzi na informacje

tabela 5.3-6 FIRMWARE_UPDATE_OFFER — układ tokenu odpowiedzi pakietu informacyjnego

Tabela 5.3-7 FIRMWARE_UPDATE_OFFER — informacyjna odpowiedź — bity tokenu

Tabela 5.3-8 FIRMWARE_UPDATE_OFFER — Odpowiedź na informacje — układ kodu RR

Tabela 5.3-9 FIRMWARE_UPDATE_OFFER — odpowiedź na informacje o ofercie — bity kodu RR

Tabela 5.3-10 FIRMWARE_UPDATE_OFFER — Informacyjna odpowiedź — Wartości kodu RR

Tabela 5.3-11 FIRMWARE_UPDATE_OFFER — format statusu odpowiedzi dotyczącej informacji o ofercie

Tabela 5.3-12 FIRMWARE_UPDATE_OFFER — Informacje o Ofercie — Bity Stanu Odpowiedzi

Tabela 5.4-1 FIRMWARE_UPDATE_OFFER — rozszerzony układ poleceń

Table 5.4-2 FIRMWARE_UPDATE_OFFER — rozszerzony pakiet poleceń — polecenie — układ składników

Tabela 5.4-3 FIRMWARE_UPDATE_OFFER — Rozszerzone polecenie — bity składników

Tabela 5.4-4 FIRMWARE_UPDATE_OFFER — rozszerzone polecenie — wartości kodu polecenia

Tabela 5.4-5 FIRMWARE_UPDATE_OFFER — rozszerzony układ odpowiedzi pakietów poleceń

Tabela 5.4-6 FIRMWARE_UPDATE_OFFER — oferowanie odpowiedzi na pakiety poleceń — układ tokenu

Tabela 5.4-7 FIRMWARE_UPDATE_OFFER — odpowiedź na polecenie oferty — bity tokena

Tabela 5.4-8 FIRMWARE_UPDATE_OFFER — układ odpowiedzi RR na pakiet informacyjny

Tabela 5.4-9 FIRMWARE_UPDATE_OFFER — odpowiedź na polecenie oferty — kod RR

Tabela 5.4-10 FIRMWARE_UPDATE_OFFER — Pakiet poleceń oferty — Wartości kodu RR

Tabela 5.4-11 FIRMWARE_UPDATE_OFFER - Układ Statusu Odpowiedzi Pakietu Polecenia Oferty

Tabela 5.4-12 FIRMWARE_UPDATE_OFFER — kod RR odpowiedzi na polecenie oferowania pakietu

Tabela 5.5-1 FIRMWARE_UPDATE_CONTENT Układ poleceń

Tabela 5.5-2 FIRMWARE_UPDATE_CONTENT Układ nagłówka komendy

Tabela 5.5-3 Bity nagłówka FIRMWARE_UPDATE_CONTENT

Tabela 5.5-4 FIRMWARE_UPDATE_OFFER — pakiet poleceń oferty — wartości flagi

Tabela 5.5-5 FIRMWARE_UPDATE_CONTENT Układ danych poleceń

Tabela 5.5-6 Bity danych polecenia FIRMWARE_UPDATE_CONTENT

Tabela 5.5-7 FIRMWARE_UPDATE_CONTENT Układ odpowiedzi polecenia

Tabela 5.5-8 Odpowiedź FIRMWARE_UPDATE_CONTENT — numer sekwencji

Tabela 5.5-9 FIRMWARE_UPDATE_CONTENT — polecenie — bity odpowiedzi

Tabela 5.5-10 FIRMWARE_UPDATE_CONTENT Układ stanu odpowiedzi

Tabela 5.5-11 FIRMWARE_UPDATE_OFFER — Odpowiedź — Bity stanu

tabela 5.5-12 FIRMWARE_UPDATE_OFFER — odpowiedź — wartości kodu stanu

1 Wprowadzenie

Dzisiejsze komputery i akcesoria mają składniki wewnętrzne, które wykonują złożone operacje. Aby zapewnić jakość produktu, należy często aktualizować zachowanie tych urządzeń w późniejszych etapach opracowywania lub po ich wysłaniu do klientów. Aktualizacja może rozwiązać zidentyfikowane problemy z funkcjonalnością lub zabezpieczeniami lub konieczność dodania nowych funkcji. Duża część złożonej logiki znajduje się w oprogramowaniu układowym uruchomionym na urządzeniu, które można aktualizować.

Ta specyfikacja opisuje ogólny protokół HID w celu zaktualizowania oprogramowania układowego dla składników znajdujących się na komputerze lub jego akcesoriach. Implementacja HID wykracza poza zakres specyfikacji.

Oto niektóre funkcje protokołu:

  • Protokół jest oparty na protokole HID — wszechobecny i ma obsługę w pudełku systemu Windows w różnych magistralach połączeń, takich jak USB i I2C. W związku z tym można użyć tego samego rozwiązania oprogramowania (sterownika), aby zaktualizować oprogramowanie układowe dla wszystkich składników.

    Notatka

    Ponieważ specyfikacja jest oparta na pakietach, proste jest dostosowanie jej do scenariuszy innych niż HID.

  • Specyfikacja umożliwia składnikowi akceptowanie oprogramowania układowego bez przerywania operacji urządzenia podczas pobierania. Umożliwia to użytkownikom lepsze środowisko pracy, ponieważ nie muszą czekać na ukończenie procesu aktualizacji oprogramowania układowego, zanim będą mogli wznowić inne zadania. Nowe oprogramowanie układowe może być wywoływane w jednej nieprzerwanej operacji w momencie, który minimalnie wpływa na użytkownika.

  • Specyfikacja obsługuje konfiguracje, w których składnik akceptujący oprogramowanie układowe może mieć podskładniki, które wymagają oddzielnych obrazów oprogramowania układowego.

    Nota

    Proces przekazywania oprogramowania układowego do podskładniku wykracza poza zakres tej specyfikacji.

  • Specyfikacja obsługuje koncepcję oferty i polega na komponencie odpowiedzialnym za decyzję, czy zaakceptować "firmware". Decyzja o zaakceptowaniu nowego oprogramowania układowego nie jest banalna. Mogą istnieć zależności między typem oprogramowania układowego i/lub wersją oraz bazowym typem/wersją sprzętu, do którego stosuje się nowe oprogramowanie układowe. Oferta działa również jako mechanizm optymalizacji, ponieważ obraz oprogramowania układowego jest wysyłany do składnika tylko wtedy, gdy jest w stanie lub gotowy go zaakceptować.

1.1 Słownik

Termin Opis
Identyfikator składnika W urządzeniu z wieloma składnikami identyfikator składnika jednoznacznie identyfikuje każdy składnik.
CRC Sprawdzanie nadmiarowości cyklicznej

Niekryptograficzny algorytm haszujący używany do tworzenia skrótu lub odcisku palca bloku danych. CRC jest używany jako kontrola w celu zapewnienia, że blok danych nie uległ zmianie od czasu obliczenia CRC. CRC nie jest niezawodny, ale daje pewność, że dane zostały odebrane poprawnie.
Urządzenie Kolekcja składników (jeden składnik podstawowy i zero lub więcej podskładników). Urządzenie jest widoczne dla systemu operacyjnego jako pojedyncza jednostka. Host wchodzi w interakcję z urządzeniem, który jest zazwyczaj składnikiem podstawowym.

Na komputerze może znajdować się wiele urządzeń. W odniesieniu do tej specyfikacji komunikacja z 2 różnymi urządzeniami jest całkowicie niezależna.
Kierowca Sterownik napisany przy użyciu struktury Windows Driver Foundation (WDF).
Oprogramowanie układowe Kod uruchomiony na sprzęcie fizycznym. Oprogramowanie układowe można aktualizować i zwykle znajduje się w programowalnej pamięci skojarzonej ze sprzętem.
Sprzęt Fizyczny kawałek krzemu na komputerze.
Składnik podstawowy Element sprzętowy w komputerze i oprogramowanie układowe dla niego. W kontekście tej specyfikacji składnik jest jednostką, która potrzebuje i akceptuje aktualizację oprogramowania układowego.
Segment Obraz oprogramowania układowego składnika może być podzielony na mniejsze segmenty. Każdy segment to mały obraz oprogramowania układowego.
Identyfikator segmentu Jeśli oprogramowanie układowe składnika jest podzielone na mniejsze segmenty, ID segmentu jest jego unikatowym identyfikatorem.
Podpis Kryptograficzny sposób określania, czy obraz oprogramowania układowego został zmieniony w sposób nieautoryzowany. Podpisy są opcjonalne, ale zalecane i wykraczają poza zakres tej specyfikacji.
Podskładnik W zależności od architektury sprzętu nie wszystkie składniki mogą być widoczne dla systemu operacyjnego, ponieważ mogą być połączone podrzędnie składnika widocznego dla systemu. Te składniki są określane jako podskładniki w tej specyfikacji.
TLC Kolekcja HID najwyższego poziomu.
Żeton Identyfikator sesji hosta. Host tworzy token i wysyła go w poleceniach, a urządzenie zwraca je w odpowiedzi. Tokeny mogą służyć do serializacji niektórych transakcji lub identyfikowania, że sesja została utracona, a inna rozpoczęta.

Zakres 1.2

1.2.1 Cele

  • Rozwiązanie niezależne od magistrali jest wymagane, aby uniknąć nowego protokołu dla każdego typu magistrali. HID jest wszechobecny i odpowiada na to wymaganie.

  • Możliwość obsługi aktualizacji oprogramowania układowego dla urządzenia wieloskładnikowego, w którym jeden składnik działa jako składnik podstawowy, a inne są podskładnikami połączonymi ze składnikiem podstawowym. Każdy składnik wymaga własnego oprogramowania układowego z nietrygalnymi zależnościami między sobą.

  • Wspólny model sterowników do pobierania obrazu oprogramowania układowego do składnika. Następnie składnik posiada algorytmy przekazywania specyficzne dla podskładników. Podskładniki mogą również przeprowadzać kontrole poprawności oprogramowania układowego i przekazywać wyniki z powrotem do podstawowego składnika.

  • Możliwość obsługi aktualizacji oprogramowania układowego, gdy trwa operacja urządzenia.

  • Możliwość aktualizacji lub wycofywania oprogramowania układowego na urządzeniach produkcyjnych za pomocą autoryzowanych narzędzi, oraz aktualizacji urządzeń użytkowych za pośrednictwem usługi Windows Update.

  • Elastyczność wspierania oprogramowania układowego w trakcie rozwoju/oprogramowania układowego obecnego na rynku.

  • Możliwość segmentowania dużego obrazu oprogramowania układowego w mniejsze segmenty, aby ułatwić składnikowi akceptowanie obrazu oprogramowania układowego.

1.2.2 Cele wykluczone

  • Określ wewnętrzny format obrazu oprogramowania układowego: dla hosta obraz oprogramowania układowego jest zestawem wpisów adresowych i dotyczących zawartości.

  • Podpisywanie/szyfrowanie/weryfikowanie zaakceptowanego oprogramowania układowego: ta specyfikacja nie opisuje sposobu podpisywania i szyfrowania obrazów oprogramowania układowego. Wymagane jest, aby oczekiwane bieżące oprogramowanie układowe uruchomione w składniku weryfikowało pobierane oprogramowanie układowe.

  • Zdefiniuj mechanizm interakcji składnika z podskładnikami: Host współdziała z urządzeniem jako pojedynczą jednostką, zazwyczaj podstawowym składnikiem. Składnik musi działać jako mostek do komunikacji związanej z oprogramowaniem układowym podskładnikowym.

2 Obsługiwane architektury sprzętowe

Aby obsługiwać elastyczny projekt sprzętu, protokół obsługuje urządzenie wieloskładnikowe, w którym każdy składnik wymaga własnego obrazu oprogramowania układowego. W projekcie jeden składnik jest składnikiem podstawowym, a zależne podskładniki są połączone z tym składnikiem podstawowym. Każdy składnik jest jednoznacznie opisany przez identyfikator składnika.

Urządzenie wieloskładnikowe jest widoczne dla systemu operacyjnego jako pojedyncza jednostka. Host wchodzi w interakcję tylko z urządzeniem, zazwyczaj głównym komponentem, przy wykorzystaniu tego protokołu CFU. Komunikacja między składnikiem a jego podskładnikami wykracza poza zakres tej specyfikacji.

Na komputerze może istnieć wiele różnych urządzeń (gdzie urządzenie może mieć co najmniej jeden składnik). W kontekście tego protokołu komunikacja z każdym urządzeniem jest niezależna. Każde urządzenie ma odpowiednie wystąpienie hosta.

oprogramowanie układowe urządzenia, podstawowy składnik i jego składniki podrzędne.

3 Wymagania wstępne protokołu

W tej sekcji wymieniono wymagania wstępne i najlepsze praktyki, które należy zaimplementować w celu wykorzystania tego protokołu.

  • Użycie obrazu atomowego

    Obraz oprogramowania układowego składnika nie jest używany, dopóki nie zostanie pomyślnie pobrany w całości. Jeśli oprogramowanie układowe jest podzielone na wiele segmentów, obraz nie może być używany do momentu odebrania końcowego segmentu od nadawcy. Należy przeprowadzić kontrole integralności na końcowym obrazie. Zaleca się, aby transport, używany do dostarczania obrazu oprogramowania układowego, miał mechanizmy poprawiania błędów i ponawiania prób, aby uniknąć powtarzania pobierania w przypadku błędów transportu.

  • Aktualizacja oprogramowania układowego nie może przerywać operacji urządzenia

    Urządzenie akceptujące obraz oprogramowania układowego musi być w stanie działać podczas aktualizacji. Urządzenie musi mieć dodatkową pamięć do przechowywania i weryfikowania przychodzącego oprogramowania układowego, bez zastępowania jego bieżącego oprogramowania układowego.

  • Uwierzytelnianie i integralność

    Implementator decyduje, jakie czynniki tworzą oryginalny obraz oprogramowania układowego. Zaleca się, aby bieżące oprogramowanie układowe składnika przynajmniej zweryfikowało CRC przychodzącego obrazu oprogramowania układowego. Bieżące oprogramowanie układowe powinno również używać podpisu cyfrowego lub innych algorytmów wykrywania błędów. Jeśli walidacja zakończy się niepowodzeniem, oprogramowanie układowe odrzuci aktualizację. Odzyskiwanie po awarii

    Jeśli obraz oprogramowania układowego zostanie pobrany i nie powiedzie się, urządzenie nie może wywołać nowego oprogramowania układowego i kontynuować pracę z istniejącym oprogramowaniem układowym. Host może ponowić próbę aktualizacji. Częstotliwość ponawiania jest specyficzna dla implementacji.

  • Poufność

    Fakultatywny. Segment oprogramowania układowego może być zaszyfrowany. Techniki szyfrowania i odszyfrowywania wykraczają poza zakres tej specyfikacji. Ta specyfikacja traktuje ładunek oprogramowania układowego jako strumień danych, niezależnie od tego, czy jest zaszyfrowany.

  • Ochrona wycofywania

    Zasady wycofywania są wymuszane przez składnik podstawowy i są specyficzne dla implementacji. Bieżące oprogramowanie układowe w składniku weryfikuje przychodzące obrazy oprogramowania układowego względem zasad wewnętrznych, takich jak konieczność nowszego numeru wersji czy brak możliwości zmiany typu wydania z release na debug itd. Protokół zezwala na przesyłanie komunikatów, aby wskazać, że aktualizacja jest akceptowana, nawet jeśli narusza zasady wycofywania.

4 Omówienie protokołu CFU

Protokół CFU to zestaw poleceń i odpowiedzi, które są wymagane do wysyłania nowych obrazów oprogramowania układowego z hosta do urządzenia, dla którego jest przeznaczone oprogramowanie układowe.

Na poziomie ogólnym protokół iteruje przez wszystkie pliki oprogramowania układowego przeznaczone do wysłania do urządzenia. Dla każdego obrazu oprogramowania układowego host oferuje do wysłania pliku na urządzenie. Tylko wtedy, gdy urządzenie zaakceptuje ofertę, host wyśle plik.

W przypadku obsługi przypadków, w których kolejność aktualizacji urządzenia ma zależności, urządzenie może nie akceptować niektórych ofert w pierwszym przebiegu, dlatego protokół umożliwia hostowi ponowne wysyłanie wszystkich ofert oprogramowania układowego do urządzenia do momentu rozwiązania wszystkich zależności.

4.1. Sekwencja poleceń programowania aktualizacji oprogramowania układowego

Oto sekwencja poleceń CFU do aktualizowania obrazu oprogramowania układowego.

sekwencja poleceń do programowania aktualizacji firmware.

4.1.1 Stan: Powiadomienie zainicjowane przez hosta

Po zainicjowaniu hosta i zidentyfikowaniu zestawu ofert, które musi wysłać do urządzenia, host wydaje polecenie OFFER_INFO_START_ENTIRE_TRANSACTION, aby wskazać składnikowi, że host jest teraz zainicjowany. Celem tego polecenia jest powiadomienie bieżącego oprogramowania układowego urządzenia o dostępności nowej instancji hosta. To powiadomienie jest przydatne, gdy poprzednie wystąpienie hosta zostanie nieoczekiwanie zakończone. Urządzenie musi pomyślnie ukończyć to polecenie.

4.1.2 Stan: OFFER_INFO_START_OFFER_LIST Powiadomienie

W tym stanie host wysyła polecenie OFFER_INFO_START_OFFER_LIST, aby wskazać, że jest gotowy do wysłania ofert(y) do oprogramowania układowego aktualnego urządzenia. Podstawowy składnik urządzenia musi ukończyć tę komendę z powodzeniem.

To polecenie jest przydatne, ponieważ host może wysyłać wszystkie oferty do urządzenia więcej niż raz.

4.1.3 Stan: Wyślij polecenie FIRMWARE_UPDATE_OFFER

Host wysyła ofertę do składnika podstawowego (lub jego podskładnika), aby sprawdzić, czy składnik chce zaakceptować/odrzucić oprogramowanie układowe. Oferta zawiera wszystkie niezbędne metadane dotyczące obrazu oprogramowania układowego, dzięki czemu bieżące oprogramowanie na składniku może zdecydować, czy zaakceptować, wstrzymać, pominąć lub odrzucić ofertę.

Oferta może być dla podstawowego składnika lub podskładniku. Jeśli składnik może zaakceptować ofertę, przygotowuje się do otrzymania oprogramowania układowego. Może to obejmować przygotowanie banku pamięci do odbierania przychodzącego obrazu oprogramowania układowego. Składnik może nie zaakceptować oferty, na przykład składnik może mieć już nowszą (lub tę samą) wersję oprogramowania układowego, którą ma wysłać host. Po więcej informacji, patrz przykłady opisane w Dodatku 1: Przykład sekwencji poleceń programowania aktualizacji oprogramowania układowego.

Nawet jeśli oferta zostanie zaakceptowana, główna jednostka może nadal odrzucić obraz oprogramowania układowego po pobraniu z powodu niepowodzenia weryfikacji integralności i/lub kontroli cofnięcia względem rzeczywiście odebranego obrazu. Składnik musi sprawdzić każdą właściwość obrazu firmware niezależnie od informacji zawartych w ofercie.

Host wysyła polecenie FIRMWARE_UPDATE_OFFER w celu powiadomienia głównego składnika o obrazie oprogramowania układowego, który host ma wysłać.

Jeśli składnik akceptuje ofertę, zmienia swój status na FIRMWARE_UPDATE_OFFER_ACCEPT, tym samym akceptując ofertę.

Jeśli oprogramowanie układowe urządzenia jest zajęte i podstawowy składnik nie może aktualnie zaakceptować tej ani następnej oferty, wysyła odpowiedź zajętościową ze stanem FIRMWARE_UPDATE_OFFER_BUSY.

Jeśli bieżące oprogramowanie układowe jest zainteresowane ofertą, jednak nie może zaakceptować oferty (na przykład ze względu na zależność od brakującej aktualizacji dla podskładnika) odpowiada z FIRMWARE_UPDATE_OFFER_SKIP wskazującą, że jest zainteresowany tym oprogramowaniem układowym, ale nie może go zaakceptować. Następnie host przechodzi do następnej oferty i musi zaoferować ponownie to firmware później.

Jeśli bieżące oprogramowanie układowe nie jest zainteresowane ofertą (na przykład jest to starsza wersja), odpowiada za pomocą stanu FIRMWARE_UPDATE_OFFER_REJECT, podając odpowiedni powód odrzucenia. Ten stan nie wskazuje, że host nie może ponownie wysłać tej oferty w przyszłości. Host zazwyczaj wysyła każdą ofertę za każdym razem, gdy inicjuje lub ponownie wysyła listę ofert do urządzenia (zobacz Stan: OFFER_INFO_START_OFFER_LIST Powiadomienie).

4.1.4 Stan: Wyślij oprogramowanie układowe

W tym stanie host rozpoczyna wysyłanie obrazu oprogramowania układowego do podstawowego składnika, dla którego składnik wcześniej zaakceptował ofertę.

Ponieważ zawartość obrazu oprogramowania układowego prawdopodobnie przekracza limity ładowności pojedynczego polecenia, host dzieli obrazy oprogramowania układowego na pakiety. Host wysyła każdy pakiet sekwencyjnie w osobnym poleceniu FIRMWARE_UPDATE CONTENT. Składnik podstawowy musi wygenerować pakiet odpowiedzi dla każdego polecenia.

Każde polecenie FIRMWARE_UPDATE CONTENT opisuje adres przesunięcia zawierający częściowy ładunek oprogramowania układowego. Składnik używa przesunięcia, aby określić adres, w którym musi być przechowywany częściowy ładunek oprogramowania układowego. Urządzenie zapisuje zawartość w odpowiedniej lokalizacji i potwierdza polecenie, wysyłając odpowiedź.

W przypadku pierwszego pakietu wysyłanego przez hosta ustawia flagę FIRMWARE_UPDATE_FLAG_FIRST_BLOCK wskazującą na urządzenie, że jest to pierwszy pakiet obrazu oprogramowania układowego. Jeśli urządzenie nie zostało jeszcze przygotowane do odbierania oprogramowania układowego, może to zrobić w tej chwili.

Dla ostatniego pakietu host wysyła go i ustawia flagę FIRMWARE_UPDATE_FLAG_LAST_BLOCK.

Po zapisaniu na urządzeniu bieżącego oprogramowania układowego częściowego ładunku oprogramowania układowego zawartego w tym poleceniu musi przeprowadzić sprawdzanie poprawności i uwierzytelniania na przychodzącym obrazie oprogramowania układowego przed wysłaniem odpowiedzi. Obejmuje to co najmniej:

  • Sprawdzanie CRC w celu zweryfikowania integralności całego obrazu oprogramowania układowego.

  • Jeśli sprawdzanie CRC powiedzie się, opcjonalna weryfikacja podpisu obrazu przychodzącego.

  • Po opcjonalnym sprawdzeniu podpisu należy przeprowadzić kontrolę wersji, aby upewnić się, że nowa wersja oprogramowania układowego jest taka sama lub nowsza niż istniejąca wersja.

W przypadku, gdy przychodzący obraz oprogramowania układowego został podzielony na mniejsze segmenty, do bieżącego oprogramowania układowego należy określić, czy jest to ostatni segment obrazu oprogramowania układowego, a następnie dołącz wszystkie segmenty w ramach walidacji.

Jeśli powyższe testy przejdą, bieżące oprogramowanie układowe może skonfigurować urządzenie do zamiany na nowy obraz przy następnym zresetowaniu i zgłosi powodzenie na hoście. Zazwyczaj składnik nie inicjuje samodzielnego resetowania. Ma to na celu zapobieganie zakłóceniom w dowolnym oprogramowaniu, oprogramowaniu układowym, jednostkach sprzętowych, z którymi współdziała składnik. Nie jest to jednak wymagane i może się różnić w zależności od implementacji.

Jeśli kroki weryfikacji nie powiodą się, oprogramowanie układowe nie powinno skonfigurować zamiany podczas następnego resetowania i musi wskazać błąd odpowiedzi do hosta.

4.1.5 Stan decyzji: Czy jest więcej ofert

W tym stanie host określa, czy istnieją jeszcze oferty do wysłania do urządzenia.

4.1.6 Stan: OFFER_INFO_END_OFFER_LIST Powiadomienie

Ten stan jest osiągany, gdy host wysłał wszystkie oferty do podstawowego składnika w bieżącym oprogramowaniu układowym urządzenia. Serwer wysyła polecenie OFFER_INFO_END_OFFER_LIST, aby wskazać, że wysłał wszystkie oferty do komponentu.

Urządzenie musi ukończyć to polecenie z powodzeniem.

4.1.7 Stan decyzji: Lista ofert odtwarzania

Host określa, czy musi ponownie wysłać wszystkie oferty. Ten przypadek może wystąpić, jeśli wcześniej podstawowy składnik pominął niektóre oferty i zaakceptował niektóre oferty. Gospodarz musi ponownie odtworzyć listę ofert.

Może istnieć inna logika specyficzna dla implementacji, która może spowodować decyzję o ponownym odtworzeniu listy ofert.

4.1.8 Stan: Urządzenie jest zajęte

Ten stan oznacza, że urządzenie zwróciło zajętą odpowiedź na ofertę.

Host wysyła polecenie OFFER_NOTIFY_ON_READY, do którego urządzenie nie odpowiada z akceptacją, dopóki urządzenie nie będzie wolne.

5 Format pakietów protokołu CFU

Protokół CFU jest implementowany jako zestaw poleceń i odpowiedzi. Protokół jest sekwencyjny w naturze. Dla każdego polecenia, które host wysyła do składnika, oczekuje się, że składnik odpowie (chyba że jawnie określono inaczej w tej specyfikacji). Host nie wysyła kolejnego polecenia, dopóki nie zostanie odebrana prawidłowa odpowiedź dla poprzedniego wysłanego polecenia.

Jeśli składnik nie odpowiada w danym okresie lub wysyła nieprawidłową odpowiedź, host może ponownie uruchomić proces od początku. Ten protokół nie definiuje określonej wartości limitu czasu.

Istnieją polecenia umożliwiające uzyskanie informacji o wersji bieżącego oprogramowania układowego w składniku, wysłanie oferty i przesłanie obrazu oprogramowania układowego.

Jednak gospodarz systemu nie musi wstrzymać oferty na podstawie odpowiedzi otrzymanej od głównego składnika na temat informacji o wersji, o którą zapytano. Informacje te są wykrywalne na potrzeby rejestrowania lub innych celów.

5.1 POBIERZ_WERSJĘ_FIRMWARE

Pobiera bieżące wersje oprogramowania układowego podstawowego składnika (i jego podskładniki). Polecenie nie ma żadnych argumentów.

5.1.1 Polecenie

To polecenie jest wysyłane przez hosta w celu uzyskania informacji o wersjach aktualnego oprogramowania układowego w składniku podstawowym (i jego podskładnikach). Host może używać go do potwierdzenia, czy oprogramowanie układowe zostało pomyślnie zaktualizowane. Po otrzymaniu tego polecenia podstawowy składnik odpowiada wersją oprogramowania układowego dla siebie i wszystkich podkomponentów.

5.1.2 Odpowiedź

Składnik odpowiada, podając wersję oprogramowania układowego zarówno podstawowego składnika, jak i podskładników. Rozmiar odpowiedzi to 60 bajtów, co umożliwia uzyskanie informacji o wersji dla maksymalnie siedmiu składników (jeden podstawowy i maksymalnie sześć podskładników).

Tabela 5.1–1 GET_FIRMWARE_VERSION Układ odpowiedzi

GET_FIRMWARE_VERSION układ odpowiedzi.

Nagłówek 5.1.2.1
Tabela 5.1–2 odpowiedź GET_FIRMWARE_VERSION — układ nagłówka

GET_FIRMWARE_VERSION Odpowiedź — układ nagłówka.

Nagłówek odpowiedzi zawiera następujące informacje.

Tabela 5.1-3: Odpowiedź GET_FIRMWARE_VERSION — bity nagłówka
Przesunięcie bitowe Pole Rozmiar Opis
0 Liczba składników 8 Liczba składników do pobrania zarządzanych za pomocą tego mechanizmu dla tego składnika. Liczba składników określa maksymalny rozmiar tabeli. Obecnie obsługiwane są maksymalnie 7 składników, aby upewnić się, że odpowiedź może mieścić się w dozwolonych 60 bajtach.
8 Rsvd 16 Pola zarezerwowane. Nadawca musi ustawić te wartości na 0. Odbiorca musi zignorować tę wartość.
24 Wersja protokołu 4 Bity rewizji aktualizacji oprogramowania układowego reprezentują rewizję protokołu aktualizacji oprogramowania układowego, która jest obecnie używana w transporcie. W przypadku interfejsu zdefiniowanego w niniejszym dokumencie wersja aktualizacji FW musi być 0010b.
28 Rsvd 3 Pola zarezerwowane. Nadawca musi ustawić te wartości na 0. Odbiorca musi zignorować tę wartość.
31 E 1 Flaga rozszerzenia to przyszły punkt zaczepienia protokołu umożliwiający raportowanie dodatkowych składników.
5.1.2.2, wersja i właściwości składnika

Dla każdego składnika używa się dwóch DWORD-ów do opisania jego właściwości, przy maksymalnie 7 składnikach. Jeśli liczba składników w nagłówku jest mniejsza niż 7, nieużywane DWORDS na końcu odpowiedzi musi być ustawiona na 0.

Tabela 5.1–4, odpowiedź na GET_FIRMWARE_VERSION — układ wersji i właściwości składnika

GET_FIRMWARE_VERSION odpowiedź — wersja składnika i układ właściwości.

Informacje specyficzne dla każdego składnika są opisane w dwóch DWORDach w następujący sposób:

Tabela 5.1–5 odpowiedź GET_FIRMWARE_VERSION — wersje składników i bity właściwości
Przesunięcie bitowe Pole Rozmiar Opis
0 Wersja oprogramowania układowego 32 Zwraca wersję bieżącego oprogramowania układowego dla tego składnika. Ta specyfikacja nie nakazuje żadnego określonego formatu dla wersji oprogramowania układowego. Zobacz sekcję Wersja firmware dla wskazówek.
32 Bank 2 Fakultatywny. W zależności od architektury, komponenty sprzętowe mogą mieć wiele banków, w których może być przechowywane oprogramowanie układowe. W zależności od implementacji nadawca może określić bank, w którym obecnie istnieje oprogramowanie układowe. To pole jest obowiązkowe warunkowo — wsparcie jest opcjonalne, ale nie może być używane do żadnego innego celu.
34 Zastrzeżony 2 Pola zarezerwowane. Nadawca musi ustawić je na 0. Odbiorca musi zignorować tę wartość.
36 Specyficzne dla dostawcy 4 Pole specyficzne dla dostawcy, które może być używane w sposób specyficzny dla implementacji.

Dostawca może użyć tych bitów do zakodowania informacji, takich jak:

- Typ oprogramowania układowego: Wersja wstępna/samodzielna/produkcja; debugowanie/sprzedaż detaliczna

- Faza programowania

— Identyfikator produktu, aby uniemożliwić składnikom odbieranie oprogramowania układowego dla innych produktów przy użyciu tego samego protokołu aktualizacji.
40 Identyfikator składnika 8 Unikatowy identyfikator składnika.
48 Specyficzne dla dostawcy 16 Pole specyficzne dla dostawcy, które może być używane w sposób specyficzny dla implementacji.

5.1.3 Mapowanie na HID

Jest to realizowane jako żądanie HID Get Feature z rozmiarem odpowiedzi wynoszącym 60 bajtów, oprócz identyfikatora raportu. Długość raportu funkcji uwzględnia całą odpowiedź GET_FIRMWARE_VERSION. Brak danych skojarzonych z żądaniem Pobierania funkcji z hosta.

5.2 OFERTA_AKTUALIZACJI_FIRMWARE

Określa, czy podstawowy składnik akceptuje lub odrzuca oprogramowanie układowe.

5.2.1 Polecenie

Host wysyła to polecenie do składnika, aby określić, czy akceptuje lub odrzuca oprogramowanie układowe. Host musi wysłać ofertę, a składnik musi zaakceptować ofertę, zanim host będzie mógł wysłać oprogramowanie układowe.

Pakiet polecenia FIRMWARE_UPDATE_OFFER jest zdefiniowany w następujący sposób.

Tabela 5.2-1 FIRMWARE_UPDATE_OFFER Układ poleceń

FIRMWARE_UPDATE_OFFER układ poleceń.

5.2.1.1 Informacje o składniku
Tabela 5.2–2 — polecenie FIRMWARE_UPDATE_OFFER — układ informacji o składniku

FIRMWARE_UPDATE_OFFER Polecenie — struktura informacji o składniku.

Bity bajtu Informacje o składniku zostały opisane w tej tabeli.

Tabela 5.2-3 polecenie FIRMWARE_UPDATE_OFFER — bity informacji dotyczące składnika
Przesunięcie bitowe Pole Rozmiar Opis
0 Numer segmentu 8 To pole jest używane w przypadku, gdy oprogramowanie układowe składnika jest podzielone na mniejsze segmenty. Jeśli jest używana, ta wartość wskazuje segment, który znajduje się w kolejnym pakiecie ładunku. Na przykład — jeśli obraz układowego oprogramowania składnika jest bardzo duży, a podstawowy składnik może przetwarzać tylko mniejsze części obrazu naraz, to pole może służyć do wskazania, że ta oferta dotyczy -tego i-szego segmentu kompletnego obrazu. Oddzielna oferta może zostać wysłana do głównego komponentu zawierającego ioraz kolejny segment obrazu, itd.
8 Zastrzeżony 6 Pola zarezerwowane. Nadawca musi ustawić te wartości na 0. Odbiorca musi zignorować tę wartość.
14 Ja 1 Wymuś natychmiastowe resetowanie (I)

— Ta wartość bitowa służy do wskazania komponentowi, aby natychmiast zresetować się po zakończeniu pobierania oprogramowania układowego i jego weryfikacji, aby bez zwłoki je uruchomić.

— Ta flaga jest przeznaczona do fazy opracowywania.
15 V 1 Wymuszanie ignorowania wersji (V)

— Ta flaga jest przeznaczona dla obrazu wstępnego wydania lub debugowania oprogramowania układowego. Zaleca, aby składnik nie odrzucał oprogramowania układowego ze względu na jego wersję.

— Ta flaga jest przeznaczona do fazy opracowywania. Może służyć do celowego wycofywania do wcześniejszej wersji oprogramowania układowego.

— Ta flaga powinna być ignorowana przez oprogramowanie układowe produkcyjne.
16 Identyfikator składnika 8 Ten bajt jest używany w scenariuszach obejmujących wiele składników. To pole może służyć do identyfikowania podskładu, dla którego jest przeznaczona oferta. Jeśli wartość nie jest używana, powinna wynosić 0. Możliwe wartości identyfikatorów składników są następujące:

1 — 0xDF: Prawidłowe

0xE0 — 0xFD: zarezerwowane. Nie używaj.

0xFF: Oferta jest specjalnym pakietem informacyjnym dotyczącym oferty specjalnej. Aby uzyskać szczegółowe informacje, zobacz informacje o FIRMWARE_UPDATE_OFFER.

0xFE: Jest to specjalny pakiet poleceń ofertowych. Aby uzyskać szczegółowe informacje, zobacz sekcję rozszerzoną FIRMWARE_UPDATE_OFFER.
24 Żeton 8 Host wstawia unikatowy token w pakiecie oferty dla składnika. Ten token musi zostać zwrócony przez składnik w odpowiedzi na ofertę.

Jest to przydatne, jeśli istnieje potrzeba, aby składnik rozróżniał różne hosty/typy hostów.

Dokładne wartości do użycia są specyficzne dla implementacji. Na przykład jedna wartość może być używana dla sterownika i innej dla aplikacji. Dzięki temu bieżące oprogramowanie układowe urządzenia może uwzględniać potencjalnych nadawców poleceń CFU. Jedną z możliwych implementacji może być zaakceptowanie pierwszego polecenia CFU i odrzucenie wszystkich innych poleceń z różnymi tokenami do momentu ukończenia pierwszych transakcji CFU.
5.2.1.2 Wersja oprogramowania układowego

Te cztery bajty reprezentują 32-bitową wersję oprogramowania układowego. Format wersji oprogramowania układowego nie jest wymagany przez tę specyfikację. Zalecane jest wykonanie poniższych czynności.

Tabela 5.2-4 — polecenie FIRMWARE_UPDATE_OFFER — schemat wersji firmware'u

FIRMWARE_UPDATE_OFFER Polecenie — układ wersji firmware'u.

Format wersji oprogramowania układowego nie jest wymagany przez tę specyfikację, jednak poniżej przedstawiono zalecane wytyczne.

Tabela 5.2-5 polecenie FIRMWARE_UPDATE_OFFER – bity wersji firmware’u
Przesunięcie bitowe Pole Rozmiar Opis
0 Wariant 8 To pole można opisać, aby odróżniać wersję firmware przedpremierową od wersji produkcyjnej firmware. Może to wskazywać typ podpisu używanego do podpisywania oprogramowania układowego.
8 Wersja pomocnicza 16 Ta wartość pola powinna być aktualizowana dla każdej kompilacji oprogramowania układowego.

Ta wartość pola powinna być aktualizowana dla każdej kompilacji oprogramowania układowego.
24 Wersja główna 8 To pole jest główną wersją obrazu oprogramowania układowego. To pole powinno zostać zaktualizowane podczas wysyłania nowej linii produktu, głównych nowych aktualizacji oprogramowania układowego itd.
5.2.1.3 Specyficzny dla dostawcy

Te cztery bajty mogą służyć do kodowania dowolnych informacji niestandardowych w ofercie specyficznej dla implementacji dostawcy.

5.2.1.4 Różne i wersja protokołu

Te cztery bajty mogą służyć do kodowania dowolnych informacji niestandardowych w ofercie specyficznej dla implementacji dostawcy.

Tabela 5.2-6 polecenie FIRMWARE_UPDATE_OFFER — układ specyficzny dla dostawcy

FIRMWARE_UPDATE_OFFER Komenda — układ specyficzny dla dostawcy.

Bity bajtu specyficznego dla dostawcy zostały opisane w tej tabeli.

Table 5.2-7 FIRMWARE_UPDATE_OFFER Command — Różne i wersja protokołu
Przesunięcie bitowe Pole Rozmiar Opis
0 Wersja protokołu 4 To pole musi być ustawione na 0010b wskazujące, że host/oferta odpowiada wersji 2 protokołu CFU.
4 Zastrzeżony 4 Zastrzeżony. Nie używaj.
8 Zastrzeżony 8 Zastrzeżony. Nie używaj.
16 Specyficzne dla dostawcy 16 To pole może służyć do kodowania dowolnych informacji niestandardowych w ofercie specyficznej dla implementacji dostawcy.

5.2.2 Odpowiedź

Pakiet odpowiedzi FIRMWARE_UPDATE_OFFER jest zdefiniowany w następujący sposób.

Tabela 5.2-8 FIRMWARE_UPDATE_OFFER Układ tokenu odpowiedzi

FIRMWARE_UPDATE_OFFER układ tokenu odpowiedzi.

5.2.2.1 Token
Tabela 5.2–9 Odpowiedź FIRMWARE_UPDATE_OFFER — układ tokenu

FIRMWARE_UPDATE_OFFER Odpowiedź — układ tokenu.

Bity bajtu tokenu zostały opisane w tej tabeli.

Tabela 5.2-10: odpowiedź FIRMWARE_UPDATE_OFFER – bity tokenu
Przesunięcie bitowe Pole Rozmiar Opis
0 Zastrzeżony 8 Zastrzeżony. Nie używaj.
8 Zastrzeżony 8 Zastrzeżony. Nie używaj.
16 Zastrzeżony 8 Zastrzeżony. Nie używaj.
24 Żeton 8 Token do identyfikowania hosta.
5.2.2.2 Zarezerwowane (B7 - B4)

Zastrzeżony. Nie używaj.

5.2.2.3 Przyczyna odrzucenia (RR)
Tabela 5.2–11 odpowiedź FIRMWARE_UPDATE_OFFER — układ przyczyny odrzucenia

FIRMWARE_UPDATE_OFFER odpowiedź — układ przyczyny odrzucenia.

Tabela 5.2–12 odpowiedź FIRMWARE_UPDATE_OFFER — odrzucanie bitów przyczyny

Bity bajtu Przyczyna odrzucenia zostały opisane w tej tabeli.

Przesunięcie bitowe Pole Rozmiar Opis
0 Kod RR 8 Kod przyczyny odrzucenia wskazujący przyczynę podaną przez składnik dotyczącą odrzucenia oferty. Ta wartość zależy od pola Stan. Aby uzyskać mapowanie stanu na kod RR, zobacz Tabela 5.2-13.
8 Zastrzeżony 24 Zastrzeżony. Nie używaj.
Tabela 5.2–13 Wartości kodu RR odpowiedzi FIRMWARE_UPDATE_OFFER

Możliwe wartości bajtu kodu RR są opisane w tej tabeli.

Kod RR Nazwa Opis
0x00 Odrzuć ofertę aktualizacji starego oprogramowania układowego Oferta została odrzucona, ponieważ wersja oferowanego oprogramowania układowego jest starsza lub taka sama jak bieżące oprogramowanie układowe.
0x01 ODRZUCENIE_OFERTY_FIRMWARE_DLA_KOMPONENTU Oferta została odrzucona, ponieważ oferowane oprogramowanie układowe nie ma zastosowania do platformy produktu. Może to być spowodowane nieobsługiwanym identyfikatorem składnika albo tym, że dostarczony obraz nie jest zgodny ze sprzętem komputerowym.
0x02 Propozycja aktualizacji oprogramowania układowego, wymiana oczekująca. Oprogramowanie układowe składnika zostało zaktualizowane, jednak zamiana na nowe oprogramowanie jest oczekiwana. Nie można kontynuować przetwarzania aktualizacji firmware’u do czasu zakończenia operacji zamiany, zazwyczaj przez zresetowanie.
0x03 — 0x08 (Zarezerwowane) Zastrzeżony. Nie używaj.
0x09 — 0xDF (Zarezerwowane) Zastrzeżony. Nie używaj.
0xE0 — 0xFF (Specyficzne dla dostawcy) Te wartości są używane przez projektantów protokołu, a znaczenie jest specyficzne dla dostawcy.
5.2.2.4 Stan
Tabela 5.2-14 FIRMWARE_UPDATE_OFFER układ stanu odpowiedzi

FIRMWARE_UPDATE_OFFER układ stanu odpowiedzi.

Bity bajtu Stan zostały opisane w tej tabeli.

Tabela 5.2-15 Odpowiedź na FIRMWARE_UPDATE_OFFER - Bity stanu
Przesunięcie bitowe Pole Rozmiar Opis
0 Status 8 Wartość ta wskazuje decyzję komponentu o zaakceptowaniu, zawieszeniu, pominięciu lub odrzuceniu oferty. Składnik udostępnia przyczynę w wartości pola Kod RR. Aby uzyskać mapowanie stanu na kod RR, patrz tabela 5.2-16.
8 Zastrzeżony 24 Zastrzeżony. Nie używaj.

Możliwe wartości bajtów stanu zostały opisane w tej tabeli.

Tabela 5.2–16 FIRMWARE_UPDATE_OFFER wartości stanu odpowiedzi
Stan Nazwa Opis
0x00 Pomijanie_oferty_aktualizacji_firmware'u Podmiot postanowił pominąć ofertę. Gospodarz musi zaoferować to ponownie później.
0x01 AKCEPTUJ OFERTĘ AKTUALIZACJI OPROGRAMOWANIA Komponent zdecydował się zaakceptować ofertę.
0x02 Odrzuć ofertę aktualizacji oprogramowania Komponent postanowił odrzucić ofertę.
0x03 Oferta aktualizacji oprogramowania układowego zajęta Urządzenie jest zajęte, a host musi czekać, aż urządzenie będzie gotowe.
0x04 POLECENIE_OFERTY_AKTUALIZACJI_FIRMWARE Używany, gdy identyfikator składnika w bajtach informacji o składniku (zobacz informacje o składniku 5.1.2.1.1) jest ustawiony na wartość 0xFE.

W przypadku kodu polecenia ustawionego na żądanie typu OFFER_NOTIFY_ON_READY, wskazuje, że akcesorium jest gotowe do akceptowania dodatkowych ofert.
0xFF Polecenie aktualizacji oprogramowania układowego nie jest obsługiwane Żądanie oferty nie jest rozpoznawane.

5.2.3 Mapowanie na protokół HID

Komunikat jest wysyłany do składnika za pomocą mechanizmu raportu wyjściowego HID , przy użyciu dedykowanego identyfikatora raportu HID dla aktualizacji oprogramowania. Narzędzie HID TLC do użycia jest opisane w dodatku.

5.3 FIRMWARE_UPDATE_OFFER — informacje

Jeśli identyfikator składnika w bajtach informacji o składniku (zobacz Informacje o składniku) jest ustawiony na 0xFF, bity (15 bajtów) są ponownie definiowane, aby wskazać tylko informacje o ofercie, od hosta do składnika. Ten mechanizm umożliwia rozszerzalność i sposób przekazywania przez hosta określonych informacji do urządzenia, takich jak Lista ofert startowych, Lista ofert końcowych, Rozpocznij całą transakcję. Pakiety informacji o ofercie są zawsze natychmiast akceptowane przez składnik.

5.3.1 Polecenie

Pakiet polecenia FIRMWARE_UPDATE_OFFER -Information jest zdefiniowany w następujący sposób:

Tabela 5.3-1 FIRMWARE_UPDATE_OFFER — układ poleceń informacji

FIRMWARE_UPDATE_OFFER — układ poleceń informacji.

Składnik 5.3.1.1
Tabela 5.3-2 FIRMWARE_UPDATE_OFFER — polecenie informacyjne — rozmieszczenie komponentu

FIRMWARE_UPDATE_OFFER — polecenie information — układ składnika.

Bity bajtu Komponentu opisane są w tej tabeli.

Tabela 5.3-3 FIRMWARE_UPDATE_OFFER — polecenie informacyjne — bity składników
Offset bitowy Pole Rozmiar Opis
0 Kod informacyjny 8 Ta wartość wskazuje typ informacji. Ta wartość nie jest maską bitową i może być tylko jedną z możliwych wartości opisanych w tabeli 5.3-4.
8 Zastrzeżony. 8 Zastrzeżony. Nie używaj.
16 Identyfikator składnika 8 Ustaw wartość na 0xFF.
24 Żeton Host wstawia unikatowy token w pakiecie oferty dla składnika. Ten token musi zostać zwrócony przez komponent w odpowiedzi na ofertę.
Tabela 5.3-4 FIRMWARE_UPDATE_OFFER — Komenda Informacyjna — Wartości Kodu Informacji
Stan Nazwa Opis
0x00 POCZĄTEK_INFORMACJI_O_OFERCIE_CAŁA_TRANZAKCJA Wskazuje, że host jest nowy, lub został ponownie załadowany, a całe przetwarzanie oferty jest (ponownie) uruchamiane.
0x01 OFFER_INFO_START_OFFER_LIST Wskazuje początek listy ofert na hoście, jeśli akcesorium ma reguły pobierania skojarzone z zapewnieniem, że jeden podskładnik jest aktualizowany przed innym podskładnikiem w systemie.
0x02 OFFER_INFO_END_OFFER_LIST Wskazuje koniec listy ofert od hosta.
5.3.1.2 Zarezerwowane B7 - B4

Zastrzeżony. Nie używaj.

5.3.1.3 Zarezerwowane B11 - B8

Zastrzeżony. Nie używaj.

5.3.1.4 Zarezerwowane B15 - B12

Zastrzeżony. Nie używaj.

5.3.2 Odpowiedź

Odpowiedź pakietu FIRMWARE_UPDATE_OFFER — informacje dotyczące oferty jest zdefiniowana w następujący sposób.

Tabela 5.3-5 FIRMWARE_UPDATE_OFFER — układ odpowiedzi informacyjnej

FIRMWARE_UPDATE_OFFER — układ odpowiedzi informacji.

5.3.2.1 Token
Tabela 5.3-6 FIRMWARE_UPDATE_OFFER — układ tokenu odpowiedzi pakietu informacyjnego

FIRMWARE_UPDATE_OFFER — układ tokenu odpowiedzi pakietu informacyjnego.

Bity bajtu tokenu zostały opisane w tej tabeli.

Tabela 5.3-7 FIRMWARE_UPDATE_OFFER — Informacja zwrotna — bity tokenu
Przesunięcie bitowe Pole Rozmiar Opis
0 Zastrzeżony 8 Zastrzeżony. Nie używaj.
8 Zastrzeżony 8 Zastrzeżony. Nie używaj.
16 Zastrzeżony 8 Zastrzeżony. Nie używaj.
24 Żeton 8 Token do identyfikowania hosta
5.3.2.2 Zarezerwowane B7 - B4

Zastrzeżony. Nie używaj.

5.3.2.3 Przyczyna odrzucenia (RR)
Tabela 5.3-8 FIRMWARE_UPDATE_OFFER — odpowiedź na informacje — układ kodu RR

FIRMWARE_UPDATE_OFFER — odpowiedź na informacje — układ kodu RR.

Bity bajtu Przyczyna odrzucenia zostały opisane w tej tabeli.

Tabela 5.3-9 FIRMWARE_UPDATE_OFFER — odpowiedź na informacje o ofercie — bity kodu RR
Przesunięcie bitowe Pole Rozmiar Opis
0 Kod RR 8 Kod przyczyny odrzucenia wskazujący powód podany przez komponent dla odrzucenia oferty. Możliwe wartości są opisane w tabeli 5.3-10. Ta wartość zależy od pola statusu.
8 Zastrzeżony 24 Zastrzeżony. Nie używaj.

Możliwe wartości bajtu kodu RR są opisane w tej tabeli.

Tabela 5.3-10 FIRMWARE_UPDATE_OFFER — Informacyjna odpowiedź — wartości kodu RR
Kod RR Nazwa Opis
0x00 FIRMWARE_OFFER_REJECT_OLD_FW Oferta została odrzucona, ponieważ wersja oferowanego oprogramowania układowego jest starsza lub taka sama jak bieżące oprogramowanie układowe.
0x01 Odrzuć Niewłaściwą Ofertę Komponentów Firmware Oferta została odrzucona, ponieważ oferowane oprogramowanie układowe nie ma zastosowania do platformy produktu. Powodem tego może być nieobsługiwany identyfikator składnika lub oferowany obraz, który nie jest zgodny ze sprzętem systemu.
0x02 OFERTA_AKTUALIZACJI_FIRMWARE ZAMIANA_OCZEKUJĄCA Oprogramowanie układowe składnika zostało zaktualizowane, jednak oczekuje zamiana na nowe oprogramowanie układowe. Nie można kontynuować przetwarzania aktualizacji firmware'u do momentu zakończenia zamiany, co zazwyczaj następuje po zresetowaniu.
0x03 — 0x08 (Zarezerwowane) Zastrzeżony. Nie używaj.
0x09 — 0xDF (Zarezerwowane) Zastrzeżony. Nie używaj.
0xE0 — 0xFF (Specyficzne dla dostawcy) Te wartości są używane przez projektantów protokołu, a znaczenie jest specyficzne dla dostawcy.
5.3.2.4 Status
Tabela 5.3-11 FIRMWARE_UPDATE_OFFER — Struktura informacji o stanie odpowiedzi oferty

FIRMWARE_UPDATE_OFFER — układ informacji o stanie odpowiedzi na ofertę.

Bity bajtu Stan zostały opisane w tej tabeli.

Tabela 5.3-12 FIRMWARE_UPDATE_OFFER — Informacje o Ofercie — Bity Stanu Odpowiedzi
Przesunięcie bitowe Pole Rozmiar Opis
0 Stan 8 To pole musi być ustawione na wartość FIRMWARE_UPDATE_OFFER_ACCEPT. Oznacza to, że składnik zdecydował się zaakceptować ofertę.
8 Zastrzeżony. 24 Zastrzeżony. Nie używaj.

5.4 FIRMWARE_UPDATE_OFFER — rozszerzone

Jeśli identyfikator składnika w bajtach informacji o składniku jest ustawiony na 0xFE, bity (15 bajtów) są ponownie definiowane, aby wskazać polecenie oferty z hosta do oprogramowania układowego urządzenia. Ten mechanizm umożliwia rozszerzalność i sposób przekazywania przez hosta określonych informacji do urządzenia. Pakiety poleceń oferty są zwracane, gdy składnik jest gotowy do odpowiedzi "Zaakceptowane".

5.4.1 Polecenie

Jeśli identyfikator składnika w bajtach informacji o składniku jest ustawiony na 0xFE, cztery DWORD są ponownie zdefiniowane w następujący sposób:

Tabela 5.4-1 FIRMWARE_UPDATE_OFFER — rozszerzony układ poleceń

FIRMWARE_UPDATE_OFFER — rozszerzony układ poleceń.

Składnik 5.4.1.1
Tabela 5.4-2 FIRMWARE_UPDATE_OFFER — rozszerzony pakiet poleceń — polecenie — układ komponentu

FIRMWARE_UPDATE_OFFER — rozszerzony pakiet poleceń — polecenie — układ komponentu.

Bity bajtu komponentu są opisane w tej tabeli.

Tabela 5.4-3 FIRMWARE_UPDATE_OFFER — rozszerzone polecenie — bity komponentów
Przesunięcie bitowe Pole Rozmiar Opis
0 Kod polecenia 8 Ta wartość wskazuje typ polecenia. Ta wartość nie jest maską bitową i może być tylko jedną z możliwych wartości opisanych w tabeli 5.4-4.
8 Zastrzeżony. 8 Zastrzeżony. Nie używaj.
16 Identyfikator składnika 8 Ustaw wartość 0xFE.
24 Żeton Host wstawia unikatowy token w pakiecie oferty dla składnika. Ten token musi zostać zwrócony przez składnik w odpowiedzi na ofertę.
Tabela 5.4-4 FIRMWARE_UPDATE_OFFER — rozszerzone polecenie — wartości kodu polecenia
Stan Nazwa Opis
0x01 POWIADOMIENIE_OFERTA_W_GOTOWOŚCI Wysłane przez hosta, jeśli oferta już wcześniej została odrzucona przez składnik.
0x02 — 0xFF Zastrzeżony Zastrzeżony
5.4.1.2 Zarezerwowane B7 - B4

Zastrzeżony. Nie używaj.

5.4.1.3 Zarezerwowane B11 - B8

Zastrzeżony. Nie używaj.

5.4.1.4 Zarezerwowane B15 - B12

Zastrzeżony. Nie używaj.

5.4.2 Odpowiedź

Odpowiedź urządzenia na komendę FIRMWARE_UPDATE_OFFER może nie zostać odebrana natychmiast. Odpowiedź jest zdefiniowana w następujący sposób.

Tabela 5.4-5 FIRMWARE_UPDATE_OFFER — rozszerzony układ odpowiedzi pakietu poleceń

FIRMWARE_UPDATE_OFFER — rozszerzony układ odpowiedzi pakietu poleceń.

5.4.2.1 Token
Tabela 5.4-6 FIRMWARE_UPDATE_OFFER — oferowanie odpowiedzi na pakiety poleceń — układ tokenu

FIRMWARE_UPDATE_OFFER — oferowanie odpowiedzi pakietu poleceń — układ tokenu.

Bity bajtu tokenu zostały opisane w tej tabeli.

Tabela 5.4-7 FIRMWARE_UPDATE_OFFER — oferowanie odpowiedzi polecenia — bity tokenu
Przesunięcie bitowe Pole Rozmiar Opis
0 Zastrzeżony 8 Zastrzeżony. Nie używaj.
8 Zastrzeżony 8 Zastrzeżony. Nie używaj.
16 Zastrzeżony 8 Zastrzeżony. Nie używaj.
24 Żeton 8 Token do identyfikowania hosta.
5.4.2.2 Zarezerwowane B7 - B4

Zastrzeżony. Nie używaj.

5.4.2.3 Powód odrzucenia
Tabela 5.4-8 FIRMWARE_UPDATE_OFFER — schemat RR odpowiedzi na ofertę pakietu informacyjnego

FIRMWARE_UPDATE_OFFER — układ RR odpowiedzi na pakiety informacyjne.

Bity bajtu Przyczyna odrzucenia zostały opisane w tej tabeli.

Tabela 5.4-9 FIRMWARE_UPDATE_OFFER — odpowiedź na polecenie oferty — kod RR
Przesunięcie bitowe Pole Rozmiar Opis
0 Kod RR 8 Ta wartość zależy od pola Stan. Aby uzyskać informacje o możliwych wartościach kodu RR, zobacz Tabela 5.4-10.
8 Zastrzeżony 24 Zastrzeżony. Nie używaj.

Możliwe wartości bajtu kodu RR są opisane w tej tabeli.

Tabela 5.4-10 FIRMWARE_UPDATE_OFFER — pakiet poleceń oferty — wartości kodu RR
Kod RR Nazwa Opis
0x00 ODRZUCENIE_OFERTY_STAREGO_FIRMWARE Oferta została odrzucona, ponieważ wersja oferowanego oprogramowania układowego jest starsza lub taka sama jak bieżące oprogramowanie układowe.
0x01 OFERTA_OPROGRAMOWANIA_ODRZUĆ_NW_KOMPONENT Oferta została odrzucona, ponieważ oferowane oprogramowanie układowe nie ma zastosowania do platformy produktu. Może to być spowodowane nieobsługiwanym identyfikatorem składnika lub oferowany obraz systemowy nie jest zgodny ze sprzętem systemowym.
0x02 OFERTA_AKTUALIZACJI_FIRMWARE WYMIANA_OCZEKUJĄCA Oprogramowanie układowe składnika zostało zaktualizowane, jednak jego zamiana na nowe jest w trakcie oczekiwania. Nie można kontynuować przetwarzania aktualizacji firmware do momentu zakończenia zamiany, co zazwyczaj odbywa się przez zresetowanie.
0x03 — 0x08 (Zarezerwowane) Zastrzeżony. Nie używaj.
0x09 — 0xDF (Zarezerwowane) Zastrzeżony. Nie używaj.
0xE0 — 0xFF (Specyficzne dla dostawcy) Te wartości są używane przez projektantów protokołu, a znaczenie jest specyficzne dla dostawcy.
5.4.2.4 Stan
Tabela 5.4-11 FIRMWARE_UPDATE_OFFER — układ statusu odpowiedzi pakietu polecenia oferty

FIRMWARE_UPDATE_OFFER — układ stanu odpowiedzi pakietu polecenia oferty.

Bity bajtu Stan zostały opisane w tej tabeli.

Tabela 5.4-12 FIRMWARE_UPDATE_OFFER — kod RR odpowiedzi na pakiety poleceń
Przesunięcie bitowe Pole Rozmiar Opis
0 Stan 8 To pole musi być ustawione na wartość FIRMWARE_UPDATE_OFFER_ACCEPT. Oznacza to, że składnik zdecydował się zaakceptować ofertę.
8 Zastrzeżony. 24 Zastrzeżony. Nie używaj.

5.5 AKTUALIZACJA OPROGRAMOWANIA UKŁADOWEGO ZAWARTOŚĆ

Host wysyła to polecenie do oprogramowania układowego urządzenia w celu udostępnienia zawartości oprogramowania układowego (czyli obrazu oprogramowania układowego). Cały plik obrazu nie powinien mieścić się w jednym poleceniu. Host musi podzielić obraz na mniejsze bloki, a każde polecenie wysyła jeden blok obrazu naraz.

Przy każdym poleceniu host wskazuje dodatkowe informacje — czy jest to pierwszy blok, ostatni blok itd. oprogramowania układowego. Podstawowy składnik oprogramowania układowego urządzenia akceptuje każdy blok obrazu przychodzącego oprogramowania układowego, przechowuje go w pamięci i musi odpowiadać na każde polecenie indywidualnie.

Gdy składnik podstawowy odbierze ostatni blok, składnik weryfikuje cały obraz oprogramowania układowego (sprawdzanie CRC, walidacja podpisu). Na podstawie wyników tych testów zwraca odpowiednią odpowiedź (niepowodzenie lub powodzenie) dla ostatniego bloku.

5.5.1 Polecenie

Układ polecenia FIRMWARE_UPDATE_CONTENT w tabeli 5.5-1

FIRMWARE_UPDATE_CONTENT schemat polecenia.

Nagłówek 5.5.1.1 (B7– B0)
Tabela 5.5-2 FIRMWARE_UPDATE_CONTENT Układ nagłówka polecenia

FIRMWARE_UPDATE_CONTENT układ nagłówka polecenia.

Bity nagłówka FIRMWARE_UPDATE_CONTENT są opisane w tej tabeli.

Bity nagłówka tabeli 5.5–3 FIRMWARE_UPDATE_CONTENT
Przesunięcie bitowe Pole Rozmiar Opis
0 Flagi 8 To pole zawiera dodatkowe informacje o poleceniu. Ta wartość to maska flag do użycia na potrzeby transferów danych. Możliwe wartości są opisane w tabeli 5.5-4.
8 Długość danych 8 Długość pola danych określającego liczbę bajtów do zapisania.

Biorąc pod uwagę rozmiar tego polecenia, maksymalna dozwolona wartość długości wynosi 52 bajty.
16 Numer sekwencji 16 Ta wartość jest tworzona przez hosta i jest unikatowa dla każdego wystawionego pakietu zawartości. Składnik musi zwrócić numer sekwencji w odpowiedzi na to żądanie.
32 Adres oprogramowania układowego 32 Little Endian (LSB First) Adres do zapisu danych. Adres jest oparty na 0. Oprogramowanie układowe używa tego jako wartości przesunięcia, aby określić potrzebny adres pamięci podczas umieszczania obrazu w pamięci.

Możliwe wartości bajtu Flags zostały opisane w tej tabeli.

Tabela 5.5-4 FIRMWARE_UPDATE_OFFER — pakiet komendy oferty — wartości flagi
Flaga Nazwa Opis
0x80 FIRMWARE_UPDATE_FLAG_FIRST_BLOCK Ta flaga wskazuje, że jest to pierwszy blok obrazu oprogramowania układowego.
0x40 FIRMWARE_UPDATE_FLAG_LAST_BLOCK (flaga związana z ostatnim blokiem aktualizacji oprogramowania) Ta flaga wskazuje, że jest to ostatni blok obrazu oprogramowania układowego i że obraz jest gotowy do zweryfikowania.

Ważne jest, aby bieżące oprogramowanie układowe składnika przeprowadzało walidację całego pobranego obrazu po zapisaniu tego bloku w pamięci nietrwałej.
5.5.1.2 Dane
Tabela 5.5-5 FIRMWARE_UPDATE_CONTENT Układ danych poleceń

FIRMWARE_UPDATE_CONTENT układ danych poleceń.

Bity danych FIRMWARE_UPDATE_CONTENT zostały opisane w tej tabeli.

Bity danych polecenia w tabeli 5.5-6 FIRMWARE_UPDATE_CONTENT
Przesunięcie bitowe Pole Rozmiar Opis
64 Dane Maksymalnie 52. Tablica bajtów do zapisu. Host zwykle wysyła bloki o 4 bajty w oparciu o architekturę produktu. Nieużywane bajty na końcu muszą być wypełnione zerami.

5.5.2 Odpowiedź

Tabela 5.5-7 FIRMWARE_UPDATE_CONTENT układ odpowiedzi polecenia

FIRMWARE_UPDATE_CONTENT Układ odpowiedzi na polecenie.

5.5.2.1 Numer sekwencji
Tabela 5.5-8 Odpowiedź FIRMWARE_UPDATE_CONTENT — numer sekwencji

FIRMWARE_UPDATE_CONTENT odpowiedź — numer sekwencji.

Bity odpowiedzi FIRMWARE_UPDATE_CONTENT (3-0) zostały opisane w tej tabeli.

Tabela 5.5-9 FIRMWARE_UPDATE_CONTENT — polecenie — bity odpowiedzi
Przesunięcie bitowe Pole Rozmiar Opis
0 Numer sekwencji 16 To pole to numer sekwencji, który został wysłany przez hosta w żądaniu.
16 Zastrzeżony 16 Zastrzeżony. Nie używaj.
5.5.2.2 Stan
Tabela 5.5-10 FIRMWARE_UPDATE_CONTENT układ stanu odpowiedzi

FIRMWARE_UPDATE_CONTENT układ stanu odpowiedzi.

Bity odpowiedzi FIRMWARE_UPDATE_CONTENT (7–4) zostały opisane w tej tabeli.

Tabela 5.5-11 FIRMWARE_UPDATE_OFFER — odpowiedź — bity stanu
Przesunięcie bitowe Pole Rozmiar Opis
0 Stan 8 Ta wartość wskazuje kod stanu zwrócony przez składnik urządzenia. Nie jest to bitowe i może być jedną z wartości opisanych w tabeli 5.5-12.
8 Zastrzeżony 24 Zastrzeżony. Nie używaj.

Możliwe wartości bajtów stanu zostały opisane w tej tabeli.

Tabela 5.5-12 FIRMWARE_UPDATE_OFFER — Odpowiedź — wartości kodu stanu
Flaga Nazwa Opis
0x00 Aktualizacja oprogramowania zakończona sukcesem Żądanie zostało ukończone pomyślnie.
0x01 BŁĄD_AKTUALIZACJI_FIRMWARE_PRZYGOTUJ Składnik nie był przygotowany do odbierania zawartości oprogramowania układowego.

W przypadku użycia ten kod jest zwykle używany w odpowiedzi na pierwszy blok. Na przykład usunięcie błędu na pamięci flash.
0x02 BŁĄD_AKTUALIZACJI_OPROGRAMOWANIA_WRITE Żądanie nie może zapisać bajtów.
0x03 BŁĄD_AKTUALIZACJI_FIRMWARE_ZAKOŃCZONY Żądanie nie może skonfigurować zamiany w odpowiedzi na FIRMWARE_UPDATE_FLAG_LAST_BLOCK.
0x04 BŁĄD_AKTUALIZACJI_OPROGRAMOWANIA_WERYFIKACJA Weryfikacja DWORD nie powiodła się w odpowiedzi na FIRMWARE_UPDATE_FLAG_VERIFY.
0x05 FIRMWARE_UPDATE_ERROR_CRC CRC obrazu oprogramowania układowego nie powiodło się w odpowiedzi na FIRMWARE_UPDATE_FLAG_LAST_BLOCK.
0x06 BŁĄD WERYFIKACJI AKTUALIZACJI OPROGRAMOWANIA UKŁADOWEGO Weryfikacja podpisu oprogramowania układowego nie powiodła się w odpowiedzi na flagę aktualizacji oprogramowania układowego oznaczającą ostatni blok (FIRMWARE_UPDATE_FLAG_LAST_BLOCK).
0x07 BŁĄD_AKTUALIZACJI_FIRMWARE_WERSJA Weryfikacja wersji oprogramowania układowego nie powiodła się w odpowiedzi na FIRMWARE_UPDATE_FLAG_LAST_BLOCK.
0x08 Aktualizacja oprogramowania - zamiana oczekująca Oprogramowanie układowe zostało już zaktualizowane i trwa oczekiwanie na zamianę. Nie można zaakceptować żadnych dalszych poleceń aktualizacji oprogramowania układowego do czasu zresetowania akcesorium.
0x09 BŁĄD_AKTUALIZACJI_FIRMWARE_NIEPRAWIDŁOWY_ADRES Oprogramowanie układowe wykryło nieprawidłowy adres docelowy w zawartości danych komunikatu.
0x0A BŁĄD_AKTUALIZACJI_OPROGRAMOWANIA_BRAK_OFERTY Polecenie FIRMWARE_UPDATE_OFFER zostało odebrane bez uprzedniego otrzymania prawidłowej i zaakceptowanej oferty aktualizacji oprogramowania układowego.
0x0B BŁĄD_AKTUALIZACJI_FIRMWARE_NIEPRAWIDŁOWY Błąd ogólny polecenia FIRMWARE_UPDATE_OFFER, taki jak nieprawidłowa odpowiednia długość danych.
5.5.2.3 Zarezerwowane B8 - B11

Zastrzeżony. Nie używaj.

5.5.2.4 Zarezerwowane B12 - B15

Zastrzeżony. Nie używaj.

6 Dodatek 1: Przykładowa sekwencja poleceń programowania aktualizacji oprogramowania układowego

6.1 Przykład 1

Rozważ następujące oprogramowanie układowe urządzenia:

  • Składnik podstawowy — identyfikator składnika 1 — bieżące oprogramowanie układowe w wersji 7.0.1

  • Podskładnik — identyfikator składnika 2 — bieżące oprogramowanie układowe w wersji 12.4.54

  • Podskładnik — identyfikator składnika 3 — bieżące oprogramowanie układowe w wersji 4.4.2

  • Podskładnik — identyfikator składnika 4 — bieżąca wersja oprogramowania układowego 23.32.9

Host ma te trzy obrazy oprogramowania układowego:

  • Identyfikator składnika 1 — oprogramowanie układowe w wersji 7.1.3

  • Identyfikator komponentu 2 — oprogramowanie układowe w wersji 12.4.54

  • Identyfikator składnika 3 — wersja oprogramowania układowego 4.5.0

Sekwencja będzie:

  1. Oferty hosta: Identyfikator składnika 1 — Wersja firmware 7.1.3

  2. Składnik podstawowy akceptuje ofertę

  3. Host wysyła obraz oprogramowania układowego

  4. Składnik podstawowy akceptuje oprogramowanie układowe, weryfikuje go

  5. Host oferuje: Identyfikator składnika 2 — wersja oprogramowania układowego 12.4.54

  6. Składnik podstawowy odrzuca ofertę

  7. Oferty hostów: Identyfikator składnika 3 — oprogramowanie układowe w wersji 4.5.0

  8. Składnik podstawowy akceptuje ofertę

  9. Host wysyła obraz oprogramowania układowego

  10. Składnik podstawowy akceptuje oprogramowanie układowe, weryfikuje go

Ponieważ wszystkie oferty nie zostały odrzucone, gospodarz odtwarza wszystkie oferty:

  1. Oferty hosta: Identyfikator składnika 1 — wersja oprogramowania układowego 7.1.3

  2. Składnik odrzuca

  3. Oferty hostów: Identyfikator składnika 2 — oprogramowanie układowe w wersji 12.4.54

  4. Odrzucone składniki

  5. Oferty hostów: Identyfikator składnika 3 — oprogramowanie układowe w wersji 4.5.0

  6. Odrzucone składniki

6.2 Przykład 2

Rozważ następujące oprogramowanie układowe urządzenia:

  • Składnik podstawowy — identyfikator składnika 1 — bieżące oprogramowanie układowe w wersji 7.0.1

  • Podskładnik — identyfikator składnika 2 — bieżące oprogramowanie układowe w wersji 12.4.54

  • Podskładnik — identyfikator składnika 3 — bieżące oprogramowanie układowe w wersji 7.4.2

  • Podskładnik — identyfikator komponentu 4 — bieżąca wersja oprogramowania układowego: 23.32.9

Host ma te trzy obrazy firmware:

  • Identyfikator składnika 1 — oprogramowanie układowe w wersji 8.0.0

  • Identyfikator składnika 2 — firmware w wersji 12.4.54

  • Identyfikator składnika 3 – wersja oprogramowania układowego 9.0.0

Ponadto implementacja wymaga, aby wersja oprogramowania układowego podskładników nie może być mniejsza niż wersja oprogramowania układowego uruchomiona w składniku podstawowym. Host nie jest świadomy tego wymagania i up-to jest podstawowym składnikiem w celu zapewnienia tej reguły.

Sekwencja będzie:

  1. Oferty hostów: Identyfikator składnika 1 — oprogramowanie układowe w wersji 8.0.0

  2. Składnik podstawowy odrzuca (ponieważ identyfikator składnika 3 nie został jeszcze zaktualizowany)

  3. Oferty hostów: Identyfikator składnika 2 — wersja oprogramowania układowego 12.4.54

  4. Składnik podstawowy odrzuca

  5. Oferty hostów: Identyfikator składnika 3 — oprogramowanie układowe w wersji 9.0.0

  6. Podstawowy składnik akceptuje ofertę

  7. Host wysyła obraz oprogramowania układowego

  8. Składnik podstawowy akceptuje oprogramowanie układowe, weryfikuje go

Ponieważ wszystkie oferty nie zostały odrzucone, gospodarz odtwarza wszystkie oferty

  1. Host oferuje: Identyfikator składnika 1 — wersja oprogramowania układowego 8.0.0

  2. Podstawowy składnik akceptuje ofertę

  3. Host wysyła obraz oprogramowania układowego

  4. Składnik podstawowy akceptuje oprogramowanie układowe, weryfikuje go

  5. Oferty hostów: Identyfikator składnika 2 — oprogramowanie układowe w wersji 12.4.54

  6. Główny składnik odrzuca coś

  7. Oferty hostów: Identyfikator składnika 3 — oprogramowanie układowe w wersji 9.0.0

  8. Składnik podstawowy odrzuca