Protokollspecifikation för komponentuppdatering av inbyggd programvara (CFU)
Den här specifikationen beskriver ett allmänt HID-protokoll för uppdatering av inbyggd programvara för komponenter som finns på en dator eller tillbehör. Specifikationen gör det möjligt för en komponent att acceptera inbyggd programvara utan att avbryta enhetsåtgärden under en nedladdning. Specifikationen stöder konfigurationer där komponenten som accepterar den inbyggda programvaran kan ha underkomponenter, som kräver separata avbildningar av inbyggd programvara. Specifikationen gör det möjligt för komponenten att bestämma om den inbyggda programvaran ska accepteras. Den fungerar också som en optimering eftersom avbildningen av den inbyggda programvaran endast skickas till komponenten om den kan eller är redo att acceptera den.
Not
CFU är tillgängligt i Windows 10 version 2004 (Windows 10 maj 2020 Update) och senare versioner.
Innehåll
- 1 Introduktion
- 2 Maskinvaruarkitektur som stöds
- 3 protokollkrav
-
4 CFU-protokollöversikt
-
4.1-kommandosekvens för uppdatering av inbyggd programvara
- 4.1.1 Status: Värdinitierat Meddelande
- 4.1.2 Tillstånd: OFFER_INFO_START_OFFER_LIST Meddelande
- 4.1.3 Tillstånd: Skicka FIRMWARE_UPDATE_OFFER Kommando
- 4.1.4 Tillstånd: Skicka inbyggd programvara
- 4.1.5 Beslutstillstånd: Finns det fler erbjudanden
- 4.1.6 Tillstånd: OFFER_INFO_END_OFFER_LIST Notifiering
- 4.1.7 Beslutsstatus: Uppspelningserbjudandelista
- 4.1.8 Tillstånd: Enheten är upptagen
-
4.1-kommandosekvens för uppdatering av inbyggd programvara
- 5 CFU-protokollpaketformat
- 6 Bilaga 1: Exempel på programmeringskommandosekvens för uppdatering av inbyggd programvara
Tabeller
Tabell 5.1–1 "GET_FIRMWARE_VERSION Svarslayout"
Tabell 5.1-2 GET_FIRMWARE_VERSION Svar – Sidhuvudlayout
tabell 5.1–3 GET_FIRMWARE_VERSION svar – sidhuvudbitar
Tabell 5.1-4 GET_FIRMWARE_VERSION Svar – Layout för komponentversion och egenskaper
Tabell 5.1-5 GET_FIRMWARE_VERSION Svar – Komponentversion och Egenskaper Bitar
Tabell 5.2-1 FIRMWARE_UPDATE_OFFER Kommandolayout
Tabell 5.2-2 FIRMWARE_UPDATE_OFFER Kommando – Layout för komponentinformation
Tabell 5.2-3 FIRMWARE_UPDATE_OFFER kommando – Komponentinformationsbitar
Table 5.2-4 FIRMWARE_UPDATE_OFFER Command – Versionslayout för inbyggd programvara
table 5.2-5 FIRMWARE_UPDATE_OFFER Command – Versionsbitar för inbyggd programvara
Tabell 5.2-6 FIRMWARE_UPDATE_OFFER Kommando – Leverantörsspecifik layout
Tabell 5.2-7 FIRMWARE_UPDATE_OFFER-kommando – Diverse och protokollversion
Tabell 5.2-8 FIRMWARE_UPDATE_OFFER Layout för svarstoken
tabell 5.2–9 FIRMWARE_UPDATE_OFFER svar – tokenlayout
Tabell 5.2–10 FIRMWARE_UPDATE_OFFER Svar – Tokenbitar
Tabell 5.2-11 FIRMWARE_UPDATE_OFFER Svar – Avvisa Orsakslayout
Tabell 5.2–12 FIRMWARE_UPDATE_OFFER – Avvisa orsaksbitarna
Tabell 5.2-13 FIRMWARE_UPDATE_OFFER Svar RR-kodvärden
Tabell 5.2-14 FIRMWARE_UPDATE_OFFER Layout för svarsstatus
tabell 5.2–15 FIRMWARE_UPDATE_OFFER svar – statusbitar
Tabell 5.2-16 FIRMWARE_UPDATE_OFFER Svarsstatusvärden
Tabell 5.3-1 FIRMWARE_UPDATE_OFFER – Informationskommandolayout
Tabell 5.3-2 FIRMWARE_UPDATE_OFFER – Informationskommando – Komponentlayout
Tabell 5.3-3 FIRMWARE_UPDATE_OFFER – Informationskommando – Komponentbitar
Tabell 5.3-4 FIRMWARE_UPDATE_OFFER – Informationskommando – Informationskodvärden
Tabell 5.3-5 FIRMWARE_UPDATE_OFFER – Layout för informationssvar
Tabell 5.3-6 FIRMWARE_UPDATE_OFFER– Layout för svarstoken för informationspaket
tabell 5.3-7 FIRMWARE_UPDATE_OFFER – Informationssvar – Tokenbitar
Tabell 5.3-8 FIRMWARE_UPDATE_OFFER – Informationssvar – RR-kodlayout
tabell 5.3–9 FIRMWARE_UPDATE_OFFER – Erbjudandeinformationssvar – RR-kodbitar
Tabell 5.3-10 FIRMWARE_UPDATE_OFFER – Informationssvar – RR-kodvärden
Tabell 5.3-11 FIRMWARE_UPDATE_OFFER – Layout för svarstatus på erbjudandeinformation
tabell 5.3–12 FIRMWARE_UPDATE_OFFER – Erbjudandeinformation – Svarsstatusbitar
Tabell 5.4-1 FIRMWARE_UPDATE_OFFER – Utökad Kommandolayout
Tabell 5.4-2 FIRMWARE_UPDATE_OFFER – Utökat kommandopaket – Kommando – Komponentlayout
tabell 5.4-3 FIRMWARE_UPDATE_OFFER – Utökat kommando – Komponentbitar
Tabell 5.4-4 FIRMWARE_UPDATE_OFFER – Utökat kommando – Kommandokodvärden
Tabell 5.4-5 FIRMWARE_UPDATE_OFFER – Layout för utökad kommandopaketsvar
Tabell 5.4-6 FIRMWARE_UPDATE_OFFER – Svar på erbjudandets kommandopaket – tokenlayout
tabell 5.4-7 FIRMWARE_UPDATE_OFFER – Erbjudandekommandosvar – Tokenbitar
Tabell 5.4-8 FIRMWARE_UPDATE_OFFER – RR-layout för erbjudandeinformationspaketsvar
tabell 5.4-9 FIRMWARE_UPDATE_OFFER – Svar på Erbjudandekommando – RR Code
Tabell 5.4-10 FIRMWARE_UPDATE_OFFER– Erbjudandekommandopaket – RR-kodvärden
Tabell 5.4-11 FIRMWARE_UPDATE_OFFER – Layout för svarsstatus för erbjudandekommandopaket
tabell 5.4-12 FIRMWARE_UPDATE_OFFER – RR-kod för erbjudandekommandopaket
Tabell 5.5-1 FIRMWARE_UPDATE_CONTENT Kommandolayout
tabell 5.5-2 FIRMWARE_UPDATE_CONTENT layout för kommandorubriker
Tabell 5.5–3 FIRMWARE_UPDATE_CONTENT Sidhuvud Bitar
Tabell 5.5-4 FIRMWARE_UPDATE_OFFER– Erbjudandekommandopaket – Flaggvärden
Tabell 5.5-5 FIRMWARE_UPDATE_CONTENT Kommandodata Layout
tabell 5.5–6 FIRMWARE_UPDATE_CONTENT kommandodatabitar
Tabell 5.5–7 FIRMWARE_UPDATE_CONTENT Layout för kommandosvar
tabell 5.5–8 FIRMWARE_UPDATE_CONTENT Svar – sekvensnummer
Tabell 5.5-9 FIRMWARE_UPDATE_CONTENT – Kommando – Svarbitar
Tabell 5.5–10 FIRMWARE_UPDATE_CONTENT Layout för svarsstatus
tabell 5.5-11 FIRMWARE_UPDATE_OFFER – Svar – Statusbitar
Tabell 5.5-12 FIRMWARE_UPDATE_OFFER– Svar – Statuskodvärden
1 Introduktion
Dagens datorer och tillbehör har interna komponenter som utför komplexa åtgärder. För att säkerställa en kvalitetsprodukt finns det ett behov av att ofta uppdatera beteendet för dessa enheter i senare utvecklingsstadier eller efter att de har levererats till kunderna. Uppdateringen kan åtgärda identifierade funktions- eller säkerhetsproblem eller ett behov av att lägga till nya funktioner. En stor del av den komplexa logiken finns i den inbyggda programvaran som körs på enheten, vilket är uppdateringsbart.
Den här specifikationen beskriver ett allmänt HID-protokoll för att uppdatera den inbyggda programvaran för komponenter som finns på en dator eller dess tillbehör. HID-implementeringen ligger utanför specifikationens omfattning.
Några av funktionerna i protokollet är:
Protokollet är baserat på HID – allestädes närvarande och har Windows in-box-stöd över olika sammankopplade bussar som USB och I2C. Därför kan samma programvarulösning (drivrutin) användas för att uppdatera den inbyggda programvaran för alla komponenter.
Not
Eftersom specifikationen är paketbaserad är det enkelt att anpassa den till scenarier som inte är HID-scenarier.
Specifikationen gör det möjligt för en komponent att acceptera inbyggd programvara utan att avbryta enhetsåtgärden under nedladdningen. Det ger användarna en bättre upplevelse eftersom de inte behöver vänta tills uppdateringsprocessen för den inbyggda programvaran har slutförts innan de kan återuppta andra uppgifter. Den nya inbyggda programvaran kan anropas i en enda atomisk åtgärd i taget som har minimal påverkan på användaren.
Specifikationen stöder konfigurationer där komponenten som accepterar den inbyggda programvaran kan ha underkomponenter, som kräver separata avbildningar av inbyggd programvara.
Not
Processen för en komponent som lämnar över den inbyggda programvaran till underkomponenten ligger utanför omfånget för den här specifikationen.
Specifikationen stöder konceptet med ett erbjudande och förlitar sig på den ansvariga komponenten för att avgöra huruvida firmware ska accepteras. Beslutet att acceptera ny inbyggd programvara är inte trivialt. Det kan finnas beroenden mellan den inbyggda programvarans typ och/eller version och den underliggande typen/versionen av maskinvaran som den nya inbyggda programvaran gäller för. Ett erbjudan fungerar också som en optimeringsmekanism eftersom firmwarebilden endast skickas till delkomponenten om den kan eller är redo att acceptera den.
1.1 Ordlista
Begrepp | Beskrivning |
---|---|
Komponent-ID | I en enhet med flera komponenter identifierar ett komponent-ID varje komponent unikt. |
CRC | Cyklisk redundanskontroll En icke-kryptografisk hashalgoritm som används för att producera ett sammandrag eller fingeravtryck av ett datablock. CRC används som en kontroll för att säkerställa att datablocket inte har ändrats sedan CRC beräknades. CRC är inte ofelbar men ger förtroende för att data har tagits emot korrekt. |
Apparat | En samling komponenter (en primär komponent och noll eller flera underkomponenter). Enheten är synlig för operativsystemet som en enda enhet. Värden interagerar med enheten, som vanligtvis är den primära komponenten. En dator kan ha flera enheter i den. När det gäller denna specifikation är kommunikationen till 2 olika enheter helt oberoende. |
Chaufför | En drivrutin som skrivs med hjälp av WDF-ramverket (Windows Driver Foundation). |
Inbyggd programvara | Koden som körs på den fysiska maskinvaran. Den inbyggda programvaran är uppdaterbar och finns vanligtvis i programmerbart minne som är associerat med maskinvaran. |
Hårdvara | En fysisk bit kisel på datorn. |
Primär komponent | En maskinvara på en dator och den inbyggda programvaran för den. I den här specifikationen är en komponent den entitet som behöver och accepterar uppdateringen av den inbyggda programvaran. |
Segment | En avbildning av inbyggd programvara för en komponent kan segmenteras i mindre segment. Varje segment är en liten avbildning av inbyggd programvara. |
Segment-ID | Om en inbyggd programvara för en komponent segmenteras i mindre segment är segment-ID den unika identifieraren för segmentet. |
Underskrift | En kryptografisk metod för att avgöra om avbildningen av den inbyggda programvaran har ändrats på otillåtet sätt. Signaturer är valfria men rekommenderas och ligger utanför den här specifikationens omfång. |
Delkomponenten | Beroende på maskinvaruarkitekturen kan inte alla komponenter vara synliga för operativsystemet, eftersom de kan vara anslutna nedströms till en komponent som är synlig för systemet. Dessa komponenter kallas för underkomponenter i den här specifikationen. |
TLC | HID-kollektion på toppnivå. |
Bevis | En identifierare för en värdsession. En värd skapar en token och skickar den i kommandon, och enheten returnerar den i svaret. Token kan användas för att serialisera vissa transaktioner eller för att identifiera att en session har förlorats och en annan startats. |
1.2 Omfång
1.2.1 Mål
En bussagnostisk lösning krävs för att undvika ett nytt protokoll för varje typ av buss. HID är allmänt förekommande och uppfyller det kravet.
Möjligheten att stödja uppdatering av inbyggd programvara för en enhet med flera komponenter, där en komponent fungerar som primär komponent och andra är underkomponenter som är anslutna till den primära komponenten. Varje komponent kräver sin egen inbyggda programvara med icke-triviala beroenden mellan varandra.
En vanlig drivrutinsmodell för att ladda ned avbildningen av den inbyggda programvaran till komponenten. Komponenten har sedan underkomponentspecifika algoritmer för vidarebefordring till underkomponenterna. Underkomponenterna kan också utföra giltighetskontroller på sin inbyggda programvara och skicka tillbaka resultaten till den primära komponenten.
Möjligheten att stödja uppdatering av inbyggd programvara medan enhetsåtgärd pågår.
Möjligheten att uppdatera/återställa den inbyggda programvaran i produktionsenheter via auktoriserade verktyg och uppdatera enheter på marknaden via Windows Update.
Flexibiliteten att stödja firmware under utveckling/för firmware på marknaden.
Möjligheten att segmentera en stor avbildning av inbyggd programvara i mindre segment för att göra det enklare för komponenten att acceptera avbildningen av inbyggd programvara.
Sådant som inte är mål
Definiera det interna formatet för avbildningen av den inbyggda programvaran: För värden är avbildningen av den inbyggda programvaran en uppsättning adress- och nyttolastposter.
Signera/kryptera/verifiera den godkända inbyggda programvaran: Den här specifikationen beskriver inte hur du signerar och krypterar avbildningar av inbyggd programvara. Det krävs att den aktuella förväntade programvaran som körs på komponenten validerar att programvaran som laddas ner är korrekt.
Definiera en mekanism för hur komponenten interagerar med underkomponenterna: Hostsystemet interagerar med enheten som en enda enhet, vanligtvis den primära komponenten. Komponenten måste fungera som en brygga för kommunikation relaterad till den inbyggda programvaran för underkomponenten.
2 Maskinvaruarkitektur som stöds
För att stödja en flexibel maskinvarudesign stöder protokollet en enhet med flera komponenter där varje komponent kräver en egen avbildning av inbyggd programvara. I designen är en komponent den primära komponenten och de beroende underkomponenterna är anslutna till den primära komponenten. Varje komponent beskrivs unikt av ett komponent-ID.
Enheten med flera komponenter är synlig för operativsystemet som en enda enhet. Värden interagerar bara med enheten, vanligtvis den primära komponenten, med hjälp av detta CFU-protokoll. Kommunikationen mellan komponenten och dess underkomponenter ligger utanför den här specifikationens omfång.
På en dator kan det finnas många olika enheter (där en enhet kan ha en eller flera komponenter där). I det här protokollet är kommunikationen till varje enhet oberoende. Varje enhet har en motsvarande instans av en värd.
3 Protokollkrav
I det här avsnittet visas de krav och metodtips som måste implementeras för att utnyttja det här protokollet:
Användning av atomiska avbildningar
En firmwarebild för en komponent används inte förrän hela firmwarebilden har laddats ner framgångsrikt. Om den inbyggda programvaran är uppdelad i flera segment får avbildningen inte användas förrän det slutliga segmentet tas emot från avsändaren. Integritetskontroller måste utföras på den slutliga avbildningen. Vi rekommenderar att transporten, som används för att leverera avbildningen av den inbyggda programvaran, har felkorrigerings- och återförsöksmekanismer för att undvika en upprepad nedladdning vid transportfel.
Uppdateringen av inbyggd programvara får inte avbryta enhetsåtgärden
Enheten som accepterar avbildningen av den inbyggda programvaran måste kunna användas under uppdateringen. Enheten måste ha extra minne för att lagra och verifiera den inkommande inbyggda programvaran, medan den aktuella inbyggda programvaran inte skrivs över.
Autentisering och integritet
Implementorn bestämmer vilka faktorer som utgör en autentisk avbildning av inbyggd programvara. Vi rekommenderar att komponentens nuvarande inbyggda programvara bör åtminstone verifiera CRC för den inkommande firmware-avbildningen. Den aktuella inbyggda programvaran bör också använda algoritmer för digital signatur eller andra felidentifieringsalgoritmer. Om verifieringen misslyckas avvisar den inbyggda programvaran uppdateringen. Återställning av fel
Om avbildningen av den inbyggda programvaran laddas ned och misslyckas får enheten inte anropa den nya inbyggda programvaran och fortsätta att fungera med den befintliga inbyggda programvaran. Värden kan försöka uppdatera igen. Frekvensen för återförsök är implementeringsspecifik.
Sekretess
Valfri. Ett segment för inbyggd programvara kan krypteras. Krypterings- och dekrypteringsteknikerna ligger utanför den här specifikationens omfång. Den här specifikationen behandlar nyttolasten för inbyggd programvara som en dataström, oavsett om den är krypterad.
Återgångsskydd
Återställningsprinciper tillämpas av den primära komponenten och är implementeringsspecifika. Den aktuella inbyggda programvaran på komponenten validerar inkommande avbildningar av inbyggd programvara mot interna principer, till exempel versionsnumret måste vara nyare, eller så kan versionstypen inte växlas från version till felsökning och så vidare. Protokollet tillåter meddelanden som anger att en uppdatering godkänns även om den bryter mot principer för återställning.
Översikt över 4 CFU-protokoll
CFU-protokollet är en uppsättning kommandon och svar som krävs för att skicka de nya avbildningarna av inbyggd programvara från värden till den enhet som den inbyggda programvaran är avsedd för.
På hög nivå itererar protokollet genom alla avbildningar av inbyggd programvara som ska skickas till enheten. För varje avbildning av inbyggd programvara erbjuder värden att skicka filen till enheten. Endast om enheten accepterar erbjudandet skickar värden filen.
För att stödja fall där en enhetsuppdateringsordning har beroenden kanske enheten inte accepterar vissa erbjudanden i det första passet, därför tillåter protokollet att värden skickar alla erbjudanden om inbyggd programvara till enheten tills alla beroenden har lösts.
4.1 Programmeringskommandosekvens för uppdatering av inbyggd programvara
Här är CFU-kommandosekvensen för uppdatering av firmware.
4.1.1 Tillstånd: Initierad avisering av värd
När värden initierar sig själv och har identifierat en uppsättning erbjudanden som den behöver skicka till enheten utfärdar värden ett OFFER_INFO_START_ENTIRE_TRANSACTION kommando för att ange för komponenten att värden nu har initierats. Syftet med det här kommandot är att meddela den aktuella enhetens firmware att en ny instans av värden är tillgänglig. Det här meddelandet är användbart när en tidigare värdinstans avslutas oväntat. Enheten måste slutföra det här kommandot med framgång.
4.1.2 Status: OFFER_INFO_START_OFFER_LIST Meddelande
I det här tillståndet utfärdar värden kommandot OFFER_INFO_START_OFFER_LIST för att indikera att det är redo att skicka erbjudandena till den aktuella enhetens firmware. Enhetens primära komponent måste slutföra det här kommandot med framgång.
Det här kommandot är användbart eftersom värden kan skicka alla erbjudanden till enheten mer än en gång.
4.1.3 Tillstånd: Skicka FIRMWARE_UPDATE_OFFER kommando
Värden skickar ett erbjudande till den primära komponenten (eller dess underkomponent) för att kontrollera om komponenten vill acceptera eller avvisa firmware. Erbjudandet innehåller alla nödvändiga metadata om firmwarebilden, så att den befintliga inbyggda programvaran på komponenten kan bestämma om den vill acceptera, vänta på, hoppa över eller avvisa erbjudandet.
Erbjudandet kan vara för den primära komponenten eller underkomponenten. Om komponenten kan acceptera erbjudandet förbereder den sig för att ta emot den inbyggda programvaran. Det kan handla om att förbereda en minnesbank för att ta emot den inkommande avbildningen av inbyggd programvara. Komponenten kanske inte accepterar erbjudandet, till exempel kanske komponenten redan har en nyare (eller samma) version av inbyggd programvara som värden avser att skicka. Mer information finns i exemplen som beskrivs i bilaga 1: Exempel på kommandosekvens för uppdatering av inbyggd programvara.
Även om ett erbjudande godkänns kan den primära komponenten fortfarande avvisa avbildningen av den inbyggda programvaran efter nedladdningen på grund av integritetsfel och/eller återställningskontroller mot den faktiska mottagna avbildningen. Komponenten måste kontrollera varje firmwarebilds egenskaper oberoende av information i erbjudandet.
Värden utfärdar kommandot FIRMWARE_UPDATE_OFFER för att meddela den primära komponenten om avbildningen av den inbyggda programvaran som värden tänker skicka.
Om komponenten accepterar erbjudandet, kommer den att ha statusen FIRMWARE_UPDATE_OFFER_ACCEPT och därmed acceptera erbjudandet.
Om enhetens inbyggda programvara är upptagen och den primära komponenten inte kan acceptera detta eller nästa erbjudande för närvarande, skickar den ett upptaget svar med FIRMWARE_UPDATE_OFFER_BUSY status.
Om den aktuella inbyggda programvaran är intresserad av erbjudandet kan den dock inte acceptera erbjudandet (till exempel på grund av ett beroende av en uppdatering som saknas för underkomponent) svarar den med en FIRMWARE_UPDATE_OFFER_SKIP som anger att den är intresserad av den här inbyggda programvaran, men kan inte acceptera den. Värden fortsätter sedan till nästa erbjudande och måste erbjuda den här inbyggda programvaran igen senare.
Om den aktuella inbyggda programvaran inte är intresserad av erbjudandet (till exempel är det en äldre version) svarar den med en FIRMWARE_UPDATE_OFFER_REJECT status som ger lämplig avvisningsorsak. Den här statusen anger inte att värden inte kan skicka det här erbjudandet igen i framtiden. Värden skickar vanligtvis varje erbjudande när den initierar eller åter skickar listan över erbjudanden till enheten (se tillståndet OFFER_INFO_START_OFFER_LIST-meddelande).
4.1.4 Tillstånd: Skicka firmware
I det här tillståndet börjar värden skicka avbildningen av inbyggd programvara till den primära komponenten, för vilken komponenten tidigare har accepterat erbjudandet.
Eftersom innehållet i firmware-avbildningen sannolikt kommer att överskrida nyttolastgränsen för ett enda kommando, delar värden upp dessa avbildningar i paket. Värden skickar varje paket sekventiellt i ett separat FIRMWARE_UPDATE CONTENT-kommando. Den primära komponenten måste generera ett svarspaket för varje kommando.
Varje FIRMWARE_UPDATE CONTENT-kommando beskriver en offsetadress som inkluderar en del av firmware. Komponenten använder förskjutningen för att fastställa adressen där den partiella nyttolasten för inbyggd programvara måste lagras. Enheten skriver innehållet till en lämplig plats och bekräftar kommandot genom att skicka ett svar.
För det första paketet som värden (host) skickar anger den flaggan FIRMWARE_UPDATE_FLAG_FIRST_BLOCK, vilket visar för enheten att detta är det första paketet i firmware-bilden. Om enheten redan inte har förberett sig för att ta emot den inbyggda programvaran kan den göra det just nu.
För det sista paketet skickar värden, den anger flaggan FIRMWARE_UPDATE_FLAG_LAST_BLOCK.
När den aktuella inbyggda programvaran på enheten har skrivit den partiella nyttolasten för inbyggd programvara som ingår i det här kommandot måste den utföra verifierings- och autentiseringskontroller på den inkommande avbildningen av inbyggd programvara innan ett svar skickas. Detta omfattar minimalt:
En CRC-kontroll för att verifiera integriteten för hela avbildningen av inbyggd programvara.
Om CRC-kontrollen lyckas kan du välja att valfritt verifiera en signatur för den inkommande filen.
Efter den valfria signaturkontrollen görs en versionskontroll för att säkerställa att den nya firmware-versionen är samma eller nyare än den befintliga firmware-versionen.
Om den inkommande avbildningen av inbyggd programvara delades in i mindre segment är det upp till den aktuella inbyggda programvaran att avgöra om det är det sista segmentet i avbildningen av den inbyggda programvaran och därefter inkludera alla segment som en del av valideringen.
Om de föregående kontrollerna godkänns, kan den aktuella inbyggda programvaran ställa in enheten för att växla till den nya bilden vid nästa återställning och rapportera framgång till värddatorn. Komponenten initierar vanligtvis inte någon självåterställning. Detta för att förhindra störningar i programvara, inbyggd programvara, maskinvaruentiteter som komponenten interagerar med. Det är dock inte ett krav och kan variera beroende på implementeringen.
Om verifieringsstegen misslyckas får den inbyggda programvaran inte konfigurera en swapfil vid nästa återställning och måste signalera ett fel till värden.
4.1.5 Beslutstillstånd: Finns det fler erbjudanden
I det här tillståndet avgör värdenheten om det finns fler erbjudanden att skicka till enheten.
4.1.6 Tillstånd: OFFER_INFO_END_OFFER_LIST meddelande
Det här tillståndet uppnås när host har skickat alla erbjudanden till den primära komponenten i den nuvarande enhetens inbyggda programvara. Värden skickar kommandot OFFER_INFO_END_OFFER_LIST för att ange att den har skickat alla erbjudanden till komponenten.
Enheten måste slutföra det här kommandot med framgång.
4.1.7 Beslutstillstånd: Lista över återuppspelningserbjudande
Värden avgör om det är nödvändigt att skicka om erbjudandena. Det kan inträffa om den primära komponenten tidigare hade hoppat över vissa erbjudanden och accepterat vissa erbjudanden. Värden måste spela upp erbjudandelistan igen.
Det kan finnas annan implementeringsspecifik logik som kan resultera i ett beslut att spela upp erbjudandelistan igen.
4.1.8 Tillstånd: Enheten är upptagen
Det här tillståndet innebär att en enhet returnerade ett upptaget svar på ett erbjudande.
Värden skickar ett OFFER_NOTIFY_ON_READY-kommando, som enheten inte svarar på med godkännande förrän den är fri.
5 CFU-protokollpaketformat
CFU-protokollet implementeras som en uppsättning kommandon och svar. Protokollet är sekventiellt. För varje kommando som värden skickar till en komponent förväntas komponenten svara, såvida inget annat uttryckligen anges i denna specifikation. Värden skickar inte nästa kommando förrän ett giltigt svar har tagits emot för föregående kommando som skickades.
Om komponenten inte svarar inom en tidsperiod eller skickar ett ogiltigt svar kan värdenheten starta om processen från början. Det här protokollet definierar inte ett specifikt timeout-värde.
Det finns kommandon för att hämta versionsinformationen för den aktuella inbyggda programvaran på komponenten. för att skicka erbjudandet och skicka avbildningen av den inbyggda programvaran.
Dock behöver värden inte hålla tillbaka ett erbjudande baserat på den primära komponentens svar om den efterfrågade versionsinformationen. Informationen kan identifieras för loggning eller andra ändamål.
5.1 GET_FIRMWARE_VERSION
Hämtar den eller de aktuella versionerna av den inbyggda programvaran för den primära komponenten (och dess underkomponenter). Kommandot har inga argument.
5.1.1 Kommando
Det här kommandot skickas av värden för att fråga efter versionerna av aktuell inbyggd programvara på den primära komponenten (och dess underkomponenter). Värden kan använda denna för att bekräfta om den inbyggda programvaran har uppdaterats framgångsrikt. När du tar emot det här kommandot svarar den primära komponenten med den inbyggda programvarans version för sig själv och alla underkomponenter.
5.1.2 Svar
Komponenten svarar med den inbyggda programvarans version av den primära komponenten och underkomponenterna. Svarsstorleken är 60 byte som tillåter versionsinformation för upp till sju komponenter (en primär och upp till sex underkomponenter).
Tabell 5.1-1 GET_FIRMWARE_VERSION svarformat
5.1.2.1 Rubrik
Tabell 5.1-2 GET_FIRMWARE_VERSION svar – rubriklayout
Rubriken för svaret innehåller följande information.
Tabell 5.1-3 GET_FIRMWARE_VERSION Svar – Huvudbitar
Bitförskjutning | Fält | Storlek | Beskrivning |
---|---|---|---|
0 | Antal komponenter | 8 | Antalet nedladdningsbara komponenter som hanteras via den här mekanismen för den här komponenten. Antalet komponenter avgör den maximala tabellstorleken. För närvarande stöds upp till 7 komponenter för att säkerställa att svaret får plats inom de tillåtna 60 byteen. |
8 | Rsvd | 16 | Reserverade fält. Avsändaren måste ange dessa till 0. Mottagaren måste ignorera det här värdet. |
24 | Protokollversion | 4 | Revisionsbitarna för firmware-uppdatering representerar den nuvarande versionen av FW Update Protocol som används i transportlagret. För gränssnittet som definieras häri måste FW Update Revision vara 0010b. |
28 | Rsvd | 3 | Reserverade fält. Avsändaren måste ange dessa till 0. Mottagaren måste ignorera det här värdet. |
31 | E | 1 | Tilläggsflaggan är en framtida protokollkrok för att möjliggöra att ytterligare komponenter rapporteras. |
5.1.2.2 Komponentversion och egenskaper
För varje komponent används två DWORD:er för att beskriva egenskaperna för komponenten upp till 7 komponenter. Om komponentantalet i rubriken är mindre än 7 måste det oanvända DWORDS i slutet av svaret anges till 0.
Tabell 5.1-4 GET_FIRMWARE_VERSION svar – Layout för komponentversion och egenskaper
Varje komponentspecifik information beskrivs i två DWORD:er enligt följande:
Tabell 5.1-5 GET_FIRMWARE_VERSION svar – Komponentversion och egenskaper bitar
Bitförskjutning | Fält | Storlek | Beskrivning |
---|---|---|---|
0 | Version av inbyggd programvara | 32 | Returnerar versionen av den aktuella inbyggda programvaran för komponenten. Den här specifikationen kräver inte något specifikt format för versionen av den inbyggda programvaran. Se avsnittet Version av inbyggd programvara för riktlinjer. |
32 | Bank | 2 | Valfri. Beroende på arkitekturen kan komponentmaskinvaran ha flera banker där den inbyggda programvaran kan lagras. Beroende på implementeringen kan avsändaren ange den bank där den inbyggda programvaran för närvarande finns. Det här fältet är villkorsstyrd obligatoriskt – stöd är valfritt, men får inte användas för något annat ändamål. |
34 | Reserverad | 2 | Reserverade fält. Avsändaren måste ange dessa till 0. Mottagaren måste ignorera det här värdet. |
36 | Leverantörsspecifik | 4 | Leverantörsspecifikt fält som kan användas på ett implementeringsspecifikt sätt. En leverantör kan använda dessa bitar för att koda information, till exempel: – Typ av inbyggd programvara: Förhandsversion/självhostad/produktion; felsökning/konsumentversion - Utvecklingsfas – Produkt-ID, för att förhindra att komponenter tar emot inbyggd programvara för andra produkter med samma uppdateringsprotokoll. |
40 | Komponent-ID | 8 | En unik identifierare för komponenten. |
48 | Leverantörsspecifik | 16 | Leverantörsspecifikt fält som kan användas på ett implementeringsspecifikt sätt. |
5.1.3 Mappning till HID
Detta implementeras som en HID Get Feature-begäran med en svarsstorlek på 60 byte, utöver rapport-ID. Funktionsrapportens längd kan innehålla hela GET_FIRMWARE_VERSION-svaret. Det finns inga data som är associerade med förfrågan om hämta funktion från värddatorn.
5.2 FIRMWARE_UPPDATERINGS_ERBJUDANDE
Avgör om den primära komponenten accepterar eller avvisar en inbyggd programvara.
5.2.1 Kommando
Värden skickar det här kommandot till komponenten för att avgöra om den accepterar eller avvisar en firmware. Värden måste skicka ett erbjudande, och komponenten måste acceptera erbjudandet innan värden kan skicka firmware.
FIRMWARE_UPDATE_OFFER-kommandopaketet definieras på följande sätt.
Tabell 5.2-1 FIRMWARE_UPDATE_OFFER kommandots layout
5.2.1.1 Komponentinformation
Tabell 5.2-2 FIRMWARE_UPDATE_OFFER kommando – Layout för komponentinformation
Bitarna i bytet för komponentinformation beskrivs i den här tabellen.
Tabell 5.2-3 FIRMWARE_UPDATE_OFFER kommando – Komponentinformationsbitar
Bitförskjutning | Fält | Storlek | Beskrivning |
---|---|---|---|
0 | Segmentnummer | 8 | Det här fältet används om den inbyggda programvaran för en komponent segmenteras i mindre segment. Om det här värdet används anger det segment som ingår i det efterföljande nyttolast paketet. Till exempel – om avbildningen av den inbyggda programvaran för komponenten är mycket stor och den primära komponenten bara kan ta mindre delar av avbildningen åt gången, kan det här fältet användas för att indikera att det här erbjudandet gäller för segmentet i-th i den fullständiga avbildningen. Ett separat erbjudande kan skickas till den primära komponenten som innehåller i+1:e delen av bilden och så vidare. |
8 | Reserverad | 6 | Reserverade fält. Avsändaren måste ange dessa till 0. Mottagaren måste ignorera det här värdet. |
14 | Jag | 1 | Framtvinga omedelbar återställning (I) – Det här bitvärdet används för att indikera för komponenten att omedelbart återställa sig själv när nedladdningen av den inbyggda programvaran har slutförts och verifierats för att omedelbart anropa den. – Den här flaggan är avsedd för utvecklingsfasen. |
15 | V | 1 | Framtvinga ignorera version (V) – Den här flaggan är avsedd för en förhandsversion eller en felsökningsavbildning av inbyggd programvara. Det anger för komponenten att inte avvisa den inbyggda programvaran med hänsyn till dess version. – Den här flaggan är avsedd för utvecklingsfasen. Den kan användas för att avsiktligt återställa till en tidigare version av inbyggd programvara. – Den här flaggan bör ignoreras av produktionsfirmware. |
16 | Komponent-ID | 8 | Bytet används för scenarier med flera komponenter. Det här fältet kan användas för att identifiera den underkomponent som erbjudandet är avsett för. Om det inte används ska värdet vara 0. Möjliga värden för komponent-ID:t är följande: 1 – 0xDF: Giltig 0xE0 – 0xFD: Reserverade. Använd inte. 0xFF: Erbjudandet är ett informationspaket för specialerbjudanden. Se FIRMWARE_UPDATE_OFFER information för detaljer. 0xFE : Erbjudandet är ett kommandopaket för specialerbjudande. Mer information finns i avsnittet FIRMWARE_UPDATE_OFFER Utökad. |
24 | Bevis | 8 | Värden infogar en unik token i erbjudandepaketet för komponenten. Den här tokenen måste returneras av komponenten i erbjudandets svar. Detta är användbart om komponenten behöver skilja mellan de olika värdarna/typerna av värdar. Exakta värden som ska användas är implementeringsspecifika. Ett värde kan till exempel användas för en drivrutin och ett annat för programmet. Detta gör att den aktuella enhetens inbyggda programvara kan ta hänsyn till potentiella flera avsändare av CFU-kommandon. En möjlig implementering kan vara att acceptera det första CFU-kommandot och avvisa alla andra kommandon med olika token tills de första CFU-transaktionerna har slutförts. |
5.2.1.2 Version av inbyggd programvara
Dessa fyra byte representerar 32-bitarsversionen av den inbyggda programvaran. Formatet för versionen av den inbyggda programvaran är inte obligatoriskt enligt den här specifikationen. Följande rekommenderas.
Tabell 5.2-4 FIRMWARE_UPDATE_OFFER kommando – Versionslayout för inbyggd programvara
Formatet för versionen av den inbyggda programvaran är inte obligatoriskt enligt den här specifikationen, men följande är en rekommenderad riktlinje.
Tabell 5.2-5 FIRMWARE_UPDATE_OFFER Kommando – Firmwareversionsbitar
Bitförskjutning | Fält | Storlek | Beskrivning |
---|---|---|---|
0 | Variant | 8 | Det här fältet kan beskrivas för att skilja mellan en förhandsversion av inbyggd programvara och produktionsprogramvara. Det kan tyda på vilken typ av signatur som används för att signera den inbyggda programvaran. |
8 | Mindre version | 16 | Det här fältvärdet bör uppdateras för varje version av den inbyggda programvaran. Det här fältvärdet bör uppdateras för varje version av den inbyggda programvaran. |
24 | Huvudversion | 8 | Det här fältet är huvudversionen av avbildningen av den inbyggda programvaran. Det här fältet bör uppdateras när du skickar en ny produktrad, större nya uppdateringar av den inbyggda programvaran och så vidare. |
5.2.1.3 Leverantörsspecifik
Dessa fyra byte kan användas för att koda anpassad information i erbjudandet som är specifik för leverantörsimplementering.
5.2.1.4 Misc. och Protokollversion
Dessa fyra byte kan användas för att koda anpassad information i erbjudandet som är specifik för leverantörsimplementering.
Tabell 5.2-6 FIRMWARE_UPDATE_OFFER kommando – Leverantörsspecifik layout
Bitarna i den leverantörsspecifika byte beskrivs i den här tabellen.
Tabell 5.2-7 FIRMWARE_UPDATE_OFFER kommando – Diverse och protokollversion
Bitförskjutning | Fält | Storlek | Beskrivning |
---|---|---|---|
0 | Protokollversion | 4 | Det här fältet måste anges till 0010b som anger att värden/erbjudandet motsvarar version 2 av CFU-protokollet. |
4 | Reserverad | 4 | Reserverad. Använd inte. |
8 | Reserverad | 8 | Reserverad. Använd inte. |
16 | Leverantörsspecifik | 16 | Det här fältet kan användas för att koda anpassad information i erbjudandet som är specifik för leverantörsimplementering. |
5.2.2 Svar
Paketet FIRMWARE_UPDATE_OFFER response definieras på följande sätt.
Layout för svarstoken i tabell 5.2-8 FIRMWARE_UPDATE_OFFER
5.2.2.1-token
Tabell 5.2-9 FIRMWARE_UPDATE_OFFER svar – tokenlayout
Bitarna i tokenbytet beskrivs i den här tabellen.
Tabell 5.2-10 FIRMWARE_UPDATE_OFFER svar – tokenbitar
Bitförskjutning | Fält | Storlek | Beskrivning |
---|---|---|---|
0 | Reserverad | 8 | Reserverad. Använd inte. |
8 | Reserverad | 8 | Reserverat. Använd inte. |
16 | Reserverad | 8 | Reserverad. Använd inte. |
24 | Bevis | 8 | Token för att identifiera värden. |
5.2.2.2 Reserverad (B7 - B4)
Reserverad. Använd inte.
5.2.2.3 Orsak till avslag (RR)
Tabell 5.2-11 FIRMWARE_UPDATE_OFFER Svar – Avslagsorsak Layout
Tabell 5.2-12 FIRMWARE_UPDATE_OFFER-svar – Avvisningsorsaksbitar
Bitarna i bytet Avvisa orsak beskrivs i den här tabellen.
Bitförskjutning | Fält | Storlek | Beskrivning |
---|---|---|---|
0 | RR-kod | 8 | Den avvisande orsakskod som anger orsaken som tillhandahålls av komponenten för att avvisa erbjudandet. Det här värdet beror på fältet Status. En status till RR Code-mappning finns i Tabell 5.2-13. |
8 | Reserverad | 24 | Reserverat. Använd inte. |
Tabell 5.2-13 FIRMWARE_UPDATE_OFFER RR-svarskodvärden
Möjliga värden för RR Code-byte beskrivs i den här tabellen.
RR-kod | Namn | Beskrivning |
---|---|---|
0x00 | Avvisa gammal firmwareerbjudande | Erbjudandet avvisades eftersom versionen av den erbjudna inbyggda programvaran är äldre eller samma som den aktuella inbyggda programvaran. |
0x01 | FIRMWARE_ERBJUDANDE_AVVISNING_OGILTIG_KOMPONENT | Erbjudandet avvisades eftersom den erbjudna inbyggda programvaran inte är tillämplig på produktens plattform. Detta kan bero på att ett komponent-ID som inte stöds eller att den erbjudna avbildningen inte är kompatibel med systemmaskinvaran. |
0x02 | FIRMWARE_UPPDATERING_ERBJUDANDE BYTE_PÅGÅR | Komponentens inbyggda programvara har uppdaterats, men ett byte till den nya inbyggda programvaran väntar. Ingen ytterligare uppdatering av inbyggd programvara kan ske förrän växlingen har slutförts, vanligtvis via en återställning. |
0x03 - 0x08 | (Reserverad) | Reserverad. Använd inte. |
0x09 - 0xDF | (Reserverad) | Reserverat Använd inte. |
0xE0 - 0xFF | (Leverantörsspecifik) | Dessa värden används av protokollets designers och innebörden är leverantörsspecifik. |
5.2.2.4 Status
Tabell 5.2-14 FIRMWARE_UPDATE_OFFER layout för svarsstatus
Bitarna i statusbytet beskrivs i den här tabellen.
Tabell 5.2–15 FIRMWARE_UPDATE_OFFER svar – statusbitar
Bitförskjutning | Fält | Storlek | Beskrivning |
---|---|---|---|
0 | Status | 8 | Det här värdet anger komponentens beslut att acceptera, vänta, hoppa över eller avvisa erbjudandet. Komponenten anger orsaken till värdet i fältet RR Code. För en mappning från Status till RR-kod, se Tabell 5.2-16. |
8 | Reserverad | 24 | Reserverad. Använd inte. |
Möjliga värden för statusbyte beskrivs i den här tabellen.
Tabell 5.2-16 FIRMWARE_UPDATE_OFFER statusvärden för svar
Status | Namn | Beskrivning |
---|---|---|
0x00 | HOPPA ÖVER UPPDATERINGSERBJUDANDE AV FIRMWARE | Komponenten har valt att hoppa över erbjudandet. Värden måste erbjuda den igen senare. |
0x01 | ACCEPTERA_FIRMWAREUPPDATERING_ERBJUDANDE | Komponenten har beslutat att acceptera erbjudandet. |
0x02 | AVBÖJ UPPDATERING AV FIRMWARE | Komponenten har beslutat att avvisa erbjudandet. |
0x03 | Erbjudande om firmwareuppdatering pågår | Enheten är upptagen och värdenheten måste vänta tills enheten är redo. |
0x04 | FIRMWARE_UPPDATERING_ERBJUDANDE_KOMMANDO | Används när komponent-ID i byte för komponentinformation (se 5.1.2.1.1 Komponentinformation) är inställt på 0xFE. För en kommandokod inställd på begäran om OFFER_NOTIFY_ON_READY, anges att tillbehöret är redo att acceptera ytterligare erbjudanden. |
0xFF | FIRMVARUUPPDATERINGSKOMMANDO_INTE_STÖTT | Erbjudandebegäran känns inte igen. |
5.2.3 Mappning till HID Protocol
Meddelandet utfärdas till komponenten via mekanismen HID-utdatarapport med hjälp av det dedikerade HID-verktygets rapport-ID för uppdatering av inbyggd programvara. Den HID-verktygs-TLC som ska användas beskrivs i bilagan.
5.3 FIRMWARE_UPPDATERING_ERBJUDANDE – Information
Om komponent-ID:t i byte för komponentinformation (se komponentinformation) är inställt på 0xFF, omdefinieras bitar (15 byte) så att endast erbjudandeinformation anges, från värden till komponenten. Den här mekanismen gör det möjligt för utökningsbarhet och ett sätt för värden att tillhandahålla specifik information till enheten, till exempel Starterbjudandelista, Sluterbjudandelista, Starta hela transaktionen. Erbjudandeinformationspaket accepteras alltid omedelbart av komponenten.
5.3.1 Kommando
FIRMWARE_UPDATE_OFFER -Information-kommandopaketet definieras på följande sätt:
Tabell 5.3-1 FIRMWARE_UPDATE_OFFER – Informationskommandolayout
5.3.1.1 Komponent
Tabell 5.3-2 FIRMWARE_UPDATE_OFFER – Informationskommando – Komponentlayout
Bitarna i komponentbytet beskrivs i den här tabellen.
Tabell 5.3-3 FIRMWARE_UPDATE_OFFER – Informationskommando – Komponentbitar
Bitförskjutning | Fält | Storlek | Beskrivning |
---|---|---|---|
0 | Informationskod | 8 | Det här värdet anger typen av information. Det här värdet är inte en bitmask och kan bara vara ett av de möjliga värden som beskrivs i tabell 5.3-4. |
8 | Reserverad. | 8 | Reserverad. Använd inte. |
16 | Komponent-ID | 8 | Ange till 0xFF. |
24 | Bevis | Värden infogar en unik token i komponentens erbjudandepaket. Den här token måste returneras av komponenten i erbjudandesvaret. |
Tabell 5.3-4 FIRMWARE_UPDATE_OFFER – Informationskommando – Informationskodvärden
Status | Namn | Beskrivning |
---|---|---|
0x00 | ERBJUDANDE_INFO_START_HELA_TRANSAKTIONEN | Indikerar att värden är ny eller har laddats om och att hela bearbetning av erbjudanden (om)startar. |
0x01 | ERBJUDANDE_INFO_STARTA_ERBJUDANDELISTA | Anger början av erbjudandelistan från värden om tillbehöret har nedladdningsregler som är associerade med att säkerställa att en underkomponent uppdateras före en annan underkomponent i systemet. |
0x02 | ERBJUDANDE_INFO_SLUT_ERBJUDANDE_LISTA | Anger slutet på erbjudandelistan från värden. |
5.3.1.2 Reserverad B7 - B4
Reserverad. Använd inte.
5.3.1.3 Reserverad B11 - B8
Reserverad. Använd inte.
5.3.1.4 Reserverad B15 - B12
Reserverad. Använd inte.
5.3.2 Svar
Svaret FIRMWARE_UPDATE_OFFER – Erbjudandeinformationssvarspaket definieras på följande sätt.
Tabell 5.3-5 FIRMWARE_UPDATE_OFFER – Layout för informationssvar
5.3.2.1-token
Tabell 5.3-6 FIRMWARE_UPDATE_OFFER– Layout för svarstoken för informationspaket
Bitarna i tokenbytet beskrivs i den här tabellen.
Tabell 5.3-7 FIRMWARE_UPDATE_OFFER – Informationssvar – Tokenbitar
Bitförskjutning | Fält | Storlek | Beskrivning |
---|---|---|---|
0 | Reserverad | 8 | Reserverat. Använd inte. |
8 | Reserverad | 8 | Reserverad. Använd inte. |
16 | Reserverad | 8 | Bokad Använd inte. |
24 | Bevis | 8 | Token för att identifiera värden |
5.3.2.2 Reserverad B7 - B4
Reserverad. Använd inte.
5.3.2.3 Avvisningsorsak (RR)
Tabell 5.3-8 FIRMWARE_UPDATE_OFFER – Informationssvar – RR-kodlayout
Bitarna i bytet Avvisa orsak beskrivs i den här tabellen.
Tabell 5.3-9 FIRMWARE_UPDATE_OFFER – Svar på erbjudandeinformation – RR-kodbitar
Bitförskjutning | Fält | Storlek | Beskrivning |
---|---|---|---|
0 | RR-kod | 8 | Den avvisande orsakskod som anger orsaken som tillhandahålls av komponenten för att avvisa erbjudandet. Möjliga värden beskrivs i tabell 5.3-10. Det här värdet beror på fältet Status. |
8 | Reserverad | 24 | Reserverad. Använd inte. |
Möjliga värden för RR Code-byte beskrivs i den här tabellen.
Tabell 5.3-10 FIRMWARE_UPDATE_OFFER– Informationssvar – RR-kodvärden
RR-kod | Namn | Beskrivning |
---|---|---|
0x00 | Avvisa gammal firmware-erbjudande | Erbjudandet avvisades eftersom versionen av den erbjudna inbyggda programvaran är äldre eller samma som den aktuella inbyggda programvaran. |
0x01 | FIRMWARE_OFFER_REJECT_INV_COMPONENT | Erbjudandet avvisades eftersom den erbjudna inbyggda programvaran inte är tillämplig på produktens plattform. Detta kan bero på att ett komponent-ID som inte stöds eller att den erbjudna avbildningen inte är kompatibel med systemmaskinvaran. |
0x02 | Firmwareuppdateringserbjudande Byte pågår | Komponentens inbyggda programvara har uppdaterats, men ett byte till den nya inbyggda programvaran väntar. Ingen ytterligare firmware-uppdatering kan ske förrän växlingen har slutförts, vanligtvis via en återställning. |
0x03 - 0x08 | (Reserverad) | Reserverat. Använd inte. |
0x09 - 0xDF | (Reserverad) | Reserverad. Använd inte. |
0xE0 – 0xFF | (Leverantörsspecifik) | Dessa värden används av protokollets designers och innebörden är leverantörsspecifik. |
5.3.2.4 Status
Tabell 5.3-11 FIRMWARE_UPDATE_OFFER – Layout för svarsstatus för erbjudandeinformation
Bitarna i statusbytet beskrivs i den här tabellen.
Tabell 5.3-12 FIRMWARE_UPDATE_OFFER – Erbjudandeinformation – Svarsstatusbitar
Bitförskjutning | Fält | Storlek | Beskrivning |
---|---|---|---|
0 | Status | 8 | Det här fältet måste vara inställt på FIRMWARE_UPDATE_OFFER_ACCEPT. Detta indikerar att komponenten har beslutat att acceptera erbjudandet. |
8 | Reserverad. | 24 | Reserverad. Använd inte. |
5.4 FIRMWARE_UPDATE_OFFER – Utökad
Om komponent-ID:t i komponentinformationsbyten är inställt på 0xFE omdefinieras bitarna från de 15 byten för att indikera ett erbjudandekommando från värdenheten till enhetens inbyggda programvara. Den här mekanismen möjliggör utbyggbarhet och ett sätt för värdenheten att tillhandahålla specifik information till enheten. Erbjudandekommandopaket returneras när komponenten är redo att svara Accepterad.
5.4.1 kommando
Om komponent-ID:t i byte för komponentinformation är inställt på 0xFE omdefinieras de fyra DWORD:erna enligt följande:
Tabell 5.4-1 FIRMWARE_UPDATE_OFFER – Utökad kommandolayout
5.4.1.1 Komponent
Tabell 5.4-2 FIRMWARE_UPDATE_OFFER – Utökat kommandopaket – Kommando – Komponentlayout
Bitarna i komponentbytet beskrivs i den här tabellen.
Tabell 5.4-3 FIRMWARE_UPDATE_OFFER – Utökat kommando – Komponentbitar
Bitförskjutning | Fält | Storlek | Beskrivning |
---|---|---|---|
0 | Kommandokod | 8 | Det här värdet anger typ av kommando. Det här värdet är inte en bitmask och kan bara vara ett av de möjliga värden som beskrivs i tabell 5.4-4. |
8 | Reserverad. | 8 | Reserverad. Använd inte. |
16 | Komponent-ID | 8 | Ange till 0xFE. |
24 | Bevis | Värden infogar en unik token i erbjudandepaketet till komponenten. Den här token måste returneras av komponenten i erbjudandesvaret. |
Tabell 5.4-4 FIRMWARE_UPDATE_OFFER – Utökat kommando – Kommandokodsvärden
Status | Namn | Beskrivning |
---|---|---|
0x01 | ERBJUDANDE_INFORMERA_NÄR_KLAR | Skickas av värden om erbjudandet tidigare avvisades av komponenten. |
0x02 - 0xFF | Reserverad | Reserverad |
5.4.1.2 Reserverad B7 - B4
Reserverad. Använd inte.
5.4.1.3 Reserverad B11 - B8
Reserverad. Använd inte.
5.4.1.4 Reserverad B15 - B12
Reserverad. Använd inte.
5.4.2 Svar
Svaret FIRMWARE_UPDATE_OFFER – Erbjudandekommando från enheten kanske inte tas emot omedelbart. Svaret definieras på följande sätt.
Tabell 5.4-5 FIRMWARE_UPDATE_OFFER – Utökad svarslayout för kommandopaket
5.4.2.1-token
Tabell 5.4-6 FIRMWARE_UPDATE_OFFER – Erbjudandekommandopaketssvar – Tokenlayout
Bitarna i tokenbytet beskrivs i den här tabellen.
Tabell 5.4-7 FIRMWARE_UPDATE_OFFER – Erbjudandekommandosvar – Tokenbitar
Bitförskjutning | Fält | Storlek | Beskrivning |
---|---|---|---|
0 | Reserverad | 8 | Reserverad. Använd inte. |
8 | Reserverad | 8 | Reserverat. Använd inte. |
16 | Reserverad | 8 | Reserverad. Använd inte. |
24 | Bevis | 8 | Token för att identifiera värden. |
5.4.2.2 Reserverad B7 - B4
Reserverad. Använd inte.
5.4.2.3 Avvisa orsak
Tabell 5.4-8 FIRMWARE_UPDATE_OFFER – Layout för svar på erbjudandeinformationspaket RR
Bitarna i bytet Avvisa orsak beskrivs i den här tabellen.
Tabell 5.4-9 FIRMWARE_UPDATE_OFFER – Svar på kommandon för erbjudande – RR-kod
Bitförskjutning | Fält | Storlek | Beskrivning |
---|---|---|---|
0 | RR-kod | 8 | Det här värdet beror på fältet Status. Möjliga RR Code-värden finns i Tabell 5.4-10. |
8 | Reserverad | 24 | Reserverad. Använd inte. |
Möjliga värden för RR Code-byte beskrivs i den här tabellen.
Tabell 5.4-10 FIRMWARE_UPDATE_OFFER– Erbjudandekommandopaket – RR-kodvärden
RR-kod | Namn | Beskrivning |
---|---|---|
0x00 | AVVISA_ERBJUDANDE_OM_GAMMAL_FIRMWARE | Erbjudandet avvisades eftersom versionen av den erbjudna inbyggda programvaran är äldre eller samma som den aktuella inbyggda programvaran. |
0x01 | FIRMWARE_ERBJUDANDE_AVVISNING_INV_KOMPONENT | Erbjudandet avvisades eftersom den erbjudna inbyggda programvaran inte är tillämplig på produktens plattform. Detta kan bero på att ett komponent-ID som inte stöds eller att den erbjudna avbildningen inte är kompatibel med systemmaskinvaran. |
0x02 | FIRMWARE_UPPDATERINGSERBJUDANDE BYTE_PÅGÅR | Komponentens inbyggda programvara har uppdaterats, men ett byte till den nya inbyggda programvaran väntar. Ingen ytterligare uppdatering av inbyggd programvara kan ske förrän omkopplingen är klar, vanligtvis genom en återställning. |
0x03 - 0x08 | (Reserverad) | Reserverat. Använd inte. |
0x09 - 0xDF | (Reserverad) | Reserverad. Använd inte. |
0xE0 – 0xFF | (Leverantörsspecifik) | Dessa värden används av protokollets designers och innebörden är leverantörsspecifik. |
5.4.2.4 Status
Tabell 5.4-11 FIRMWARE_UPDATE_OFFER – Layout för svarsstatus för erbjudandekommandopaket
Bitarna i statusbytet beskrivs i den här tabellen.
Tabell 5.4-12 FIRMWARE_UPDATE_OFFER– Offer Command Packet Response RR Code
Bitförskjutning | Fält | Storlek | Beskrivning |
---|---|---|---|
0 | Status | 8 | Det här fältet måste vara inställt på FIRMWARE_UPDATE_OFFER_ACCEPT. Detta indikerar att komponenten har beslutat att acceptera erbjudandet. |
8 | Reserverad. | 24 | Reserverad. Använd inte. |
5,5 FIRMWARE_UPDATE_CONTENT
Värden skickar det här kommandot till enhetens inbyggda programvara för att tillhandahålla dess innehåll, det vill säga avbildningen av den inbyggda programvaran. Hela avbildningsfilen förväntas inte få plats i ett enda kommando. Värden måste dela upp avbildningen i mindre block och varje kommando skickar ett block av avbildningen i taget.
Med varje kommando anger värden ytterligare information – om det är det första blocket, det sista blocket och så vidare, av den inbyggda programvaran. Den primära komponenten i enhetens inbyggda programvara accepterar varje block av den inkommande avbildningen av inbyggd programvara, lagrar den i minnet och måste svara på varje kommando individuellt.
När den primära komponenten tar emot det sista blocket verifierar komponenten hela avbildningen av inbyggd programvara (CRC-kontroll, signaturverifiering). Baserat på resultaten av dessa kontroller returneras ett lämpligt svar (fel eller framgång) för det senaste blocket.
5.5.1-kommando
Tabell 5.5-1 FIRMWARE_UPDATE_CONTENT kommandolayout
5.5.1.1 Rubrik (B7 - B0)
Tabell 5.5-2 Layout för kommandorubriken FIRMWARE_UPDATE_CONTENT
Bitarna i FIRMWARE_UPDATE_CONTENT-huvudet beskrivs i den här tabellen.
Tabell 5.5-3 FIRMWARE_UPDATE_CONTENT sidhuvudbitar
Bitförskjutning | Fält | Storlek | Beskrivning |
---|---|---|---|
0 | Flaggor | 8 | Det här fältet innehåller extra information om kommandot. Det här värdet är en mask med flaggor som ska användas för dataöverföringarna. Möjliga värden beskrivs i tabell 5.5-4. |
8 | Datalängd | 8 | Längden på tillämpligt datafält som anger antalet byte som ska skrivas. Med tanke på storleken på det här kommandot är det högsta tillåtna värdet för längden 52 byte. |
16 | Sekvensnummer | 16 | Det här värdet skapas av värden och är unikt för varje innehållspaket som utfärdas. Komponenten måste returnera sekvensnumret i sitt svar på den här begäran. |
32 | Adress för inbyggd programvara | 32 | Little Endian (LSB First) Adress för att skriva data. Adressen är 0-baserad. Den inbyggda programvaran använder detta som en förskjutning för att fastställa adressen efter behov när avbildningen placeras i minnet. |
Möjliga värden för bytet Flaggor beskrivs i den här tabellen.
Tabell 5.5-4 FIRMWARE_UPDATE_OFFER– Erbjudandekommandopaket – Flaggvärden
Flagga | Namn | Beskrivning |
---|---|---|
0x80 | FIRMWARE_UPDATE_FLAG_FIRST_BLOCK | Den här flaggan anger att det här är det första blocket i avbildningen av den inbyggda programvaran. |
0x40 | FIRMWARE_UPDATE_FLAG_LAST_BLOCK | Den här flaggan anger att det här är det sista blocket i avbildningen av den inbyggda programvaran och att avbildningen är redo att verifieras. Det är viktigt att den aktuella inbyggda programvaran på komponenten utför validering av hela den nedladdade firmware-avbildningen efter att ha skrivit detta block till icke-flyktigt minne. |
5.5.1.2 Data
Tabell 5.5-5 FIRMWARE_UPDATE_CONTENT kommandodatalayout
Bitarna i FIRMWARE_UPDATE_CONTENT Data beskrivs i den här tabellen.
Tabell 5.5-6 FIRMWARE_UPDATE_CONTENT kommandodatabitar
Bitförskjutning | Fält | Storlek | Beskrivning |
---|---|---|---|
64 | Data | Max 52. | Byte-matrisen som ska skrivas. Vanligtvis skickar värden block på 4 byte baserat på produktarkitektur. Alla oanvända byte i slutet måste vara utfyllt med 0. |
5.5.2 Svar
Tabellen 5.5-7 FIRMWARE_UPDATE_CONTENT Kommandosvarslayout
Sekvensnummer 5.5.2.1
Tabell 5.5-8 FIRMWARE_UPDATE_CONTENT svar – sekvensnummer
Bitarna i FIRMWARE_UPDATE_CONTENT-svaret (3–0) beskrivs i den här tabellen.
Tabell 5.5-9 FIRMWARE_UPDATE_CONTENT – Kommando – Svarsbitar
Bitförskjutning | Fält | Storlek | Beskrivning |
---|---|---|---|
0 | Sekvensnummer | 16 | Det här fältet är sekvensnumret som skickades med hosten i begäran. |
16 | Reserverad | 16 | Reserverat Använd inte. |
5.5.2.2 Status
Tabell 5.5-10 Layout för FIRMWARE_UPDATE_CONTENT:s svarstatus
Bitarna i FIRMWARE_UPDATE_CONTENT-svaret (7–4) beskrivs i den här tabellen.
Tabell 5.5-11 FIRMWARE_UPDATE_OFFER – Svar – Statusbitar
Bitförskjutning | Fält | Storlek | Beskrivning |
---|---|---|---|
0 | Status | 8 | Det här värdet anger statuskoden som returneras av enhetskomponenten. Detta är inte bitvis och kan vara ett av de värden som beskrivs i tabell 5.5-12. |
8 | Reserverad | 24 | Reserverat Använd inte. |
Möjliga värden för statusbyte beskrivs i den här tabellen.
Tabell 5.5-12 FIRMWARE_UPDATE_OFFER– Svar – Statuskodvärden
Flagga | Namn | Beskrivning |
---|---|---|
0x00 | FIRMWARE-uppdatering lyckad | Begäran har slutförts. |
0x01 | FEL VID FÖRBEREDELSE AV FIRMWAREUPPDATERING | Komponenten var inte beredd att ta emot innehållet i den inbyggda programvaran. Om den används används den här koden vanligtvis i ett svar på det första blocket. Till exempel ta bort fel på flashminnet. |
0x02 | FIRMWARE_UPPDATERINGSFEL_SKRIV | Begäran kunde inte skriva byte. |
0x03 | FIRMWAREUPPDATERINGSFEL_FULLSTÄNDIG | Begäran kunde inte konfigurera växlingen som svar på FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
0x04 | FIRMWAREUPPDATERINGSFEL_VERIFIERA | Verifieringen av DWORD misslyckades som svar på FIRMWARE_UPDATE_FLAG_VERIFY. |
0x05 | FEL_FIRMWAREUPPDATERING_CRC | CRC för avbildningen av inbyggd programvara misslyckades som svar på FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
0x06 | FELSIGNATUR_FÖR_FIRMWAREUPPDATERING | Verifieringen av signaturen för inbyggd programvara misslyckades som svar på FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
0x07 | FIRMWAREUPPDATERINGSFEL_VERSION | Verifiering av inbyggd programvaruversion misslyckades på grund av FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
0x08 | FIRMWAREUPPDATERING_VÄXLING_PÅGÅR | Den inbyggda programvaran har redan uppdaterats och ett byte väntar. Inga ytterligare kommandon för uppdatering av inbyggd programvara kan accepteras förrän tillbehöret har återställts. |
0x09 | FIRMWARE_UPPDATERINGS_FEL_OGILTIG_ADRESS | Inbyggd programvara har identifierat en ogiltig måladress i meddelandets datainnehåll. |
0x0A | FIRMWARE_UPDATE_ERROR_NO_OFFER | Kommandot FIRMWARE_UPDATE_OFFER togs emot utan att först få ett giltigt och godkänt erbjudande för uppdatering av inbyggd programvara. |
0x0B | FIRMWARE_UPPDATERINGSFEL_OGILTIG | Allmänt fel för FIRMWARE_UPDATE_OFFER-kommandot, till exempel en ogiltig tillämplig datalängd. |
5.5.2.3 Reserverad B8 - B11
Reserverad. Använd inte.
5.5.2.4 Reserverad B12 - B15
Reserverad. Använd inte.
6 Bilaga 1: Exempel på programmeringskommandosekvens för uppdatering av inbyggd programvara
6.1 Exempel 1
Överväg följande inbyggda programvara för enheter:
Primär komponent – Komponent-ID 1 – Aktuell version av inbyggd programvara 7.0.1
Underkomponent – Komponent-ID 2 – Aktuell version av inbyggd programvara 12.4.54
Underkomponent – Komponent-ID 3 – Aktuell version av inbyggd programvara 4.4.2
Underkomponent – Komponent-ID 4 – Aktuell version av inbyggd programvara 23.32.9
Värden har följande tre firmware-versioner:
Komponent-ID 1 – Version 7.1.3 av inbyggd programvara
Komponent-ID 2 – Version 12.4.54 av inbyggd programvara
Komponent-ID 3 – Version 4.5.0 av inbyggd programvara
Sekvensen blir:
Värderbjudanden: Komponent-ID 1 – Inbyggd programvara version 7.1.3
Den primära komponenten accepterar erbjudandet
Värden skickar avbildningen av inbyggd programvara
Den primära komponenten accepterar inbyggd programvara, validerar den
Värderbjudanden: Komponent-ID 2 – Inbyggd programvara version 12.4.54
Den primära komponenten avvisar erbjudandet
Värderbjudanden: Komponent-ID 3 – Inbyggd programvara version 4.5.0
Den primära komponenten accepterar erbjudandet
Värden skickar avbildningen av inbyggd programvara
Den primära komponenten accepterar inbyggd programvara, validerar den
Eftersom alla erbjudanden inte avvisades spelar värden upp alla erbjudanden:
Värd erbjuder: Komponent-ID 1 – Firmware version 7.1.3
Komponenten avvisar
Värderbjudanden: Komponent-ID 2 – Inbyggd programvara version 12.4.54
Komponenten avvisar
Värderbjudanden: Komponent-ID 3 – Inbyggd programvara version 4.5.0
Komponent avvisar
6.2 Exempel 2
Överväg följande inbyggda programvara för enheter:
Primär komponent – Komponent-ID 1 – Aktuell version av inbyggd programvara 7.0.1
Underkomponent – Komponent-ID 2 – Aktuell version av inbyggd programvara 12.4.54
Underkomponent – Komponent-ID 3 – Aktuell version av inbyggd programvara 7.4.2
Underkomponent – Komponent-ID 4 – Aktuell version av inbyggd programvara 23.32.9
Värden har följande tre avbildningar av inbyggd programvara:
Komponent-ID 1 – Version 8.0.0 av inbyggd programvara
Komponent-ID 2 – Version 12.4.54 av inbyggd programvara
Komponent-ID 3 – Version 9.0.0 av inbyggd programvara
Dessutom kräver implementeringen att den inbyggda programvarans version av underkomponenterna inte får vara mindre än den version av inbyggd programvara som körs på den primära komponenten. Värden är inte medveten om det kravet, och up-to är den primära komponenten för att säkerställa denna regel.
Sekvensen blir:
Värderbjudanden: Komponent-ID 1 – Version 8.0.0 av inbyggd programvara
Primär komponent avvisar (eftersom komponent-ID 3 ännu inte har uppdaterats)
Värderbjudanden: Komponent-ID 2 – Inbyggd programvara version 12.4.54
Primär komponent avvisar
Värderbjudanden: Komponent-ID 3 – Inbyggd programvara version 9.0.0
Den primära komponenten accepterar erbjudandet
Värden skickar firmware-avbildningen
Den primära komponenten accepterar inbyggd programvara, validerar den
Eftersom inte alla erbjudanden avvisades spelar värden upp alla erbjudanden
Host-erbjudanden: Komponent-ID 1 – Firmwareversion 8.0.0
Den primära komponenten accepterar erbjudandet
Värden skickar firmware-avbildningen
Den primära komponenten accepterar inbyggd programvara, validerar den
Värderbjudande: Komponent-ID 2 – Inbyggd programvara version 12.4.54
Primär komponent avvisar
Värderens erbjudanden: Komponent-ID 3 – Inbyggd programvara version 9.0.0
Primär komponent avvisar