CFU-protocolspecificatie (Component Firmware Update)
In deze specificatie wordt een algemeen HID-protocol beschreven voor het bijwerken van firmware voor onderdelen die aanwezig zijn op een pc of accessoires. Met de specificatie kan een onderdeel firmware accepteren zonder de apparaatbewerking tijdens een download te onderbreken. De specificatie ondersteunt configuraties waarbij het onderdeel dat de firmware accepteert mogelijk subonderdelen heeft, waarvoor afzonderlijke firmware-installatiekopieën vereist zijn. De specificatie stelt de verantwoordelijke voor de component in staat om te bepalen of de firmware moet worden geaccepteerd. Het fungeert ook als optimalisatie omdat de firmware-installatiekopieën alleen naar het onderdeel worden verzonden als het kan of gereed is om het te accepteren.
Notitie
CFU is beschikbaar in Windows 10, versie 2004 (Windows 10 mei 2020 Update) en latere versies.
Inhoud
- 1 Inleiding
- 2 ondersteunde hardwarearchitectuur
- 3-protocolvereisten
- Overzicht van 4 CFU-protocol
-
4.1 Firmware-update programmeeropdrachtenreeks
- 4.1.1 Status: Geïnitialiseerde hostmelding
- 4.1.2 Status: OFFER_INFO_START_OFFER_LIST Melding
- 4.1.3 State: FIRMWARE_UPDATE_OFFER-opdracht verzenden
- 4.1.4-status: Firmware verzenden
- Beslissingsstatus 4.1.5: Zijn er meer aanbiedingen
- 4.1.6 Status: OFFER_INFO_END_OFFER_LIST Kennisgeving
- 4.1.7 Beslissingsstatus: Lijst met aanbiedingen opnieuw afspelen
- Status 4.1.8: Apparaat is bezet
-
4.1 Firmware-update programmeeropdrachtenreeks
- 5 CFU-protocolpakketindeling
- 6 bijlage 1: voorbeeld van voor het programmeren van firmware-updates
Tabellen
Tabel 5.1-1 GET_FIRMWARE_VERSION Antwoordstructuur
Tabel 5.1-2 GET_FIRMWARE_VERSION Antwoord - koptekstindeling
Tabel 5.1-3 GET_FIRMWARE_VERSION-Antwoord - Header-bits
Tabel 5.1-4 GET_FIRMWARE_VERSION Reactie - Indeling van componentversie en eigenschappen
tabel 5.1-5 GET_FIRMWARE_VERSION-antwoord - Versie en eigenschappenbytes van componenten
Tabel 5.2-1 FIRMWARE_UPDATE_OFFER Opdrachtindeling
Opdracht Tabel 5.2-2 FIRMWARE_UPDATE_OFFER - Indeling van onderdeelinformatie
opdracht Tabel 5.2-3 FIRMWARE_UPDATE_OFFER - Bits voor onderdeelinformatie
Tabel 5.2-4 FIRMWARE_UPDATE_OFFER Opdracht - Indeling Firmwareversie
Opdracht Tabel 5.2-5 FIRMWARE_UPDATE_OFFER - firmwareversie-bits
opdracht Tabel 5.2-6 FIRMWARE_UPDATE_OFFER - Leverancierspecifieke indeling
Tabel 5.2-7 FIRMWARE_UPDATE_OFFER Command - Diversen en Protocolversie
Tabel 5.2-8 FIRMWARE_UPDATE_OFFER Indeling van Antwoordtoken
Tabel 5.2-9 FIRMWARE_UPDATE_OFFER Antwoord - Tokenindeling
Tabel 5.2-10 FIRMWARE_UPDATE_OFFER Antwoord - Token Bits
Tabel 5.2-11 FIRMWARE_UPDATE_OFFER Antwoord - Afwijzingsredenindeling
Tabel 5.2-12 FIRMWARE_UPDATE_OFFER-antwoord - bits van afwijsredenen
Tabel 5.2-13 FIRMWARE_UPDATE_OFFER Response RR-codewaarden
Tabel 5.2-14 FIRMWARE_UPDATE_OFFER Indeling Antwoordstatus
Tabel 5.2-15 FIRMWARE_UPDATE_OFFER-antwoord - statusbits
Tabel 5.2-16 FIRMWARE_UPDATE_OFFER Reactie Statuswaarden
Tabel 5.3-1 FIRMWARE_UPDATE_OFFER - Indeling van gegevensopdracht
Tabel 5.3-2 FIRMWARE_UPDATE_OFFER - Informatiecommando - Indeling van onderdelen
Tabel 5.3-3 FIRMWARE_UPDATE_OFFER - Informatieopdracht - Onderdeel Bits
Tabel 5.3-4 FIRMWARE_UPDATE_OFFER - Informatieopdracht - Waarden voor Informatiecode
Tabel 5.3-5 FIRMWARE_UPDATE_OFFER - Indeling voor antwoord op informatie
Tabel 5.3-6 FIRMWARE_UPDATE_OFFER - Layout van het antwoordtoken voor informatiepakketten
Tabel 5.3-7 FIRMWARE_UPDATE_OFFER - Antwoord op gegevens - Token bits
Tabel 5.3-8 FIRMWARE_UPDATE_OFFER - Informatieantwoord - Indeling van RR-code
Tabel 5.3-9 FIRMWARE_UPDATE_OFFER - Antwoord op aanbiedingsinformatie - RR-code-bits
Tabel 5.3-10 FIRMWARE_UPDATE_OFFER- Informatieantwoord - RR-codewaarden
Tabel 5.3-11 FIRMWARE_UPDATE_OFFER - Indeling voor antwoordstatus van aanbiedingsinformatie
Tabel 5.3-12 FIRMWARE_UPDATE_OFFER - Aanbiedingsinformatie - Antwoordstatus-bits
Tabel 5.4-1 FIRMWARE_UPDATE_OFFER - Uitgebreide opdrachtindeling
Tabel 5.4-2 FIRMWARE_UPDATE_OFFER - Uitgebreid opdrachtpakket - Opdracht - Indeling van onderdelen
Tabel 5.4-3 FIRMWARE_UPDATE_OFFER - Uitgebreide opdracht - Component-bits
Tabel 5.4-4 FIRMWARE_UPDATE_OFFER - Uitgebreide opdracht - Opdrachtcodewaarden
Tabel 5.4-5 FIRMWARE_UPDATE_OFFER - Indeling voor antwoord van uitgebreide opdrachtpakketten
Tabel 5.4-6 FIRMWARE_UPDATE_OFFER- Opdrachtpakketantwoord aanbieden - Tokenindeling
Tabel 5.4-7 FIRMWARE_UPDATE_OFFER - Opdrachtantwoord aanbieden - Token bits
Tabel 5.4-8 FIRMWARE_UPDATE_OFFER - Indeling voor antwoord op informatiepakket RR
Tabel 5.4-9 FIRMWARE_UPDATE_OFFER - Respons op aanbiedingsopdracht - RR-code
Tabel 5.4-10 FIRMWARE_UPDATE_OFFER- Opdrachtpakket aanbieden - RR-codewaarden
Tabel 5.4-11 FIRMWARE_UPDATE_OFFER - Indeling van antwoordstatus voor aanbieding van opdrachtpakket
Tabel 5.4-12 FIRMWARE_UPDATE_OFFER- Opdrachtpakketantwoord RR-code aanbieden
Tabel 5.5-1 FIRMWARE_UPDATE_CONTENT opdrachtindeling
tabel 5.5-2 FIRMWARE_UPDATE_CONTENT opdrachtkopindeling
Tabel 5.5-3 FIRMWARE_UPDATE_CONTENT Header-bits
Tabel 5,5-4 FIRMWARE_UPDATE_OFFER- Opdrachtpakket aanbieden - Waarden markeren
Tabel 5.5-5 FIRMWARE_UPDATE_CONTENT Opdrachtgegevensindeling
Tabel 5.5-6 FIRMWARE_UPDATE_CONTENT Bits voor Opdrachtgegevens
Tabel 5,5-7 FIRMWARE_UPDATE_CONTENT opdracht-antwoordindeling
Tabel 5,5-8 FIRMWARE_UPDATE_CONTENT Antwoord - Reeksnummer
Tabel 5,5-9 FIRMWARE_UPDATE_CONTENT - Opdracht - Antwoord-bits
Tabel 5.5-10 FIRMWARE_UPDATE_CONTENT Antwoordstatus Indeling
Tabel 5,5-11 FIRMWARE_UPDATE_OFFER - Antwoord - Status-bits
Tabel 5,5-12 FIRMWARE_UPDATE_OFFER- Antwoord - Statuscodewaarden
1 Inleiding
De pc's en accessoires van vandaag hebben interne componenten die complexe bewerkingen uitvoeren. Om een kwaliteitsproduct te garanderen, moet u het gedrag van deze apparaten regelmatig bijwerken in latere fasen van ontwikkeling of nadat ze naar de klanten zijn verzonden. De update kan geïdentificeerde functionele of beveiligingsproblemen oplossen of nieuwe functies toevoegen. Een groot deel van de complexe logica bevindt zich in de firmware die wordt uitgevoerd op het apparaat, dat kan worden bijgewerkt.
In deze specificatie wordt een algemeen HID-protocol beschreven voor het bijwerken van de firmware voor onderdelen die aanwezig zijn op een pc of de bijbehorende accessoires. HID-implementatie valt buiten het bereik van de specificatie.
Enkele van de functies van het protocol zijn:
Het protocol is gebaseerd op HID, dat alomtegenwoordig is en Windows-ondersteuning biedt via verschillende interconnectbussen, zoals USB en I2C. Daarom kan dezelfde softwareoplossing (stuurprogramma) worden gebruikt om de firmware voor alle onderdelen bij te werken.
Notitie
Omdat de specificatie op pakketten is gebaseerd, is het eenvoudig om deze aan te passen aan niet-HID-scenario's.
Met de specificatie kan een onderdeel firmware accepteren zonder de apparaatbewerking tijdens het downloaden te onderbreken. Het biedt gebruikers een betere ervaring omdat ze niet hoeven te wachten totdat het firmware-updateproces is voltooid voordat ze andere taken kunnen hervatten. De nieuwe firmware kan worden aangeroepen in één atomische bewerking tegelijk die minimale gevolgen heeft voor de gebruiker.
De specificatie ondersteunt configuraties waarbij het onderdeel dat de firmware accepteert mogelijk subonderdelen heeft, waarvoor afzonderlijke firmware-installatiekopieën vereist zijn.
Notitie
Het proces van een onderdeel dat de firmware aan het subonderdeel overgeeft, valt buiten het bereik van deze specificatie.
De specificatie ondersteunt het concept van een aanbieding en is afhankelijk van de verantwoordelijke component om ervoor te kiezen de firmware al dan niet te accepteren. De beslissing om nieuwe firmware te accepteren is niet triviaal. Er zijn mogelijk afhankelijkheden tussen het firmwaretype en/of de versie en het onderliggende type/de onderliggende versie van hardware waarop de nieuwe firmware van toepassing is. Een aanbod fungeert ook als een optimalisatiemechanisme omdat de firmware-image alleen naar het onderdeel wordt verzonden als het in staat of gereed is om het te accepteren.
1.1 Woordenlijst
| Term | Beschrijving |
|---|---|
| Onderdeel-id | Op een apparaat met meerdere onderdelen identificeert een onderdeel-id elk onderdeel uniek. |
| CRC | Cyclische redundantiecontrole Een niet-cryptografisch hash-algoritme dat wordt gebruikt voor het produceren van een samenvatting of vingerafdruk van een blok gegevens. De CRC wordt gebruikt als een controle om te garanderen dat het gegevensblok niet is gewijzigd sinds de CRC is berekend. De CRC is niet onfeilbaar, maar biedt vertrouwen dat de gegevens correct zijn ontvangen. |
| Apparaat | Een verzameling onderdelen (één primair onderdeel en nul of meer subonderdelen). Het apparaat is als één eenheid zichtbaar voor het besturingssysteem. De host communiceert met het apparaat. Dit is meestal het primaire onderdeel. Een computer kan meerdere apparaten bevatten. Wat deze specificatie betreft, zijn de communicatie met 2 verschillende apparaten volledig onafhankelijk. |
| Chauffeur | Een stuurprogramma dat is geschreven met behulp van het WDF-framework (Windows Driver Foundation). |
| Firmware | De code die wordt uitgevoerd op de fysieke hardware. Firmware kan worden bijgewerkt en bevindt zich meestal in programmeerbaar geheugen dat is gekoppeld aan de hardware. |
| Hardware | Een fysiek stukje silicium op de computer. |
| Primair onderdeel | Een stuk hardware op een computer en de firmware hiervoor. In de context van deze specificatie is een onderdeel de entiteit die de firmware-update nodig heeft en accepteert. |
| Segment | Een firmware image voor een component kan worden gesegmenteerd in kleinere segmenten. Elk segment is een kleine firmware-afbeelding. |
| Segment-id | Als een firmware van een onderdeel in kleinere segmenten is gesegmenteerd, is segment-id de unieke id voor het segment. |
| Handtekening | Een cryptografische methode om te bepalen of de firmware-installatiekopieën zijn gewijzigd door onbevoegde middelen. Handtekeningen zijn optioneel, maar worden aanbevolen en vallen buiten het bereik van deze specificatie. |
| Subonderdeel | Afhankelijk van de hardwarearchitectuur zijn niet alle onderdelen mogelijk zichtbaar voor het besturingssysteem, omdat ze mogelijk downstream zijn verbonden met een onderdeel dat zichtbaar is voor het systeem. Deze onderdelen worden in deze specificatie subonderdelen genoemd. |
| TLC | HID Topniveauverzameling. |
| Teken | Een id voor een hostsessie. Een host maakt een token en verzendt het in opdrachten en het apparaat retourneert het in het antwoord. Tokens kunnen worden gebruikt om bepaalde transacties te serialiseren of om te identificeren dat een sessie verloren is gegaan en een andere sessie is gestart. |
1.2 Bereik
1.2.1 Doelen
Er is een busagnostische oplossing vereist om een nieuw protocol voor elk type bus te voorkomen. HID is alomtegenwoordig en beantwoordt die vereiste.
De mogelijkheid om firmware-updates voor een apparaat met meerdere onderdelen te ondersteunen, waarbij één onderdeel fungeert als het primaire onderdeel en andere subonderdelen die zijn verbonden met het primaire onderdeel. Elk onderdeel vereist een eigen firmware met niet-triviale afhankelijkheden tussen elkaar.
Een universeel drivermodel voor het downloaden van de firmware-afbeelding naar de component. Het onderdeel bevat vervolgens specifieke algoritmen voor subonderdelen voor het doorsturen naar de subonderdelen. De subonderdelen kunnen ook geldigheidscontroles uitvoeren op hun firmware en de resultaten doorgeven aan het primaire onderdeel.
De mogelijkheid om firmware-updates te ondersteunen terwijl de apparaatbewerking wordt uitgevoerd.
De mogelijkheid om de firmware in productieapparaten bij te werken/terug te draaien via geautoriseerde hulpprogramma's en apparaten in de markt bij te werken via Windows Update.
De flexibiliteit om firmware in ontwikkeling/firmware op de markt te ondersteunen.
De mogelijkheid om een grote firmware-afbeelding te segmenteren in kleinere segmenten, zodat het voor het onderdeel makkelijker is om de firmware-afbeelding te accepteren.
1.2.2 Niet-doelstellingen
Definieer de interne indeling van de firmware-installatiekopie: voor de host is de firmware-installatiekopie een set adres- en nettoladingvermeldingen.
De geaccepteerde firmware ondertekenen/versleutelen/valideren: in deze specificatie wordt niet beschreven hoe u de installatiekopieën van de firmware kunt ondertekenen en versleutelen. Het is vereist dat de huidige firmware op het onderdeel de nieuw te downloaden firmware valideert.
Definieer een mechanisme over de interactie van het onderdeel met de subonderdelen: de host communiceert met het apparaat als één eenheid, meestal het primaire onderdeel. Het onderdeel moet fungeren als een brug voor communicatie met betrekking tot de subcomponentfirmware.
2 Ondersteunde hardwarearchitectuur
Ter ondersteuning van een flexibel hardwareontwerp ondersteunt het protocol een apparaat met meerdere onderdelen waarbij elk onderdeel een eigen firmware-installatiekopieën vereist. In het ontwerp is één onderdeel het primaire onderdeel en de afhankelijke subonderdelen zijn verbonden met dat primaire onderdeel. Elk onderdeel wordt uniek beschreven door een onderdeel-id.
Het apparaat met meerdere onderdelen is zichtbaar voor het besturingssysteem als één eenheid. De host communiceert alleen met het apparaat, meestal het primaire onderdeel met behulp van dit CFU-protocol. De communicatie tussen het onderdeel en de bijbehorende subonderdelen valt buiten het bereik van deze specificatie.
Op een pc zijn er mogelijk veel verschillende apparaten (waarbij een apparaat mogelijk een of meer onderdelen bevat). In de context van dit protocol is de communicatie met elk apparaat onafhankelijk. Elk apparaat heeft een bijbehorend exemplaar van de host.
3 Protocolvereisten
In deze sectie worden de perquisites en aanbevolen procedures vermeld die moeten worden geïmplementeerd om gebruik te maken van dit protocol:
Atomisch afbeeldingsgebruik
Een firmware-image voor een onderdeel wordt pas gebruikt als de volledige firmware-image succesvol is gedownload. Als de firmware in meerdere segmenten wordt gesplitst, mag de afbeelding pas worden gebruikt als het laatste segment van de afzender is ontvangen. Integriteitscontroles moeten worden uitgevoerd op de uiteindelijke afbeelding. Het wordt aanbevolen dat het transport, dat wordt gebruikt om de installatiekopieën van de firmware te leveren, foutcorrectie heeft en mechanismen voor opnieuw proberen heeft om een herhalingsdownload te voorkomen in het geval van transportfouten.
Firmware-update mag apparaatbewerking niet onderbreken
Het apparaat dat de firmware-installatiekopieën accepteert, moet tijdens de update kunnen werken. Het apparaat moet extra geheugen hebben om de binnenkomende firmware op te slaan en te valideren, terwijl de huidige firmware niet wordt overschreven.
Verificatie en integriteit
De implementor beslist welke factoren een authentieke firmware-afbeelding vormen. Het is raadzaam dat de huidige firmware van het onderdeel ten minste de CRC van de binnenkomende firmware-installatiekopieën moet valideren. De huidige firmware moet ook gebruikmaken van digitale handtekening of andere algoritmen voor foutdetectie. Als de validatie mislukt, weigert de firmware de update. Herstel van fouten
Als de firmware-installatiekopieën zijn gedownload en mislukt, mag het apparaat de nieuwe firmware niet aanroepen en blijven werken met de bestaande firmware. De host kan de update opnieuw proberen. De frequentie van nieuwe pogingen is specifiek voor de implementatie.
Vertrouwelijkheid
Facultatief. Een firmwaresegment kan worden versleuteld. De versleutelings- en ontsleutelingstechnieken vallen buiten het bereik van deze specificatie. Deze specificatie behandelt de nettolading van de firmware als een gegevensstroom, ongeacht of deze is versleuteld.
Terugdraai beveiliging
Beleid voor terugdraaien wordt afgedwongen door het primaire onderdeel en zijn implementatiespecifiek. De huidige firmware op het onderdeel valideert binnenkomende firmware-installatiekopieën op basis van intern beleid, zoals dat het versienummer nieuwer moet zijn of dat het releasetype niet kan worden overgeschakeld van release naar foutopsporing, enzovoort. Het protocol staat berichten toe om aan te geven dat een update wordt geaccepteerd, zelfs als het beleid voor terugdraaien schendt.
Overzicht van het 4 CFU-protocol
Het CFU-protocol is een set opdrachten en antwoorden die nodig zijn om de nieuwe firmware-installatiekopieën van de host te verzenden naar het apparaat waarvoor de firmware is bedoeld.
Op hoog niveau doorloopt het protocol alle firmware-installatiekopieën die naar het apparaat moeten worden verzonden. Voor elke firmware-afbeelding biedt de host de mogelijkheid om het bestand naar het apparaat te verzenden. Alleen als het apparaat de aanbieding accepteert, verzendt de host het bestand.
Ter ondersteuning van gevallen waarin een apparaatupdateorder afhankelijkheden heeft, accepteert het apparaat mogelijk bepaalde aanbiedingen in de eerste pas niet. Daarom kan de host alle firmwareaanbiedingen opnieuw verzenden naar het apparaat totdat alle afhankelijkheden zijn opgelost.
4.1 Programmeeropdrachtreeks voor firmware-updates
Hier is de CFU-commandosequentie voor het bijwerken van de firmware-image.
4.1.1 Status: Geïnitialiseerde hostmelding
Nadat de host zichzelf heeft geïnitialiseerd en een set aanbiedingen heeft geïdentificeerd die naar het apparaat moeten worden verzonden, geeft de host een OFFER_INFO_START_ENTIRE_TRANSACTION opdracht uit om aan te geven aan het onderdeel dat de host nu is geïnitialiseerd. Het doel van deze opdracht is om de huidige apparaatfirmware op de hoogte te stellen dat er een nieuw exemplaar van de host beschikbaar is. Deze melding is handig wanneer een eerder exemplaar van de host onverwacht wordt beëindigd. Het apparaat moet deze opdracht voltooien met succes.
4.1.2 Status: OFFER_INFO_START_OFFER_LIST Melding
In deze status geeft de host de OFFER_INFO_START_OFFER_LIST opdracht uit om aan te geven dat deze gereed is om de aanbieding(en) naar de huidige apparaatfirmware te verzenden. Het primaire onderdeel van het apparaat moet deze opdracht voltooien met succes.
Deze opdracht is handig omdat de host meerdere keren alle aanbiedingen naar het apparaat kan verzenden.
4.1.3 Status: opdracht FIRMWARE_UPDATE_OFFER verzenden
De host verzendt een aanbieding naar het primaire onderdeel (of het bijbehorende subonderdeel) om te controleren of het onderdeel de firmware wil accepteren/afwijzen. De aanbieding bevat alle benodigde metagegevens over de firmware-image, zodat de huidige firmware op het onderdeel kan bepalen of de aanbieding moet worden geaccepteerd, in behandeling gehouden, overgeslagen of geweigerd.
De aanbieding kan voor het primaire onderdeel of het subonderdeel zijn. Als het onderdeel de aanbieding kan accepteren, bereidt het zich voor om de firmware te ontvangen. Dit kan betrekking hebben op het voorbereiden van een geheugenbank om de binnenkomende firmware-installatiekopieën te ontvangen. Het onderdeel kan de aanbieding niet accepteren, bijvoorbeeld dat het onderdeel al een nieuwere (of dezelfde) firmwareversie heeft die de host wil verzenden. Zie voor meer redenen de voorbeelden die worden beschreven in bijlage 1: Voorbeeld van firmware-update programmeeropdrachtreeks.
Zelfs als een aanbod wordt geaccepteerd, kan het primaire onderdeel het firmwarebeeld nog steeds afwijzen, zelfs na het downloaden, wegens het falen van integriteits- en/of terugdraaicontroles op de feitelijk ontvangen image. Het onderdeel moet elke eigenschap van de firmware-installatiekopieën controleren, onafhankelijk van alle informatie in de aanbieding.
De host geeft de FIRMWARE_UPDATE_OFFER opdracht om het primaire onderdeel op de hoogte te stellen van de firmware-installatiekopie die de host wil verzenden.
Als het onderdeel de aanbieding accepteert, krijgt het de status FIRMWARE_UPDATE_OFFER_ACCEPT en accepteert daarmee de aanbieding.
Als de firmware van het apparaat bezet is en het primaire onderdeel dit of de volgende aanbieding momenteel niet kan accepteren, wordt er een bezet antwoord met FIRMWARE_UPDATE_OFFER_BUSY status verzonden.
Als de huidige firmware geïnteresseerd is in de aanbieding, kan de aanbieding echter niet worden geaccepteerd (bijvoorbeeld vanwege een afhankelijkheid van een ontbrekende update voor subcomponent) reageert deze met een FIRMWARE_UPDATE_OFFER_SKIP die aangeeft dat het geïnteresseerd is in deze firmware, maar deze niet kan accepteren. De host gaat vervolgens verder met de volgende aanbieding en moet deze firmware later opnieuw aanbieden.
Als de huidige firmware niet geïnteresseerd is in de aanbieding (bijvoorbeeld een oudere versie), reageert deze met een FIRMWARE_UPDATE_OFFER_REJECT status die de juiste weigeringsreden biedt. Deze status geeft niet aan dat de host deze aanbieding in de toekomst niet opnieuw kan verzenden. De host verzendt doorgaans elke aanbieding telkens wanneer deze de lijst met aanbiedingen initialiseert of opnieuw verzendt naar het apparaat (zie Status: OFFER_INFO_START_OFFER_LIST Notification).
4.1.4 Status: Firmware verzenden
In deze status begint de host de installatiekopie van de firmware naar het primaire onderdeel te verzenden, waarvoor het onderdeel de aanbieding eerder heeft geaccepteerd.
Omdat de inhoud van de firmware-installatiekopie waarschijnlijk de nettoladinglimieten van één opdracht zal overschrijden, breekt de host de firmware-installatiekopieën in pakketten. De host verzendt elk pakket sequentieel in een afzonderlijke opdracht FIRMWARE_UPDATE INHOUD. Het primaire onderdeel moet voor elke opdracht een antwoordpakket genereren.
Elke FIRMWARE_UPDATE inhoudsopdracht beschrijft een offsetadres dat een gedeeltelijke nettolading van de firmware bevat. Het onderdeel gebruikt de offset om het adres te bepalen waar de gedeeltelijke nettolading van de firmware moet worden opgeslagen. Het apparaat schrijft de inhoud naar een geschikte locatie en bevestigt de opdracht door een antwoord te verzenden.
Voor het eerste pakket dat de host verzendt, wordt de vlag FIRMWARE_UPDATE_FLAG_FIRST_BLOCK ingesteld, die aangeeft aan het apparaat dat dit het eerste pakket van de firmware-installatiekopie is. Als het apparaat zich nog niet heeft voorbereid om de firmware te ontvangen, kan dit op dit moment gebeuren.
Voor het laatste pakket dat de host verzendt, wordt de FIRMWARE_UPDATE_FLAG_LAST_BLOCK-flag ingesteld.
Nadat de huidige firmware op het apparaat de gedeeltelijke nettolading van de firmware in deze opdracht heeft geschreven, moet deze validatie- en verificatiecontroles uitvoeren op de installatiekopie van de binnenkomende firmware voordat een antwoord wordt verzonden. Dit omvat minimaal:
Een CRC-controle om de integriteit van de volledige firmware-installatiekopieën te controleren.
Als de CRC-controle slaagt, kan optioneel de handtekening van de binnenkomende afbeelding worden gecontroleerd.
Na de optionele handtekeningcontrole controleert u of de nieuwe firmwareversie hetzelfde of nieuwer is dan de bestaande firmware.
Als de binnenkomende firmware-installatiekopieën zijn onderverdeeld in kleinere segmenten, is het aan de huidige firmware om te bepalen of het het laatste segment van de firmware-installatiekopieën is en vervolgens alle segmenten als onderdeel van de validatie bevat.
Als de voorgaande controles slagen, kan de huidige firmware het apparaat zodanig instellen dat het bij de volgende reset overschakelt naar het nieuwe image en succes rapporteert aan de host. Normaal gesproken initieert het onderdeel geen zelfherstel. Dit is om onderbrekingen te voorkomen in software, firmware, hardware-entiteiten waarmee het onderdeel communiceert. Dit is echter geen vereiste en kan variëren, afhankelijk van de implementatie.
Als de verificatiestappen mislukken, mag de firmware geen geheugenwissel instellen bij de volgende reset en moet een foutmelding naar de host worden verstuurd.
4.1.5 Beslissingsstaat: Zijn er meer aanbiedingen
In deze status bepaalt de host of er meer aanbiedingen zijn om naar het apparaat te verzenden.
4.1.6 Toestand: OFFER_INFO_END_OFFER_LIST Melding
Deze status wordt bereikt wanneer de host alle aanbiedingen naar het primaire onderdeel in de huidige apparaatfirmware heeft verzonden. De host verzendt de OFFER_INFO_END_OFFER_LIST opdracht om aan te geven dat alle aanbiedingen naar het onderdeel zijn verzonden.
Het apparaat moet deze opdracht voltooien met succes.
4.1.7 Beslissingsstatus: Lijst met aanbiedingen opnieuw afspelen
De host bepaalt of alle aanbiedingen opnieuw moeten worden verzonden. Dit geval kan zich voordoen als het primaire onderdeel eerder enkele aanbiedingen had overgeslagen en bepaalde aanbiedingen had geaccepteerd. De host moet de lijst met aanbiedingen opnieuw afspelen.
Er kan andere implementatiespecifieke logica zijn die kan leiden tot een beslissing om de lijst met aanbiedingen opnieuw af te spelen.
4.1.8 Status: Apparaat is bezet
Deze status impliceert dat een apparaat een bezet antwoord op een aanbieding heeft geretourneerd.
De host verzendt een OFFER_NOTIFY_ON_READY opdracht, waarnaar het apparaat niet reageert met acceptatie totdat het apparaat gratis is.
5 CFU Protocol Pakketindeling
Het CFU-protocol wordt geïmplementeerd als een set opdrachten en antwoorden. Het protocol is sequentieel van aard. Voor elke opdracht die de host naar een onderdeel verzendt, wordt verwacht dat het onderdeel reageert (tenzij expliciet anders vermeld in deze specificatie). De host verzendt de volgende opdracht pas als er een geldig antwoord is ontvangen voor de vorige opdracht die wordt verzonden.
Als het onderdeel niet binnen een bepaalde periode reageert of een ongeldig antwoord verzendt, kan de host het proces opnieuw starten vanaf het begin. Dit protocol definieert geen specifieke time-outwaarde.
Er zijn opdrachten om de versie-informatie van de huidige firmware op het onderdeel op te halen; om de aanbieding te verzenden en de firmware-installatiekopieën te verzenden.
De host hoeft echter geen aanbieding af te houden op basis van het antwoord dat is ontvangen van het primaire onderdeel over de informatie over de opgevraagde versie. De informatie kan worden gedetecteerd voor logboekregistratie of andere doeleinden.
5.1 GET_FIRMWARE_VERSION
Hiermee haalt u de huidige firmwareversie(s) van het primaire onderdeel (en de bijbehorende subonderdelen) op. De opdracht heeft geen argumenten.
Opdracht 5.1.1
Deze opdracht wordt door de host verzonden om een query uit te voeren op de versie(s) van de huidige firmware(s) op het primaire onderdeel (en de bijbehorende subonderdelen). De host kan deze gebruiken om te bevestigen of de firmware is bijgewerkt. Bij ontvangst van deze opdracht reageert het primaire onderdeel met de firmwareversie voor zichzelf en alle subonderdelen.
5.1.2 Antwoord
Het onderdeel reageert met de firmwareversie van het primaire onderdeel en de subonderdelen. De antwoordgrootte is 60 bytes, waardoor versie-informatie voor maximaal zeven onderdelen (één primaire en maximaal zes subonderdelen) is toegestaan.
Tabel 5.1-1 GET_FIRMWARE_VERSION Antwoordindeling
Koptekst 5.1.2.1
Tabel 5.1-2 GET_FIRMWARE_VERSION Antwoord - Headerindeling
De header voor het antwoord bevat de volgende informatie.
Tabel 5.1-3 GET_FIRMWARE_VERSION-antwoord - header-bits
| Bit-offset | Veld | Grootte | Beschrijving |
|---|---|---|---|
| 0 | Aantal onderdelen | 8 | Het aantal downloadbare onderdelen dat wordt beheerd via dit mechanisme voor dit onderdeel. Het aantal onderdelen bepaalt de maximale tabelgrootte. Momenteel worden maximaal 7 onderdelen ondersteund om ervoor te zorgen dat het antwoord binnen de toegestane 60 bytes past. |
| 8 | Rsvd | 16 | Gereserveerde velden. De afzender moet deze instellen op 0. Ontvanger moet deze waarde negeren. |
| 24 | Protocolversie | 4 | De revisie-bits voor firmware-updates geven aan welke revisie van het FW-updateprotocol momenteel wordt gebruikt in het transport. Voor de interface die hier is gedefinieerd, moet de revisie van de FW-update 0010b zijn. |
| 28 | Rsvd | 3 | Gereserveerde velden. De afzender moet deze instellen op 0. Ontvanger moet deze waarde negeren. |
| 31 | E | 1 | De extensievlag is een toekomstige protocolhook waarmee extra onderdelen kunnen worden gerapporteerd. |
5.1.2.2 Componentversie en Eigenschappen
Voor elk onderdeel worden twee DWORD's gebruikt om de eigenschappen ervan te beschrijven, voor maximaal 7 onderdelen. Als het aantal onderdelen in de header kleiner is dan 7, moet de ongebruikte DWORDS aan het einde van het antwoord worden ingesteld op 0.
Tabel 5.1-4 GET_FIRMWARE_VERSION Antwoord - Indeling van onderdeelversie en eigenschappen
Elk onderdeelspecifieke informatie wordt als volgt beschreven in twee DWORDs:
Tabel 5.1-5 GET_FIRMWARE_VERSION Response - Component Version en Properties Bytes
| Bit-offset | Veld | Grootte | Beschrijving |
|---|---|---|---|
| 0 | Firmwareversie | 32 | Retourneert de versie van de huidige firmware voor dat onderdeel. Deze specificatie vereist geen specifieke indeling voor de firmwareversie. Zie de sectie Firmwareversie voor richtlijnen. |
| 32 | Bank | 2 | Facultatief. Afhankelijk van de architectuur kan de hardware van het onderdeel meerdere banken hebben waarin de firmware kan worden opgeslagen. Afhankelijk van de implementatie kan de afzender de bank opgeven waarin de firmware momenteel bestaat. Dit veld is voorwaardelijk verplicht. Ondersteuning is optioneel, maar mag niet worden gebruikt voor andere doeleinden. |
| 34 | Gereserveerd | 2 | Gereserveerde velden. De afzender moet deze instellen op 0. Ontvanger moet deze waarde negeren. |
| 36 | Leverancierspecifiek | 4 | Leveranciersspecifiek veld dat mogelijk op een implementatie-afhankelijke manier kan worden gebruikt. Een leverancier kan deze bits gebruiken om informatie te coderen, zoals: - Type firmware: pre-release/self-host/productie; foutopsporing/detailhandel - Ontwikkelingsfase - Product-id, om te voorkomen dat onderdelen firmware ontvangen voor andere producten die gebruikmaken van hetzelfde updateprotocol. |
| 40 | Onderdeel-id | 8 | Een unieke id voor het onderdeel. |
| 48 | Leverancierspecifiek | 16 | Leverancierspecifiek veld dat kan worden gebruikt op een manier die specifiek is voor de implementatie. |
5.1.3 Koppeling aan HID
Dit wordt geïmplementeerd als een HID Get Feature aanvraag met een antwoordgrootte van 60 bytes, naast de rapport-id. De lengte van het functierapport omvat de volledige GET_FIRMWARE_VERSION response. Er zijn geen gegevens gekoppeld aan het Get Feature-verzoek van de host.
5.2 FIRMWARE_UPDATE_AANBOD
Bepaalt of het primaire onderdeel een firmware accepteert of weigert.
Opdracht 5.2.1
De host verzendt deze opdracht naar het onderdeel om te bepalen of het een firmware accepteert of weigert. De host moet een aanbieding verzenden en het onderdeel moet de aanbieding accepteren voordat de host de firmware kan verzenden.
Het FIRMWARE_UPDATE_OFFER Opdrachtpakket wordt als volgt gedefinieerd.
Tabel 5.2-1 FIRMWARE_UPDATE_OFFER Opdrachtindeling
5.2.1.1 Component Informatie
Tabel 5.2-2 FIRMWARE_UPDATE_OFFER-commando - Indeling van componentinformatie
De bits van de byte Component Information worden beschreven in deze tabel.
Tabel 5.2-3 FIRMWARE_UPDATE_OFFER-opdracht - Onderdeelinformatiebits
| Bit-offset | Veld | Grootte | Beschrijving |
|---|---|---|---|
| 0 | Segmentnummer | 8 | Dit veld wordt gebruikt voor het geval de firmware voor een onderdeel wordt gesegmenteerd in kleinere segmenten. Als deze waarde wordt gebruikt, geeft deze waarde het segment aan dat is opgenomen in het volgende nettoladingpakket. Als de firmware-image voor het onderdeel bijvoorbeeld erg groot is en het primaire onderdeel slechts kleinere delen van de image tegelijk kan verwerken, kan dit veld worden gebruikt om aan te geven dat het voor het i-de segment van de volledige image is. Een aparte aanbieding kan worden gestuurd naar het primaire onderdeel dat het i+1e segment van de afbeelding bevat, enzovoort. |
| 8 | Gereserveerd | 6 | Gereserveerde velden. De afzender moet deze instellen op 0. Ontvanger moet deze waarde negeren. |
| 14 | Ik | 1 | Onmiddellijk opnieuw instellen forceren (I) - Deze bitwaarde wordt gebruikt om aan te geven dat het onderdeel onmiddellijk opnieuw moet worden ingesteld nadat het downloaden van de firmware is voltooid en geverifieerd om het onmiddellijk aan te roepen. - Deze vlag is bedoeld voor de ontwikkelingsfase. |
| 15 | V | 1 | Versie negeren forceren (V) - Deze vlag is bedoeld voor een pre-release of debug firmware-afbeelding. Het geeft aan dat het onderdeel de firmware niet weigert op basis van de firmwareversie. - Deze vlag is bedoeld voor de ontwikkelingsfase. Het kan worden gebruikt om opzettelijk terug te draaien naar een eerdere firmwareversie. - Deze vlag moet worden genegeerd door productie-firmware. |
| 16 | Onderdeel-id | 8 | Deze byte wordt gebruikt voor scenario's met meerdere onderdelen. Dit veld kan worden gebruikt om het subonderdeel te identificeren waarvoor de aanbieding is bedoeld. Als de waarde niet wordt gebruikt, moet deze 0 zijn. De mogelijke waarden van onderdeel-id's zijn als volgt: 1 - 0xDF: Geldig 0xE0 - 0xFD: Gereserveerd. Niet gebruiken. 0xFF: De aanbieding is een informatiepakket over speciale aanbiedingen. Zie FIRMWARE_UPDATE_OFFER informatie voor meer informatie. 0xFE: De aanbieding is een opdrachtpakket voor speciale aanbiedingen. Raadpleeg de uitgebreide sectie van FIRMWARE_UPDATE_OFFER voor meer informatie. |
| 24 | Teken | 8 | De host voegt een uniek token in het aanbiedingspakket voor de component in. Dit token moet door het onderdeel in de aanbiedingsreactie worden geretourneerd. Dit is handig als het onderdeel onderscheid moet maken tussen de verschillende hosts/typen hosts. Exacte waarden die moeten worden gebruikt, zijn implementatiespecifiek. De ene waarde kan bijvoorbeeld worden gebruikt voor een stuurprogramma en een andere voor de toepassing. Hierdoor kan de huidige apparaatfirmware rekening houden met mogelijke meerdere afzenders van CFU-opdrachten. Een mogelijke implementatie kan zijn om de eerste CFU-opdracht te accepteren en alle andere opdrachten met verschillende tokens te negeren totdat de eerste CFU-transacties zijn voltooid. |
5.2.1.2 Firmwareversie
Deze vier bytes vertegenwoordigen de 32-bits versie van de firmware. De indeling voor de firmwareversie is niet verplicht volgens deze specificatie. Het volgende wordt aanbevolen.
Tabel 5.2-4 FIRMWARE_UPDATE_OFFER Opdracht - Indeling firmwareversie
De indeling voor de firmwareversie is niet verplicht volgens deze specificatie, maar hieronder volgt een aanbevolen richtlijn.
Opdracht tabel 5.2-5 FIRMWARE_UPDATE_OFFER - firmwareversie-bits
| Bit-offset | Veld | Grootte | Beschrijving |
|---|---|---|---|
| 0 | Variant | 8 | Dit veld kan worden beschreven om onderscheid te maken tussen een firmware vóór release en productiefirmware. Het kan duiden op het type handtekening dat wordt gebruikt om de firmware te ondertekenen. |
| 8 | Kleine versie | 16 | Deze veldwaarde moet worden bijgewerkt voor elke build van de firmware. Deze veldwaarde moet worden bijgewerkt voor elke build van de firmware. |
| 24 | Hoofdversie | 8 | Dit veld is de hoofdversie van de firmwareversie. Dit veld moet worden bijgewerkt bij het verzenden van een nieuwe productlijn, belangrijke nieuwe updates voor de firmware, enzovoort. |
5.2.1.3 Leverancierspecifiek
Deze vier bytes kunnen worden gebruikt om aangepaste informatie in de aanbieding te coderen die specifiek is voor de implementatie van de leverancier.
5.2.1.4 Misc. en Protocolversie
Deze vier bytes kunnen worden gebruikt om aangepaste informatie in de aanbieding te coderen die specifiek is voor de implementatie van de leverancier.
Tabel 5.2-6 FIRMWARE_UPDATE_OFFER Opdracht - Leverancierspecifieke indeling
De bits van de leverancierspecifieke byte worden in deze tabel beschreven.
Tabel 5.2-7 FIRMWARE_UPDATE_OFFER Opdracht - Misc. en Protocolversie
| Bit-offset | Veld | Grootte | Beschrijving |
|---|---|---|---|
| 0 | Protocolversie | 4 | Dit veld moet worden ingesteld op 0010b die aangeeft dat de host/aanbieding overeenkomt met versie 2 van het CFU-protocol. |
| 4 | Gereserveerd | 4 | Gereserveerd. Niet gebruiken. |
| 8 | Gereserveerd | 8 | Gereserveerd. Niet gebruiken. |
| 16 | Leverancierspecifiek | 16 | Dit veld kan worden gebruikt om aangepaste informatie in de aanbieding te coderen die specifiek is voor de implementatie van de leverancier. |
5.2.2-antwoord
Het FIRMWARE_UPDATE_OFFER Antwoordpakket wordt als volgt gedefinieerd.
Tabel 5.2-8 FIRMWARE_UPDATE_OFFER Antwoordtokenindeling
5.2.2.1 Token
Tabel 5.2-9 FIRMWARE_UPDATE_OFFER Antwoord - Tokenindeling
De bits van de token-byte worden beschreven in deze tabel.
Tabel 5.2-10 FIRMWARE_UPDATE_OFFER Antwoord - Token-bits
| Bit-offset | Veld | Grootte | Beschrijving |
|---|---|---|---|
| 0 | Gereserveerd | 8 | Gereserveerd. Niet gebruiken. |
| 8 | Gereserveerd | 8 | Gereserveerd. Niet gebruiken. |
| 16 | Gereserveerd | 8 | Gereserveerd. Niet gebruiken. |
| 24 | Teken | 8 | Token om de host te identificeren. |
5.2.2.2 Gereserveerd (B7 - B4)
Gereserveerd. Niet gebruiken.
5.2.2.3 Afwijsreden (RR)
Tabel 5.2-11 FIRMWARE_UPDATE_OFFER Antwoord - Opmaak van Afwijsreden
Tabel 5.2-12 FIRMWARE_UPDATE_OFFER Antwoord - Reden-bits negeren
De bits van de byte Reden voor afwijzing worden in deze tabel beschreven.
| Bit-offset | Veld | Grootte | Beschrijving |
|---|---|---|---|
| 0 | RR-code | 8 | De redencode weigeren die de reden aangeeft die is opgegeven door het onderdeel voor het weigeren van de aanbieding. Deze waarde is afhankelijk van het veld Status. Zie tabel 5.2-13 voor een status-naar-RR-codetoewijzing. |
| 8 | Gereserveerd | 24 | Gereserveerd. Niet gebruiken. |
Tabel 5.2-13 FIRMWARE_UPDATE_OFFER Antwoordcodewaarden voor RR
De mogelijke waarden voor de RR Code-byte worden beschreven in deze tabel.
| RR-code | Naam | Beschrijving |
|---|---|---|
| 0x00 | FIRMWARE_AANBOD_AFWIJZING_OUDE_FW | De aanbieding is geweigerd omdat de versie van de aangeboden firmware ouder of gelijk is aan de huidige firmware. |
| 0x01 | FIRMWARE_OFFER_REJECT_INV_COMPONENT | De aanbieding is geweigerd omdat de aangeboden firmware niet van toepassing is op het platform van het product. Dit kan worden veroorzaakt door een niet-ondersteunde onderdeel-id of de aangeboden afbeelding is niet compatibel met de systeemhardware. |
| 0x02 | FIRMWARE_UPDATE_OFFER SWAP_PENDING | De onderdeelfirmware is bijgewerkt, maar er is een wissel naar de nieuwe firmware in behandeling. Er kan geen verdere verwerking van firmware-updates plaatsvinden totdat het wisselen is voltooid, meestal via een reset. |
| 0x03 - 0x08 | (Gereserveerd) | Gereserveerd. Niet gebruiken. |
| 0x09 - 0xDF | (Gereserveerd) | Gereserveerd. Niet gebruiken. |
| 0xE0 - 0xFF | (Leverancierspecifiek) | Deze waarden worden gebruikt door de ontwerpers van het protocol en de betekenis is leverancierspecifiek. |
5.2.2.4 Status
Tabel 5.2-14 FIRMWARE_UPDATE_OFFER Antwoordstatusstructuur
De bits van de status byte worden beschreven in deze tabel.
Tabel 5.2-15 FIRMWARE_UPDATE_OFFER-reactie - Statusbits
| Bitverplaatsing | Veld | Grootte | Beschrijving |
|---|---|---|---|
| 0 | Status | 8 | Deze waarde geeft de beslissing van het onderdeel aan om de aanbieding te accepteren, te penden, over te slaan of af te wijzen. Het onderdeel geeft de reden voor de waarde van het RR-codeveld aan. Raadpleeg tabel 5.2-16 voor de toewijzing van een status aan een RR-code. |
| 8 | Gereserveerd | 24 | Gereserveerd. Niet gebruiken. |
De mogelijke waarden voor de status-byte worden beschreven in deze tabel.
Tabel 5.2-16 FIRMWARE_UPDATE_OFFER Statuswaarden van antwoord
| Status | Naam | Beschrijving |
|---|---|---|
| 0x00 | Firmware-updateaanbieding overslaan | Het onderdeel heeft besloten de aanbieding over te slaan. De host moet deze later opnieuw aanbieden. |
| 0x01 | FIRMWARE_UPDATE_AANBIEDING_ACCEPTEREN | Het onderdeel heeft besloten de aanbieding te accepteren. |
| 0x02 | FIRMWARE_UPDATE_AANBOD_AFWIJZEN | Het onderdeel heeft besloten de aanbieding af te wijzen. |
| 0x03 | Firmware-update-aanbieding-bezet | Het apparaat is bezet en de host moet wachten totdat het apparaat gereed is. |
| 0x04 | FIRMWARE_UPDATE_AANBIEDINGSOPDRACHT | Wordt gebruikt wanneer onderdeel-id in het onderdeelgegevensbytes (zie 5.1.2.1.1-onderdeelgegevens) is ingesteld op 0xFE. Voor opdrachtcode ingesteld op het verzoek OFFER_NOTIFY_ON_READY, geeft aan dat de accessoire gereed is om extra aanbiedingen te accepteren. |
| 0xFF | FIRMWARE_UPDATE_OPDRACHT_NIET_ONDERSTEUND | De aanvraag voor de aanbieding wordt niet herkend. |
5.2.3 Toewijzing aan HID-protocol
Het bericht wordt aan het onderdeel doorgegeven via het HID-uitvoerrapport mechanisme, met behulp van de toegewezen HID Hulpprogrammarapport-ID voor firmware-update. De HID Utility TLC die moet worden gebruikt, zoals beschreven in de bijlage.
5.3 FIRMWARE_UPDATE_OFFER - Informatie
Als de onderdeel-id in het onderdeelgegevensbytes (zie Onderdeelinformatie) is ingesteld op 0xFF, worden bits (15 bytes) opnieuw gedefinieerd om alleen aanbiedingsgegevens aan te geven, van de host naar het onderdeel. Dit mechanisme maakt uitbreidbaarheid en een manier mogelijk voor de host om specifieke informatie te verstrekken aan het apparaat, zoals Lijst met startaanbieding, lijst met eindaanbieding, Volledige transactie starten. Aanbiedingsinformatiepakketten worden altijd onmiddellijk geaccepteerd door het onderdeel.
5.3.1-opdracht
Het FIRMWARE_UPDATE_OFFER -Information opdrachtpakket wordt als volgt gedefinieerd:
Tabel 5.3-1 FIRMWARE_UPDATE_OFFER - Layout van het informatiecommando
5.3.1.1 Component
Tabel 5.3-2 FIRMWARE_UPDATE_OFFER - Informatieopdracht - Indeling van onderdelen
De bits van de component-byte worden beschreven in deze tabel.
Tabel 5.3-3 FIRMWARE_UPDATE_OFFER - Informatieopdracht - Onderdeel-bits
| Bit-offset | Veld | Grootte | Beschrijving |
|---|---|---|---|
| 0 | Informatiecode | 8 | Deze waarde geeft het type informatie aan. Deze waarde is geen bitmasker en kan slechts een van de mogelijke waarden zijn die worden beschreven in tabel 5.3-4. |
| 8 | Gereserveerd. | 8 | Gereserveerd. Niet gebruiken. |
| 16 | Onderdeel-id | 8 | Ingesteld op 0xFF. |
| 24 | Teken | De host voegt een uniek token toe aan het aanbiedingspakket voor het onderdeel. Dit token moet worden geretourneerd door het onderdeel in de respons op het aanbod. |
Tabel 5.3-4 FIRMWARE_UPDATE_OFFER - Informatieopdracht - Waarden voor informatiecode
| Status | Naam | Beschrijving |
|---|---|---|
| 0x00 | AANBOD_INFO_START_VOLLEDIGE_TRANSACTIE | Geeft aan dat de host nieuw is of opnieuw is geladen en dat de volledige verwerking van de aanbieding (opnieuw) wordt gestart. |
| 0x01 | OFFER_INFO_START_OFFER_LIST | Hiermee wordt het begin van de lijst met aanbiedingen van de host aangegeven in het geval het accessoire downloadregels heeft die ervoor zorgen dat een subcomponent moet worden bijgewerkt voordat een ander subcomponent in het systeem is geüpdatet. |
| 0x02 | AANBIEDING_INFO_EIND_AANBIEDING_LIJST | Geeft het einde van de lijst met aanbiedingen van de host aan. |
5.3.1.2 Gereserveerd B7 - B4
Gereserveerd. Niet gebruiken.
5.3.1.3 Gereserveerde B11 - B8
Gereserveerd. Niet gebruiken.
5.3.1.4 Gereserveerd B15 - B12
Gereserveerd. Niet gebruiken.
5.3.2 Antwoord
Het antwoordpakket voor het aanbodinformatie van FIRMWARE_UPDATE_OFFER is als volgt gedefinieerd.
Tabel 5.3-5 FIRMWARE_UPDATE_OFFER - Indeling van antwoord op gegevens
5.3.2.1 Token
Tabel 5.3-6 FIRMWARE_UPDATE_OFFER- Indeling van antwoordtoken voor informatiepakket
De bits van de token-byte worden beschreven in deze tabel.
Tabel 5.3-7 FIRMWARE_UPDATE_OFFER - Antwoord op gegevens - Token-bits
| Bit-offset | Veld | Grootte | Beschrijving |
|---|---|---|---|
| 0 | Gereserveerd | 8 | Gereserveerd. Niet gebruiken. |
| 8 | Gereserveerd | 8 | Gereserveerd. Niet gebruiken. |
| 16 | Gereserveerd | 8 | Gereserveerd. Niet gebruiken. |
| 24 | Teken | 8 | Token om de host te identificeren |
5.3.2.2 Gereserveerd B7 - B4
Gereserveerd. Niet gebruiken.
5.3.2.3 Afwijsreden (RR)
Tabel 5.3-8 FIRMWARE_UPDATE_OFFER - Informatieantwoord - RR-code-indeling
De bits van de Weigerreden-byte worden beschreven in deze tabel.
Tabel 5.3-9 FIRMWARE_UPDATE_OFFER - Antwoord op aanbiedingsinformatie - RR-code-bits
| bitverplaatsing | Veld | Grootte | Beschrijving |
|---|---|---|---|
| 0 | RR-code | 8 | De redencode weigeren die de reden aangeeft die is opgegeven door het onderdeel voor het weigeren van de aanbieding. De mogelijke waarden worden beschreven in tabel 5.3-10. Deze waarde is afhankelijk van het veld Status. |
| 8 | Gereserveerd | 24 | Gereserveerd. Niet gebruiken. |
De mogelijke waarden voor de RR Code-byte worden beschreven in deze tabel.
Tabel 5.3-10 FIRMWARE_UPDATE_OFFER- Informatieantwoord - RR-codewaarden
| RR-code | Naam | Beschrijving |
|---|---|---|
| 0x00 | AANBOD_FIRMWARE_WEIGEREN_OUDE_FW | De aanbieding is geweigerd omdat de versie van de aangeboden firmware ouder of gelijk is aan de huidige firmware. |
| 0x01 | FIRMWARE_AANBIEDING_AFWIJZING_INV_COMPONENT | De aanbieding is geweigerd omdat de aangeboden firmware niet van toepassing is op het platform van het product. Dit kan worden veroorzaakt door een niet-ondersteunde component-ID of omdat de aangeboden image niet compatibel is met de systeemhardware. |
| 0x02 | FIRMWARE_UPDATE_AANBOD WISSELING_IN_WACHTEN | De onderdeelfirmware is bijgewerkt, maar er is een wissel naar de nieuwe firmware in behandeling. Er kan geen verdere verwerking van firmware-updates plaatsvinden totdat het wisselen is voltooid, meestal via een reset. |
| 0x03 - 0x08 | (Gereserveerd) | Gereserveerd. Niet gebruiken. |
| 0x09 - 0xDF | (Gereserveerd) | Gereserveerd. Niet gebruiken. |
| 0xE0 — 0xFF | (Leverancierspecifiek) | Deze waarden worden gebruikt door de ontwerpers van het protocol en de betekenis is leverancierspecifiek. |
5.3.2.4 Status
Tabel 5.3-11 FIRMWARE_UPDATE_OFFER - Layout van responsstatus voor aanbiedingsinformatie
De bits van de status byte worden beschreven in deze tabel.
Tabel 5.3-12 FIRMWARE_UPDATE_OFFER - Aanbiedingsinformatie - Antwoordstatus-bits
| Bit-offset | Veld | Grootte | Beschrijving |
|---|---|---|---|
| 0 | Status | 8 | Dit veld moet worden ingesteld op FIRMWARE_UPDATE_OFFER_ACCEPT. Dit geeft aan dat het onderdeel heeft besloten de aanbieding te accepteren. |
| 8 | Gereserveerd. | 24 | Gereserveerd. Niet gebruiken. |
5.4 FIRMWARE_UPDATE_OFFER - Uitgebreid
Als de Component-ID in de componentinformatiebytes is ingesteld op 0xFE, worden de bits (15 bytes) opnieuw gedefinieerd om een aanbodopdracht van de host aan de apparaatfirmware aan te geven. Dit mechanisme maakt uitbreidbaarheid en een manier mogelijk voor de host om specifieke informatie aan het apparaat te verstrekken. Opdrachtpakketten voor aanbiedingen worden geretourneerd wanneer het onderdeel gereed is om te reageren op Geaccepteerd.
Opdracht 5.4.1
Als de Component ID in de bytes van de componentinformatie is ingesteld op 0xFE, worden de vier DWORDs als volgt opnieuw gedefinieerd:
Tabel 5.4-1 FIRMWARE_UPDATE_OFFER - Uitgebreide opdrachtindeling
5.4.1.1 Component
Tabel 5.4-2 FIRMWARE_UPDATE_OFFER - Uitgebreid opdrachtpakket - Opdracht - Onderdeelindeling
De bits van de component-byte worden beschreven in deze tabel.
Tabel 5.4-3 FIRMWARE_UPDATE_OFFER - Uitgebreide opdracht - Onderdeel-bits
| Bit-offset | Veld | Grootte | Beschrijving |
|---|---|---|---|
| 0 | Opdrachtcode | 8 | Deze waarde geeft het type opdracht aan. Deze waarde is geen bitmasker en kan slechts een van de mogelijke waarden zijn die worden beschreven in tabel 5,4-4. |
| 8 | Gereserveerd. | 8 | Gereserveerd. Niet gebruiken. |
| 16 | Onderdeel-id | 8 | Ingesteld op 0xFE. |
| 24 | Teken | De host voegt een uniek token in het aanbiedingspakket voor het onderdeel in. Dit token moet worden geretourneerd door het onderdeel in het antwoord van de aanbieding. |
Tabel 5.4-4 FIRMWARE_UPDATE_OFFER - Uitgebreide opdracht - Opdrachtcodewaarden
| Toestand | Naam | Beschrijving |
|---|---|---|
| 0x01 | BIEDEN_MELDEN_BIJ_GEREED | Verzonden door de host als de aanbieding eerder is afgewezen door het onderdeel. |
| 0x02 - 0xFF | Gereserveerd | Gereserveerd |
5.4.1.2 Gereserveerd B7 - B4
Gereserveerd. Niet gebruiken.
5.4.1.3 Gereserveerde B11 - B8
Gereserveerd. Niet gebruiken.
5.4.1.4 Gereserveerde B15 - B12
Gereserveerd. Niet gebruiken.
5.4.2 Antwoord
Het FIRMWARE_UPDATE_OFFER - aanbodopdrachtreactie van het apparaat wordt mogelijk niet direct ontvangen. Antwoord wordt als volgt gedefinieerd.
Tabel 5.4-5 FIRMWARE_UPDATE_OFFER - Antwoordindeling voor uitgebreid opdrachtpakket
5.4.2.1 Token
Tabel 5.4-6 FIRMWARE_UPDATE_OFFER- Opdrachtpakketantwoord aanbieden - Tokenindeling
De bits van de token-byte worden beschreven in deze tabel.
Tabel 5.4-7 FIRMWARE_UPDATE_OFFER - Opdrachtantwoord bieden - Token-bits
| Bit-offset | Veld | Grootte | Beschrijving |
|---|---|---|---|
| 0 | Gereserveerd | 8 | Gereserveerd. Niet gebruiken. |
| 8 | Gereserveerd | 8 | Gereserveerd. Niet gebruiken. |
| 16 | Gereserveerd | 8 | Gereserveerd. Niet gebruiken. |
| 24 | Teken | 8 | Token om de host te identificeren. |
5.4.2.2 Gereserveerd B7 - B4
Gereserveerd. Niet gebruiken.
5.4.2.3 Afwijsreden
Tabel 5.4-8 FIRMWARE_UPDATE_OFFER - RR-indeling voor antwoord op informatie over aanbod
De bits van de byte Afwijsreden worden beschreven in deze tabel.
Tabel 5.4-9 FIRMWARE_UPDATE_OFFER- Antwoord op Aanbodcommando - RR-code
| Bit-offset | Veld | Grootte | Beschrijving |
|---|---|---|---|
| 0 | RR-code | 8 | Deze waarde is afhankelijk van het veld Status. Zie tabel 5.4-10 voor mogelijke RR-codewaarden. |
| 8 | Gereserveerd | 24 | Gereserveerd. Niet gebruiken. |
De mogelijke waarden voor de RR Code-byte worden beschreven in deze tabel.
Tabel 5.4-10 FIRMWARE_UPDATE_OFFER- Opdrachtpakket aanbieden - RR-codewaarden
| RR-Code | Naam | Beschrijving |
|---|---|---|
| 0x00 | Weigering van firmware-aanbod: oude firmware | De aanbieding is geweigerd omdat de versie van de aangeboden firmware ouder of gelijk is aan de huidige firmware. |
| 0x01 | FIRMWARE_AANBOD_AFWIJZEN_INV_COMPONENT | De aanbieding is geweigerd omdat de aangeboden firmware niet van toepassing is op het platform van het product. Dit kan worden veroorzaakt door een niet-ondersteunde onderdeel-id of de aangeboden afbeelding is niet compatibel met de systeemhardware. |
| 0x02 | FIRMWARE_UPDATE_OFFER SWAP_PENDING | De onderdeelfirmware is bijgewerkt, maar er is een wissel naar de nieuwe firmware in behandeling. Er kan geen verdere verwerking van firmware-updates plaatsvinden totdat het wisselen is voltooid, meestal via een reset. |
| 0x03 - 0x08 | (Gereserveerd) | Gereserveerd. Niet gebruiken. |
| 0x09 - 0xDF | (Gereserveerd) | Gereserveerd. Niet gebruiken. |
| 0xE0 — 0xFF | (Leverancierspecifiek) | Deze waarden worden gebruikt door de ontwerpers van het protocol en de betekenis is leverancierspecifiek. |
5.4.2.4 Status
Tabel 5.4-11 FIRMWARE_UPDATE_OFFER - Indeling van de responstatus voor aanbieding van opdrachtpakket
De bits van de status byte worden beschreven in deze tabel.
Tabel 5.4-12 FIRMWARE_UPDATE_OFFER- Opdrachtpakketantwoord RR-code aanbieden
| Bit-offset | Veld | Grootte | Beschrijving |
|---|---|---|---|
| 0 | Status | 8 | Dit veld moet worden ingesteld op FIRMWARE_UPDATE_OFFER_ACCEPT. Dit geeft aan dat het onderdeel heeft besloten de aanbieding te accepteren. |
| 8 | Gereserveerd. | 24 | Gereserveerd. Niet gebruiken. |
5,5 FIRMWARE_UPDATE_CONTENT
De host verzendt deze opdracht naar de apparaatfirmware om de firmware-inhoud op te geven (dat wil gezegd de firmware-installatiekopie). Het volledige afbeeldingsbestand wordt niet verwacht in één opdracht te passen. De host moet de installatiekopie opsplitsen in kleinere blokken en elke opdracht verzendt één blok van de installatiekopie tegelijk.
Met elke opdracht geeft de host aanvullende informatie aan, of dit het eerste blok, laatste blok, enzovoort, van de firmware is. Het primaire onderdeel van de apparaatfirmware accepteert elk blok van de binnenkomende firmware-installatiekopieën, slaat deze op in het geheugen en moet afzonderlijk reageren op elke opdracht.
Wanneer het primaire onderdeel het laatste blok ontvangt, valideert het onderdeel de volledige firmware-installatiekopieën (CRC-controle, handtekeningvalidatie). Op basis van de resultaten van deze controles wordt een geschikt antwoord (mislukt of geslaagd) geretourneerd voor het laatste blok.
Opdracht 5.5.1
Opdrachtindeling tabel 5.5-1 FIRMWARE_UPDATE_CONTENT
5.5.1.1 Koptekst (B7 - B0)
Tabel 5.5-2 FIRMWARE_UPDATE_CONTENT opdrachtkopindeling
De bits van de FIRMWARE_UPDATE_CONTENT Header worden beschreven in deze tabel.
Tabel 5.5-3 FIRMWARE_UPDATE_CONTENT HEADER_BITS
| Bit-offset | Veld | Grootte | Beschrijving |
|---|---|---|---|
| 0 | Vlaggen | 8 | Dit veld bevat extra informatie over de opdracht. Deze waarde is een masker van vlaggen die moeten worden gebruikt voor de gegevensoverdracht. De mogelijke waarden worden beschreven in tabel 5,5-4. |
| 8 | Gegevenslengte | 8 | De lengte van het toepasselijke gegevensveld dat het aantal te schrijven bytes aangeeft. Gezien de grootte van deze opdracht is de maximaal toegestane waarde voor de lengte 52 bytes. |
| 16 | Volgnummer | 16 | Deze waarde wordt gemaakt door de host en is uniek voor elk inhoudspakket dat wordt uitgegeven. Het onderdeel moet het volgnummer retourneren in de reactie op deze aanvraag. |
| 32 | Firmwareadres | 32 | Little Endian (LSB First) Adres waarop de gegevens geschreven moeten worden. Het adres is gebaseerd op 0. De firmware gebruikt dit als een offset om, indien nodig, het adres te bepalen wanneer de afbeelding in het geheugen wordt geplaatst. |
De mogelijke waarden voor de Vlaggen-byte worden in deze tabel beschreven.
Tabel 5.5-4 FIRMWARE_UPDATE_OFFER - Aanbiedingsopdrachtpakket - Vlagwaarden
| Vlag | Naam | Beschrijving |
|---|---|---|
| 0x80 | FIRMWARE_UPDATE_FLAG_FIRST_BLOCK | Deze vlag geeft aan dat dit het eerste blok van de firmware is. |
| 0x40 | FIRMWARE_UPDATE_FLAG_LAATSTE_BLOK | Deze vlag geeft aan dat dit het laatste blok van de firmware-installatiekopieën is en dat de installatiekopieën gereed zijn om te worden gevalideerd. Het is belangrijk dat de huidige firmware op de component validatie uitvoert op de volledige gedownloade firmware-afbeelding nadat dit blok is weggeschreven naar niet-vluchtig geheugen. |
5.5.1.2 Gegevens
Tabel 5.5-5 FIRMWARE_UPDATE_CONTENT Opdrachtgegevensindeling
De bits van de FIRMWARE_UPDATE_CONTENT Data worden beschreven in deze tabel.
Tabel 5.5-6 FIRMWARE_UPDATE_CONTENT Opdrachtgegevens Bits
| Bit-offset | Veld | Grootte | Beschrijving |
|---|---|---|---|
| 64 | Gegevens | Max. 52. | De bytematrix die moet worden geschreven. De host verzendt doorgaans blokken van 4 bytes op basis van productarchitectuur. Ongebruikte bytes aan het einde moeten opgevuld worden met nullen. |
5.5.2 Antwoord
Tabel 5.5-7 FIRMWARE_UPDATE_CONTENT Opdrachtantwoordindeling
5.5.2.1 Reeksnummer
Tabel 5.5-8 FIRMWARE_UPDATE_CONTENT Reactie - Volgnummer
De bits van het FIRMWARE_UPDATE_CONTENT-antwoord (3-0) worden in deze tabel beschreven.
Tabel 5.5-9 FIRMWARE_UPDATE_CONTENT - Opdracht - Antwoord-Bits
| Bit-offset | Veld | Grootte | Beschrijving |
|---|---|---|---|
| 0 | Volgnummer | 16 | Dit veld is het volgnummer dat door de host in de aanvraag is verzonden. |
| 16 | Gereserveerd | 16 | Gereserveerd. Niet gebruiken. |
5.5.2.2 Status
Tabel 5.5-10 FIRMWARE_UPDATE_CONTENT Antwoordstatusindeling
De bits van het FIRMWARE_UPDATE_CONTENT-antwoord (7-4) worden beschreven in deze tabel.
Tabel 5.5-11 FIRMWARE_UPDATE_OFFER - Antwoord - Statusbits
| Bit-offset | Veld | Grootte | Beschrijving |
|---|---|---|---|
| 0 | Status | 8 | Deze waarde geeft de statuscode aan die wordt geretourneerd door het apparaatonderdeel. Dit is geen bitwise en kan een van de waarden zijn die worden beschreven in tabel 5,5-12. |
| 8 | Gereserveerd | 24 | Gereserveerd. Niet gebruiken. |
De mogelijke waarden voor de status-byte worden beschreven in deze tabel.
Tabel 5.5-12 FIRMWARE_UPDATE_OFFER- Antwoord - Statuscodewaarden
| Vlag | Naam | Beschrijving |
|---|---|---|
| 0x00 | Firmware-update geslaagd | De aanvraag is voltooid. |
| 0x01 | FOUT_BIJ_FIRMWARE_UPDATE_VOORBEREIDEN | Het onderdeel is niet voorbereid om de inhoud van de firmware te ontvangen. Als deze code wordt gebruikt, wordt deze code meestal gebruikt in een reactie op het eerste blok. Bijvoorbeeld: wisfout bij flash. |
| 0x02 | FIRMWARE_UPDATE_FOUT_SCHRIJVEN | Het verzoek kon de bytes niet schrijven. |
| 0x03 | FIRMWARE_UPDATE_ERROR_COMPLETE | De aanvraag kon de omzetting niet uitvoeren als reactie op FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
| 0x04 | FIRMWARE_UPDATE_FOUT_CONTROLEREN | De verificatie van het DWORD is mislukt in reactie op FIRMWARE_UPDATE_FLAG_VERIFY. |
| 0x05 | FIRMWARE_UPDATE_ERROR_CRC | CRC van de firmware-afbeelding is mislukt als reactie op FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
| 0x06 | FIRMWARE_UPDATE_ERROR_SIGNATURE | Verificatie van firmwarehandtekening is mislukt in reactie op FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
| 0x07 | FIRMWARE_UPDATE_FOUT_VERSIE | Verificatie van firmwareversie is mislukt in reactie op FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
| 0x08 | FIRMWARE_UPDATE_SWAP_PENDING (Firmware-update uitwisseling in afwachting) | De firmware is al bijgewerkt en er is een wissel in behandeling. Er kunnen geen verdere firmware-updateopdrachten worden geaccepteerd totdat het accessoire opnieuw is ingesteld. |
| 0x09 | Firmware-updatefout: Ongeldig adres | Firmware heeft een ongeldig doeladres gedetecteerd in de inhoud van de berichtgegevens. |
| 0x0A | FIRMWARE_UPDATE_ERROR_NO_OFFER | De FIRMWARE_UPDATE_OFFER Opdracht is ontvangen zonder eerst een geldige en geaccepteerde firmware-updateaanbieding te ontvangen. |
| 0x0B | FIRMWARE_UPDATE_FOUT_ONGELDIG | Algemene fout voor de FIRMWARE_UPDATE_OFFER-opdracht, zoals een ongeldige toepasselijke gegevenslengte. |
5.5.2.3 Gereserveerd B8 - B11
Gereserveerd. Niet gebruiken.
5.5.2.4 Gereserveerde B12 - B15
Gereserveerd. Niet gebruiken.
6 Bijlage 1: Voorbeeld van de opdrachtreeks voor het bijwerken van firmware-updates
6.1 Voorbeeld 1
Houd rekening met de volgende apparaatfirmware:
Primair onderdeel - Onderdeel-id 1 - Huidige firmwareversie 7.0.1
Subcomponent - Onderdeel-id 2 - Huidige firmwareversie 12.4.54
Subcomponent - Onderdeel-id 3 - Huidige firmwareversie 4.4.2
Subcomponent - Onderdeel-id 4 - Huidige firmwareversie 23.32.9
De host heeft deze drie firmware-installatiekopieën:
Onderdeel-id 1 - Firmwareversie 7.1.3
Onderdeel-id 2 - Firmwareversie 12.4.54
Onderdeel-id 3 - Firmwareversie 4.5.0
De volgorde is:
Hostaanbiedingen: Onderdeel-id 1 - Firmwareversie 7.1.3
Het primaire onderdeel accepteert de aanbieding
De host verzendt de installatiekopie van de firmware
Het primaire onderdeel accepteert firmware, valideert het
Hostaanbiedingen: Onderdeel-id 2 - Firmwareversie 12.4.54
Het primaire onderdeel weigert de aanbieding
Hostaanbiedingen: Onderdeel-id 3 - Firmwareversie 4.5.0
Het primaire onderdeel accepteert de aanbieding
De host verzendt de installatiekopie van de firmware
Het primaire onderdeel accepteert firmware, valideert het
Omdat alle aanbiedingen niet zijn afgewezen, worden alle aanbiedingen opnieuw afgespeeld door de host:
Hostaanbiedingen: Onderdeel-id 1 - Firmwareversie 7.1.3
Onderdeel weigert
Hostaanbiedingen: Onderdeel-id 2 - Firmwareversie 12.4.54
Onderdeel weigert
Hostaanbiedingen: Onderdeel-id 3 - Firmwareversie 4.5.0
Onderdeel weigert
6.2 Voorbeeld 2
Houd rekening met de volgende apparaatfirmware:
Primair onderdeel - Onderdeel-id 1 - Huidige firmwareversie 7.0.1
Subcomponent - Onderdeel-id 2 - Huidige firmwareversie 12.4.54
Subcomponent - Onderdeel-id 3 - Huidige firmwareversie 7.4.2
Subcomponent - Onderdeel-id 4 - Huidige firmwareversie 23.32.9
De host heeft deze drie firmware-installatiekopieën:
Onderdeel-id 1 - Firmwareversie 8.0.0
Onderdeel-id 2 - Firmwareversie 12.4.54
Onderdeel-id 3 - Firmwareversie 9.0.0
Bovendien vereist de implementatie dat de firmwareversie van de subonderdelen niet kleiner mag zijn dan de firmwareversie die wordt uitgevoerd op het primaire onderdeel. De host is niet op de hoogte van deze vereiste en up-to is het primaire onderdeel om aan deze regel te voldoen.
De volgorde is:
Hostaanbiedingen: Onderdeel-id 1 - Firmwareversie 8.0.0
Primaire component wordt geweigerd (omdat onderdeel-id 3 nog niet is bijgewerkt)
Hostaanbiedingen: Onderdeel-id 2 - Firmwareversie 12.4.54
Primaire component weigert
Hostaanbiedingen: Onderdeel-id 3 - Firmwareversie 9.0.0
Het primaire onderdeel accepteert aanbieding
De host verzendt de installatiekopie van de firmware
Het primaire onderdeel accepteert firmware, valideert het
Omdat alle aanbiedingen niet zijn afgewezen, worden alle aanbiedingen opnieuw afgespeeld door de host
Hostaanbiedingen: Onderdeel-id 1 - Firmwareversie 8.0.0
Het primaire onderdeel accepteert aanbieding
De host verzendt de installatiekopie van de firmware
Het primaire onderdeel accepteert firmware, valideert het
Hostaanbiedingen: Onderdeel-id 2 - Firmwareversie 12.4.54
Primaire component weigert
Hostaanbiedingen: Onderdeel-id 3 - Firmwareversie 9.0.0
Primaire component afgekeurd