Spécification du protocole CFU (Component Firmware Update)
Cette spécification décrit un protocole HID générique pour mettre à jour le microprogramme des composants présents sur un PC ou des accessoires. La spécification permet à un composant d’accepter le microprogramme sans interrompre l’opération de l’appareil pendant un téléchargement. La spécification prend en charge les configurations où le composant acceptant le microprogramme peut avoir des sous-composants, qui nécessitent des images de microprogramme distinctes. La spécification permet au composant en charge de décider s’il faut accepter le microprogramme. Il agit également comme une optimisation, car l’image du microprogramme est envoyée uniquement au composant s’il est en mesure ou prêt à l’accepter.
Remarque
Le CFU est disponible dans Windows 10, version 2004 (Mise à jour de Windows 10 de mai 2020) et versions ultérieures.
Contenu
- 1 Introduction
- 2 Architecture matérielle prise en charge
- 3 Conditions préalables au protocole
- Vue d’ensemble du protocole CFU 4
- 4.1 Séquence de commandes de programmation de la mise à jour du microprogramme
- 4.1.1 État : Notification d'initialisation de l'hôte
- 4.1.2 État : Notification OFFER_INFO_START_OFFER_LIST
- 4.1.3 État : Envoi de la commande FIRMWARE_UPDATE_OFFER
- 4.1.4 État : Envoi du microprogramme
- 4.1.5 État de décision : y a-t-il plus d’offres
- 4.1.6 État : Notification OFFER_INFO_END_OFFER_LIST
- 4.1.7 État de décision : Rejouer la liste d'offres
- état 4.1.8 : l’appareil est occupé
- 4.1 Séquence de commandes de programmation de la mise à jour du microprogramme
- 5 Format des paquets du protocole CFU
- 6 Annexe 1 : Exemple de séquence de commandes de programmation de mise à jour du microprogramme
Tableaux
Tableau 5.1-1 Disposition de la réponse GET_FIRMWARE_VERSION
Tableau 5.1-2 Réponse GET_FIRMWARE_VERSION – Disposition de l'en-tête
Tableau 5.1-3 Réponse GET_FIRMWARE_VERSION – Bits d'en-tête
Tableau 5.1-4 Réponse GET_FIRMWARE_VERSION - Version et disposition des propriétés du composant
Tableau 5.1-5 Réponse GET_FIRMWARE_VERSION – Bits de version et de propriété des composants
Tableau 5.2-1 Disposition de la commande FIRMWARE_UPDATE_OFFER
Tableau 5.2-2 Commande FIRMWARE_UPDATE_OFFER – Informations sur les composants
Tableau 5.2-3 Commande FIRMWARE_UPDATE_OFFER – Bits d'information sur les composants
Tableau 5.2-4 Commande FIRMWARE_UPDATE_OFFER – Disposition de la version du microprogramme
Tableau 5.2-5 Commande FIRMWARE_UPDATE_OFFER – Bits de la version du microprogramme
Tableau 5.2-6 Commande FIRMWARE_UPDATE_OFFER – Disposition spécifique au fournisseur
Tableau 5.2-7 Commande FIRMWARE_UPDATE_OFFER – Divers et version du protocole
Tableau 5.2-8 Disposition du jeton de réponse FIRMWARE_UPDATE_OFFER
Tableau 5.2-9 Réponse FIRMWARE_UPDATE_OFFER – Disposition des jetons
Tableau 5.2-10 Réponse FIRMWARE_UPDATE_OFFER – Bits de jeton
Tableau 5.2-11 Réponse FIRMWARE_UPDATE_OFFER – Disposition du motif de rejet
Tableau 5.2-12 Réponse FIRMWARE_UPDATE_OFFER – Bits de motif de rejet
Tableau 5.2-13 Réponse FIRMWARE_UPDATE_OFFER – Valeurs du code RR
Tableau 5.2-14 Réponse FIRMWARE_UPDATE_OFFER – Disposition du statut
Tableau 5.2-15 Réponse FIRMWARE_UPDATE_OFFER – Bits d'état
Tableau 5.2-16 Réponse FIRMWARE_UPDATE_OFFER – Valeurs d'état
Tableau 5.3-1 FIRMWARE_UPDATE_OFFER – Disposition de la commande d'information
Tableau 5.3-2 FIRMWARE_UPDATE_OFFER – Commande d'information – Disposition des composants
Tableau 5.3-3 FIRMWARE_UPDATE_OFFER – Commande d'information – Bits de composants
Tableau 5.3-4 FIRMWARE_UPDATE_OFFER – Commande d'information – Valeurs du code d'information
Tableau 5.3-5 FIRMWARE_UPDATE_OFFER – Réponse d'information – Disposition
Tableau 5.3-6 FIRMWARE_UPDATE_OFFER – Paquet d'informations – Disposition du jeton de réponse
Tableau 5.3-7 FIRMWARE_UPDATE_OFFER – Information Response – Bits de jeton
Tableau 5.3-8 FIRMWARE_UPDATE_OFFER – Réponse d'information – Disposition du code RR
Tableau 5.3-9 FIRMWARE_UPDATE_OFFER – Réponse d'information sur l'offre – Bits du code RR
Tableau 5.3-10 FIRMWARE_UPDATE_OFFER – Réponse d'information – Valeurs du code RR
Tableau 5.3-11 FIRMWARE_UPDATE_OFFER – Réponse d'information sur l'offre – Disposition du statut
Tableau 5.3-12 FIRMWARE_UPDATE_OFFER – Informations sur l'offre – Bits d'état de la réponse
Tableau 5.4-1 FIRMWARE_UPDATE_OFFER – Disposition de la commande étendue
Tableau 5.4-3 FIRMWARE_UPDATE_OFFER – Commande étendue – Bits des composants
Tableau 5.4-4 FIRMWARE_UPDATE_OFFER – Commande étendue – Valeurs du code de commande
Tableau 5.4-5 FIRMWARE_UPDATE_OFFER – Commande étendue – Disposition du paquet de réponses
Tableau 5.4-7 FIRMWARE_UPDATE_OFFER – Réponse à la commande d'offre – Bits de jeton
Tableau 5.4-9 FIRMWARE_UPDATE_OFFER – Réponse à la commande d'offre – Code RR
Tableau 5.4-10 FIRMWARE_UPDATE_OFFER- Offre d'un pack de commande – Valeurs du code RR
Tableau 5.4-12 FIRMWARE_UPDATE_OFFER- Réponse au paquet de commandes de l'offre – Code RR
Tableau 5.5-1 FIRMWARE_UPDATE_CONTENT – Disposition des commandes
Tableau 5.5-2 FIRMWARE_UPDATE_CONTENT – Disposition de l'en-tête de la commande
Tableau 5.5-3 FIRMWARE_UPDATE_CONTENT – Bits d'en-tête
Tableau 5.5-4 FIRMWARE_UPDATE_OFFER – Paquet de commandes d'offre – Valeurs des indicateurs
Tableau 5.5-5 FIRMWARE_UPDATE_CONTENT – Disposition des données de commande
Tableau 5.5-6 FIRMWARE_UPDATE_CONTENT – Bits de données de commande
Tableau 5.5-7 FIRMWARE_UPDATE_CONTENT – Disposition de la réponse à la commande
Tableau 5.5-8 Réponse FIRMWARE_UPDATE_CONTENT – Numéro de séquence
Tableau 5.5-9 FIRMWARE_UPDATE_CONTENT – Commande – Bits de réponse
Tableau 5.5-10 Réponse FIRMWARE_UPDATE_CONTENT – Disposition du statut
Tableau 5.5-11 FIRMWARE_UPDATE_OFFER – Réponse – Bits d'état
Tableau 5.5-12 Réponse FIRMWARE_UPDATE_OFFER – Valeurs des codes d'état
1 Introduction
Les PC et accessoires d’aujourd’hui ont des composants internes qui effectuent des opérations complexes. Pour garantir une qualité de produit, il est nécessaire de mettre à jour fréquemment le comportement de ces appareils dans les phases ultérieures de développement ou après leur expédition aux clients. La mise à jour peut résoudre les problèmes fonctionnels ou de sécurité identifiés, ou avoir besoin d’ajouter de nouvelles fonctionnalités. Une grande partie de la logique complexe se trouve dans le microprogramme en cours d’exécution sur l’appareil, qui est pouvant être mis à jour.
Cette spécification décrit un protocole HID générique pour mettre à jour le microprogramme des composants présents sur un PC ou ses accessoires. L’implémentation HID dépasse la portée de la spécification.
Voici quelques-unes des fonctionnalités du protocole :
Le protocole est basé sur HID-ubiquitous et est pris en charge par Windows sur différents bus d'interconnexion tels que USB et I2C. Par conséquent, la même solution logicielle (pilote) peut être exploitée pour mettre à jour le microprogramme pour tous les composants.
Remarque
Étant donné que la spécification est basée sur des paquets, il est simple de l’adapter aux scénarios non HID.
La spécification permet à un composant d’accepter le microprogramme sans interrompre l’opération de l’appareil pendant le téléchargement. Il permet une meilleure expérience pour les utilisateurs, car ils n’ont pas besoin d’attendre que le processus de mise à jour du microprogramme se termine avant de pouvoir reprendre d’autres tâches. Le nouveau microprogramme peut être appelé dans une seule opération atomique à la fois qui a un impact minimal sur l’utilisateur.
La spécification prend en charge les configurations où le composant acceptant le microprogramme peut avoir des sous-composants, qui nécessitent des images de microprogramme distinctes.
Remarque
Le processus d’un composant qui passe le microprogramme au sous-composant est en dehors de l’étendue de cette spécification.
La spécification prend en charge le concept d'une offre de type et s'appuie sur le composant responsable pour décider s'il faut accepter le microprogramme. La décision d’accepter un nouveau microprogramme n’est pas triviale. Il peut y avoir des dépendances entre le type de microprogramme et/ou la version et le type/version sous-jacent du matériel auquel le nouveau microprogramme s’applique. Une offre agit également comme un mécanisme d’optimisation, car l’image du microprogramme est envoyée au composant uniquement s’il est en mesure /prêt à l’accepter.
1.1 Glossaire
| Terme | Description |
|---|---|
| ID de composant | Dans un appareil avec plusieurs composants, un ID de composant identifie de façon unique chaque composant. |
| CRC | Contrôle de redondance cyclique Algorithme de hachage non chiffré utilisé pour produire une synthèse ou une empreinte digitale d’un bloc de données. Le CRC est utilisé comme vérification pour fournir l’assurance que le bloc de données n’a pas changé depuis que le CRC a été calculé. Le CRC n’est pas infaillible, mais fournit la confiance que les données ont été reçues correctement. |
| Appareil | Collection de composants (un composant principal et zéro ou plusieurs sous-composants). L’appareil est visible par le système d’exploitation en tant qu’unité unique. L’hôte interagit avec l’appareil, qui est généralement le composant principal. Un ordinateur peut contenir plusieurs appareils. En ce qui concerne cette spécification, les communications vers 2 appareils différents sont totalement indépendantes. |
| Chauffeur | Un pilote écrit à l'aide du cadre de travail Windows Driver Foundation (WDF). |
| Microprogramme | Code en cours d’exécution sur le matériel physique. Le microprogramme est pouvant être mis à jour et réside généralement dans la mémoire programmable associée au matériel. |
| Matériel | Un morceau physique de silicium sur l’ordinateur. |
| Composant principal | Un morceau de matériel sur un ordinateur et le microprogramme pour celui-ci. Dans le contexte de cette spécification, un composant est l’entité qui a besoin et accepte la mise à jour du microprogramme. |
| Segment | Une image de microprogramme pour un composant peut être segmentée en segments plus petits. Chaque segment est une petite image de microprogramme. |
| Identifiant de segment | Si un microprogramme d’un composant est segmenté en segments plus petits, l’ID de segment est l’identificateur unique du segment. |
| Signature | Un moyen de chiffrement pour déterminer si l’image du microprogramme a été modifiée par des moyens non autorisés. Les signatures sont facultatives mais recommandées, et elles dépassent le cadre de cette spécification. |
| Sous-composant | Selon l’architecture matérielle, tous les composants ne peuvent pas être visibles par le système d’exploitation, car ils peuvent être connectés en aval d’un composant visible par le système. Ces composants sont appelés sous-composants dans cette spécification. |
| TLC | Collection de niveau supérieur HID. |
| Jeton | Identificateur d’une session hôte. Un hôte crée un jeton et l’envoie dans des commandes, et l’appareil le retourne dans la réponse. Les jetons peuvent être utilisés pour sérialiser certaines transactions ou pour identifier qu’une session a été perdue et qu’une autre a démarré. |
1.2 Étendue
1.2.1 Objectifs
Une solution indépendante de bus est nécessaire pour éviter un nouveau protocole pour chaque type de bus. HID est omniprésent et répond à cette exigence.
Possibilité de prendre en charge la mise à jour du microprogramme pour un appareil à plusieurs composants, où un composant agit comme composant principal et d’autres sont des sous-composants connectés au composant principal. Chaque composant nécessite son propre microprogramme avec des dépendances non triviales entre elles.
Modèle de pilote courant pour télécharger l’image du microprogramme sur le composant. Le composant dispose ensuite d'algorithmes spécifiques pour le transfert vers les sous-composants. Les sous-composants peuvent également effectuer des vérifications de validité sur leur microprogramme et transmettre les résultats au composant principal.
Possibilité de prendre en charge la mise à jour du microprogramme pendant que l’opération de l’appareil est en cours.
Possibilité de mettre à jour/restaurer le microprogramme dans les appareils de production par le biais d’outils autorisés et de mettre à jour les appareils sur le marché via Windows Update.
La souplesse nécessaire pour prendre en charge les microprogrammes en cours de développement et les microprogrammes du marché.
Possibilité de segmenter une image de microprogramme volumineuse en segments plus petits afin de faciliter l’acceptation de l’image du microprogramme par le composant.
1.2.2 Non-objectifs
Définissez le format interne de l’image du microprogramme : pour l’hôte, l’image du microprogramme est un ensemble d’entrées d’adresse et de charge utile.
Signer/chiffrer/valider le microprogramme accepté : cette spécification ne décrit pas comment signer et chiffrer les images du microprogramme. Il est nécessaire que le microprogramme actuel attendu s’exécutant sur le composant valide le microprogramme en cours de téléchargement.
Définissez un mécanisme sur la façon dont le composant interagit avec les sous-composants : l’hôte interagit avec l’appareil en tant qu’unité unique, généralement le composant principal. Le composant doit agir comme un pont pour la communication liée au microprogramme sous-composant.
2 Architecture matérielle prise en charge
Pour prendre en charge une conception matérielle flexible, le protocole prend en charge un appareil à composants multiples où chaque composant requiert son propre image de microprogramme. Dans la conception, un composant est le composant principal et les sous-composants dépendants sont connectés à ce composant principal. Chaque composant est décrit de manière unique par un ID de composant.
L’appareil à composants multiples est visible par le système d’exploitation en tant qu’unité unique. L’hôte interagit uniquement avec l’appareil, généralement le composant principal utilisant ce protocole CFU. La communication entre le composant et ses sous-composants dépasse la portée de cette spécification.
Sur un PC, il peut y avoir de nombreux appareils différents (où un appareil peut avoir un ou plusieurs composants là-bas). Dans le contexte de ce protocole, la communication à chaque appareil est indépendante. Chaque appareil a une instance correspondante de l’hôte.
3 Conditions préalables au protocole
Cette section répertorie les prérequis et les meilleures pratiques qui doivent être implémentés pour bénéficier de ce protocole :
Utilisation de l’image atomique
Une image de microprogramme pour un composant n’est pas utilisée tant que l’image de microprogramme entière n’a pas été correctement téléchargée. Si le microprogramme est divisé en plusieurs segments, l’image ne doit pas être utilisée tant que le segment final n’est pas reçu de l’expéditeur. Les vérifications d’intégrité doivent être effectuées sur l’image finale. Il est recommandé que le transport, utilisé pour fournir l’image du microprogramme, ait des mécanismes de correction d’erreur et de nouvelle tentative en place pour éviter un téléchargement répété en cas d’erreurs de transport.
La mise à jour du microprogramme ne doit pas interrompre l’opération de l’appareil
L’appareil acceptant l’image du microprogramme doit pouvoir fonctionner pendant la mise à jour. L’appareil doit disposer d’une mémoire supplémentaire pour stocker et valider le microprogramme entrant, tandis que son microprogramme actuel n’est pas remplacé.
Authentification et intégrité
L’implémenteur décide des facteurs qui constituent une image de micrologiciel authentique. Il est recommandé que le microprogramme actuel du composant doit au moins valider le CRC de l’image de microprogramme entrante. Le microprogramme actuel doit également utiliser la signature numérique ou d’autres algorithmes de détection d’erreurs. Si la validation échoue, le microprogramme rejette la mise à jour. Récupération après échec
Si l’image du microprogramme est téléchargée et échoue, l’appareil ne doit pas appeler le nouveau microprogramme et continuer à fonctionner avec le microprogramme existant. L’hôte peut réessayer la mise à jour. La fréquence de nouvelle tentative est spécifique à l’implémentation.
Confidentialité
Optionnel. Un segment de microprogramme peut être chiffré. Les techniques de chiffrement et de déchiffrement dépassent la portée de cette spécification. Cette spécification traite la charge utile du microprogramme comme un flux de données, qu’elle soit chiffrée ou non.
Protection contre le retour en arrière
Les stratégies de retour en arrière sont appliquées par le composant principal et sont spécifiques à l'implémentation. Le microprogramme actuel du composant valide les images de microprogramme entrantes par rapport à des stratégies internes telles que le numéro de version doit être plus récent, ou le type de version ne peut pas passer de version à débogage, etc. Le protocole permet d'indiquer qu'une mise à jour est acceptée même si elle enfreint les politiques de révocation.
Vue d’ensemble du protocole CFU 4
Le protocole CFU est un ensemble de commandes et de réponses requises pour envoyer la ou les nouvelles images de microprogramme de l’hôte à l’appareil pour lequel le microprogramme est destiné.
À un niveau élevé, le protocole passe en revue toutes les images de microprogrammes à envoyer à l'appareil. Pour chaque image du microprogramme, l’hôte propose d’envoyer le fichier à l’appareil. Uniquement si l’appareil accepte l’offre, l’hôte envoie le fichier.
Pour prendre en charge les cas où un ordre de mise à jour d’appareil a des dépendances, l’appareil peut ne pas accepter certaines offres dans la première passe, par conséquent, le protocole permet à l’hôte de renvoyer toutes les offres de microprogramme à l’appareil jusqu’à ce que toutes les dépendances soient résolues.
Commande de séquence de programmation de mise à jour du firmware 4.1
Voici la séquence de commandes CFU pour la mise à jour de l’image du microprogramme.
4.1.1 État : Notification initialisée de l’hôte
Une fois que l’hôte s’est initialisé et a identifié un ensemble d’offres qu’il doit envoyer à l’appareil, l’hôte émet une commande OFFER_INFO_START_ENTIRE_TRANSACTION pour indiquer au composant que l’hôte est maintenant initialisé. L’objectif de cette commande est d’informer le microprogramme d’appareil actuel qu’une nouvelle instance de l’hôte est disponible. Cette notification est utile lorsqu’une instance précédente de l’hôte est arrêtée de façon inattendue. L’appareil doit exécuter cette commande avec succès.
4.1.2 État : Notification OFFER_INFO_START_OFFER_LIST
Dans cet état, l’hôte émet la commande OFFER_INFO_START_OFFER_LIST pour indiquer qu’elle est prête à envoyer l’offre au microprogramme de l’appareil actuel. Le composant principal de l’appareil doit exécuter cette commande avec succès.
Cette commande est utile, car l’hôte peut envoyer toutes les offres à l’appareil plusieurs fois.
4.1.3 État : Envoyer FIRMWARE_UPDATE_OFFER commande
L’hôte envoie une offre au composant principal (ou à son sous-composant) pour vérifier si le composant souhaite accepter/rejeter le microprogramme. L’offre contient toutes les métadonnées nécessaires sur l’image du microprogramme, afin que le microprogramme actuel sur le composant puisse décider s’il accepte, met en attente, ignore ou rejette l’offre.
L’offre peut être destinée au composant principal ou au sous-composant. Si le composant peut accepter l’offre, il se prépare à recevoir le microprogramme. Cela peut impliquer la préparation d’une banque de mémoire pour recevoir l’image du microprogramme entrant. Le composant peut ne pas accepter l’offre, par exemple, que le composant dispose déjà d’une version plus récente (ou identique) du microprogramme que l’hôte a l’intention d’envoyer. Pour plus de raisons, consultez les exemples décrits dans l’Annexe 1 : Exemple de séquence de commandes de programmation de mise à jour du microprogramme.
Même si une offre est acceptée, le composant primaire peut toujours rejeter l'image du microprogramme après le téléchargement pour cause d'échec des contrôles d'intégrité et/ou de retour en arrière par rapport à l'image réelle reçue. Le composant doit vérifier chaque propriété d’image du microprogramme indépendamment des informations contenues dans l’offre.
L’hôte émet la commande FIRMWARE_UPDATE_OFFER pour avertir le composant principal de l’image du microprogramme que l’hôte a l’intention d’envoyer.
Si le composant accepte l'offre, son statut devient FIRMWARE_UPDATE_OFFER_ACCEPT, indiquant ainsi l'acceptation de l'offre.
Si le microprogramme de l’appareil est occupé et que le composant principal n’est pas en mesure d’accepter cette offre ou l’offre suivante pour le moment, il envoie une réponse occupée avec le statut FIRMWARE_UPDATE_OFFER_BUSY.
Si le microprogramme actuel est intéressé par l’offre, toutefois ne peut pas accepter l’offre (par exemple, en raison d’une dépendance à une mise à jour manquante pour le sous-composant) elle répond avec un FIRMWARE_UPDATE_OFFER_SKIP indiquant qu’elle est intéressée par ce microprogramme, mais ne peut pas l’accepter. L'hôte passe ensuite à l'offre suivante et doit proposer à nouveau ce microprogramme ultérieurement.
Si le microprogramme actuel n’est pas intéressé par l’offre (par exemple, il s’agit d’une version antérieure), il répond avec un état FIRMWARE_UPDATE_OFFER_REJECT fournissant la raison de rejet appropriée. Cet état n’indique pas que l’hôte ne peut pas renvoyer cette offre à l’avenir. L’hôte envoie généralement chaque offre chaque fois qu’elle initialise ou renvoie la liste des offres à l’appareil (voir État : OFFER_INFO_START_OFFER_LIST Notification).
4.1.4 État : Envoyer le firmware
Dans cet état, l’hôte commence à envoyer l’image du microprogramme au composant principal pour lequel le composant a précédemment accepté l’offre.
Étant donné que le contenu de l’image du microprogramme est susceptible de dépasser les limites de charge utile d’une seule commande, l’hôte interrompt les images du microprogramme en paquets. L’hôte envoie chaque paquet de manière séquentielle dans une commande FIRMWARE_UPDATE CONTENT distincte. Le composant principal doit générer un paquet de réponse pour chaque commande.
Chaque commande FIRMWARE_UPDATE CONTENT décrit une adresse de décalage qui inclut une charge utile partielle du microprogramme. Le composant utilise le décalage pour déterminer l’adresse où la charge utile partielle du microprogramme doit être stockée. L’appareil écrit le contenu à un emplacement approprié et reconnaît la commande en envoyant une réponse.
Pour le premier paquet envoyé par l’hôte, il définit l’indicateur FIRMWARE_UPDATE_FLAG_FIRST_BLOCK, indiquant à l’appareil qu’il s’agit du premier paquet de l’image du microprogramme. Si l’appareil n’a pas encore préparé lui-même la réception du microprogramme, il peut le faire pour l’instant.
Pour le dernier paquet qu'il envoie, l'hôte active l'indicateur FIRMWARE_UPDATE_FLAG_LAST_BLOCK.
Une fois que le microprogramme actuel de l'appareil a écrit la charge utile partielle du microprogramme incluse dans cette commande, il doit effectuer des contrôles de validation et d'authentification sur l'image du microprogramme entrant avant d'envoyer une réponse. Cela inclut minimalement les éléments suivants :
Contrôle CRC pour vérifier l’intégrité de l’image entière du microprogramme.
Si la vérification CRC réussit, une vérification facultative de la signature de l'image entrante est effectuée.
Après la vérification facultative de la signature, une vérification de version pour vérifier que la nouvelle version du microprogramme est identique ou ultérieure au microprogramme existant.
Si l'image du microprogramme entrante a été divisée en segments plus petits, c’est au microprogramme actuel de déterminer s'il s'agit du dernier segment de l'image du microprogramme et d'inclure tous les segments dans le cadre de la validation.
Si les vérifications précédentes passent, le microprogramme actuel peut configurer l’appareil pour échanger vers la nouvelle image à la prochaine réinitialisation et signale la réussite à l’hôte. En règle générale, le composant ne lance pas de réinitialisation automatique. Cela permet d’éviter les interruptions dans tous les logiciels, microprogrammes, entités matérielles avec lesquelles le composant interagit. Toutefois, ce n’est pas une exigence et peut varier en fonction de l’implémentation.
Si les étapes de vérification échouent, le microprogramme ne doit pas configurer un échange lors de la réinitialisation suivante et doit indiquer une réponse d’échec à l’hôte.
4.1.5 État de décision : y a-t-il plus d’offres
Dans cet état, l’hôte détermine s’il existe d’autres offres à envoyer à l’appareil.
4.1.6 État : Notification OFFER_INFO_END_OFFER_LIST
Cet état est atteint lorsque l’hôte a envoyé toutes les offres au composant principal dans le microprogramme de l’appareil actuel. L’hôte envoie la commande OFFER_INFO_END_OFFER_LIST pour indiquer qu’elle a envoyé toutes les offres au composant.
L’appareil doit exécuter cette commande avec succès.
4.1.7 État de décision : Rejouer la liste d'offres
L’hôte détermine s’il doit renvoyer toutes les offres. Ce cas peut se produire si le composant principal avait précédemment ignoré certaines offres et accepté certaines offres. L'hôte doit rejouer la liste d'offres.
Il peut y avoir d'autres logiques spécifiques à l'implémentation qui peuvent entraîner une décision de rejouer la liste d'offres.
4.1.8 État : L’appareil est occupé
Cet état implique qu'un appareil a renvoyé une réponse occupée à une offre.
L’hôte envoie une commande OFFER_NOTIFY_ON_READY, à laquelle l’appareil ne répond pas avec acceptation tant que l’appareil n’est pas libre.
Format de paquet du protocole CFU 5
Le protocole CFU est implémenté en tant qu’ensemble de commandes et de réponses. Le protocole est séquentiel dans la nature. Pour chaque commande envoyée par l’hôte à un composant, le composant est censé répondre (sauf indication explicite dans cette spécification). L’hôte n’envoie pas la commande suivante tant qu’une réponse valide n’est pas reçue pour la commande précédente envoyée.
Si le composant ne répond pas dans un délai ou envoie une réponse non valide, l’hôte peut redémarrer le processus à partir du début. Ce protocole ne définit pas de valeur de délai d’expiration spécifique.
Il existe des commandes pour obtenir les informations de version du microprogramme actuel sur le composant ; pour envoyer l’offre et envoyer l’image du microprogramme.
Toutefois, l’hôte n’a pas besoin de refuser une offre en fonction de la réponse reçue du composant principal sur les informations de version interrogées. Les informations sont détectables à des fins de journalisation ou d’autres fins.
5.1 GET_FIRMWARE_VERSION
Obtient la ou les versions actuelles du ou des microprogrammes du composant principal (et de ses sous-composants). La commande n’a aucun argument.
5.1.1 Commande
Cette commande est envoyée par l’hôte pour interroger la ou les versions des microprogrammes actuels sur le composant principal (et ses sous-composants). L’hôte peut l’utiliser pour vérifier si le microprogramme a été correctement mis à jour. Lors de la réception de cette commande, le composant principal répond avec la version du microprogramme pour elle-même et tous les sous-composants.
5.1.2 Réponse
Le composant répond avec la version du microprogramme du composant principal et des sous-composants. La taille de la réponse est de 60 octets, ce qui permet d'obtenir des informations de version pour jusqu'à sept composants (un composant principal et jusqu'à six sous-composants).
Tableau 5.1-1 Disposition de la réponse GET_FIRMWARE_VERSION
5.1.2.1 En-tête
Tableau 5.1-2 Réponse GET_FIRMWARE_VERSION – Disposition de l'en-tête
L’en-tête de la réponse fournit les informations suivantes.
Tableau 5.1-3 Réponse GET_FIRMWARE_VERSION – Bits d'en-tête
| Bit Offset | Champ | Taille | Description |
|---|---|---|---|
| 0 | Nombre de composants | 8 | Nombre de composants téléchargeables gérés via ce mécanisme pour ce composant. Le nombre de composants détermine la taille maximale de la table. Actuellement, jusqu’à 7 composants sont pris en charge pour s’assurer que la réponse peut correspondre aux 60 octets autorisés. |
| 8 | Rsvd | 16 | Champs réservés. L’expéditeur doit définir ces valeurs sur 0. Le récepteur doit ignorer cette valeur. |
| 24 | Version du protocole | 4 | Les bits de révision de la mise à jour du microprogramme représentent la révision du protocole de mise à jour du microprogramme actuellement utilisé dans le transport. Pour l'interface définie ici, la révision de la mise à jour du firmware doit être 0010b. |
| 28 | Rsvd | 3 | Champs réservés. L’expéditeur doit définir ces valeurs sur 0. Le récepteur doit ignorer cette valeur. |
| 31 | E | 1 | L'indicateur d'extension est un futur crochet de protocole permettant de signaler des composants supplémentaires. |
5.1.2.2 Version et propriétés du composant
Pour chaque composant, deux DWORD sont utilisés pour décrire ses propriétés, et cela jusqu'à un total de 7 composants. Si le nombre de composants dans l’en-tête est inférieur à 7, le DWORDS inutilisé à la fin de la réponse doit être défini sur 0.
Tableau 5.1-4 GET_FIRMWARE_VERSION Réponse - Version du composant et disposition des propriétés
Chaque information spécifique à chaque composant est décrite dans deux DWORD comme suit :
Tableau 5.1-5 Réponse GET_FIRMWARE_VERSION – Bits de version et de propriété des composants
| Bit Offset | Champ | Taille | Description |
|---|---|---|---|
| 0 | Version du microprogramme | 32 | Retourne la version du microprogramme actuel pour ce composant. Cette spécification n’impose aucun format spécifique pour la version du microprogramme. Consultez la section Version du microprogramme pour obtenir des instructions. |
| 32 | Banque | 2 | Optionnel. Selon l’architecture, le matériel de composant peut avoir plusieurs banques dans lesquelles le microprogramme peut être stocké. Selon l’implémentation, l’expéditeur peut spécifier la banque dans laquelle le microprogramme existe actuellement. Ce champ est obligatoire conditionnel : la prise en charge est facultative, mais ne doit pas être utilisée à d’autres fins. |
| 34 | Réservé | 2 | Champs réservés. L’expéditeur doit définir ces valeurs sur 0. Le récepteur doit ignorer cette valeur. |
| 36 | Spécifique au fournisseur | 4 | Champ spécifique du fournisseur qui peut être utilisé de manière spécifique à l’implémentation. Un fournisseur peut utiliser ces bits pour encoder des informations telles que : - Type de microprogramme : Pre-release/self-host/production ; debug/retail - Phase de développement - ID de produit, pour empêcher les composants de recevoir le microprogramme pour d’autres produits à l’aide du même protocole de mise à jour. |
| 40 | ID de composant | 8 | Identificateur unique du composant. |
| 48 | Spécifique au fournisseur | 16 | Champ spécifique du fournisseur qui peut être utilisé de manière spécifique à l’implémentation. |
5.1.3 Mappage au HID
Cette fonction est mise en œuvre sous la forme d'une requête HID Get Feature avec une taille de réponse de 60 octets, en plus de l'ID de l'état. La longueur du rapport de fonctionnalité couvre l'ensemble de la réponse GET_FIRMWARE_VERSION. Aucune donnée n’est associée à la demande Get Feature de l’hôte.
5.2 OFFRE_DE_MISE_À_JOUR_DU_FIRMWARE
Détermine si le composant principal accepte ou rejette un microprogramme.
5.2.1 Commande
L’hôte envoie cette commande au composant pour déterminer s’il accepte ou rejette un microprogramme. L’hôte doit envoyer une offre et le composant doit accepter l’offre avant que l’hôte puisse envoyer le microprogramme.
Le paquet de commandes FIRMWARE_UPDATE_OFFER est défini comme suit.
Tableau 5.2-1 Disposition de la commande FIRMWARE_UPDATE_OFFER
5.2.1.1 Informations sur les composants
Tableau 5.2-2 FIRMWARE_UPDATE_OFFER Commande - Disposition des informations sur les composants
Commande 
Les bits de l’octet Informations sur les composants sont décrits dans ce tableau.
Tableau 5.2-3 FIRMWARE_UPDATE_OFFER Commande - Bits d’informations sur les composants
| Bit Offset | Champ | Taille | Description |
|---|---|---|---|
| 0 | Numéro de segment | 8 | Ce champ est utilisé si le microprogramme d’un composant est segmenté en segments plus petits. Si elle est utilisée, cette valeur indique le segment contenu dans le paquet de charge utile suivant. Par exemple, si l’image du microprogramme du composant est très volumineuse et que le composant principal ne peut prendre que des parties plus petites de l’image à la fois, ce champ peut être utilisé pour indiquer que cette offre concerne le i-ième segment de l’image complète. Une offre distincte peut être envoyée au composant principal qui contient le i+1er segment de l’image, et ainsi de suite. |
| 8 | Réservé | 6 | Champs réservés. L’expéditeur doit définir ces valeurs sur 0. Le récepteur doit ignorer cette valeur. |
| 14 | I | 1 | Forcer la réinitialisation immédiate (I) - Cette valeur de bit est utilisée pour indiquer au composant de procéder à une réinitialisation immédiate une fois le téléchargement du microprogramme terminé et vérifié, afin de l'exécuter sans délai. - Cet indicateur est destiné à la phase de développement. |
| 15 | V | 1 | Forcer à ignorer la version (V) - Cet indicateur est destiné aux images de microprogrammes de préversion ou de débogage. Il indique au composant de ne pas rejeter le microprogramme en fonction de la version du microprogramme. - Cet indicateur est destiné à la phase de développement. Il peut être utilisé pour restaurer intentionnellement une version antérieure du microprogramme. - Cet indicateur doit être ignoré par le microprogramme de production. |
| 16 | ID de composant | 8 | Cet octet est utilisé pour les scénarios à plusieurs composants. Ce champ peut être utilisé pour identifier le sous-composant pour lequel l’offre est destinée. Si elle n’est pas utilisée, la valeur doit être 0. Les valeurs possibles des ID de composant sont les suivantes : 1 - 0xDF : valide 0xE0 - 0xFD : réservé. N’utilisez pas. 0xFF : L'offre est un paquet d'informations sur les offres spéciales. Consultez les informations de FIRMWARE_UPDATE_OFFER pour plus de détails. 0xFE : L'offre est un paquet de commande d'offre spéciale. Voir la section FIRMWARE_UPDATE_OFFER Extended pour plus de détails. |
| 24 | Jeton | 8 | L'hôte insère un jeton unique dans le paquet d'offres destiné au composant. Ce jeton doit être renvoyé par le composant dans la réponse à l'offre. Cela est utile s’il est nécessaire que le composant distingue les différents hôtes/types d’hôtes. Les valeurs exactes à utiliser sont spécifiques à l’implémentation. Par exemple, une valeur peut être utilisée pour un pilote et une autre pour l’application. Cela permet au microprogramme d’appareil actuel de tenir compte de plusieurs expéditeurs potentiels de commandes CFU. Une implémentation possible peut être d’accepter la première commande CFU et de rejeter toutes les autres commandes avec des jetons différents jusqu’à ce que les premières transactions CFU soient terminées. |
5.2.1.2 Version du microprogramme
Ces quatre octets représentent la version 32 bits du microprogramme. Le format de la version du microprogramme n’est pas obligatoire par cette spécification. Voici ce qui est recommandé.
Tableau 5.2-4 FIRMWARE_UPDATE_OFFER Commande - Disposition de version du microprogramme
commande 
Le format de la version du microprogramme n’est pas obligatoire par cette spécification, mais voici une recommandation recommandée.
Tableau 5.2-5 Commande FIRMWARE_UPDATE_OFFER - Bits de version du microprogramme
| Bit Offset | Champ | Taille | Description |
|---|---|---|---|
| 0 | Variante | 8 | Ce champ peut être décrit pour faire la distinction entre un microprogramme en préversion et un microprogramme de production. Il peut indiquer le type de signature utilisé pour signer le microprogramme. |
| 8 | Version mineure | 16 | Cette valeur de champ doit être mise à jour pour chaque build du microprogramme. Cette valeur de champ doit être mise à jour pour chaque build du microprogramme. |
| 24 | Version principale | 8 | Ce champ est la version principale de l’image du microprogramme. Ce champ doit être mis à jour lors de l’expédition d’une nouvelle ligne de produit, de nouvelles mises à jour majeures du microprogramme, et ainsi de suite. |
5.2.1.3 Fournisseur spécifique
Ces quatre octets peuvent être utilisés pour encoder toutes les informations personnalisées de l’offre spécifiques à l’implémentation du fournisseur.
5.2.1.4 Divers et version du protocole
Ces quatre octets peuvent être utilisés pour encoder toutes les informations personnalisées de l’offre spécifiques à l’implémentation du fournisseur.
Tableau 5.2-6 FIRMWARE_UPDATE_OFFER Commande - Disposition spécifique du fournisseur
Commande 
Les bits de l’octet spécifique au fournisseur sont décrits dans ce tableau.
Tableau 5.2-7 Commande FIRMWARE_UPDATE_OFFER – Divers et version du protocole
| Bit Offset | Champ | Taille | Description |
|---|---|---|---|
| 0 | Version du protocole | 4 | Ce champ doit être défini sur 0010b indiquant que l’hôte/l’offre correspond à la version 2 du protocole CFU. |
| 4 | Réservé | 4 | Réservé. N’utilisez pas. |
| 8 | Réservé | 8 | Réservé. N’utilisez pas. |
| 16 | Spécifique au fournisseur | 16 | Ce champ peut être utilisé pour encoder toutes les informations personnalisées de l’offre spécifiques à l’implémentation du fournisseur. |
5.2.2 Réponse
Le paquet de réponse FIRMWARE_UPDATE_OFFER est défini comme suit.
Tableau 5.2-8 FIRMWARE_UPDATE_OFFER Disposition du jeton de réponse
5.2.2.1 Jeton
Tableau 5.2-9 Réponse FIRMWARE_UPDATE_OFFER : Disposition des jetons
Les bits de l’octet de Token sont décrits dans ce tableau.
Tableau 5.2-10 Réponse FIRMWARE_UPDATE_OFFER – Bits de jeton
| Bit Offset | Champ | Taille | Description |
|---|---|---|---|
| 0 | Réservé | 8 | Réservé. N’utilisez pas. |
| 8 | Réservé | 8 | Réservé. N’utilisez pas. |
| 16 | Réservé | 8 | Réservé. N’utilisez pas. |
| 24 | Jeton | 8 | Jeton permettant d’identifier l’hôte. |
5.2.2.2 Réservé (B7 - B4)
Réservé. N’utilisez pas.
5.2.2.3 Raison du rejet (RR)
Tableau 5.2-11 Réponse FIRMWARE_UPDATE_OFFER - Disposition des motifs de rejet
Tableau 5.2-12 Réponse FIRMWARE_UPDATE_OFFER – Bits de motif de rejet
Les bits de l'octet "Reject Reason" sont décrits dans ce tableau.
| Bit Offset | Champ | Taille | Description |
|---|---|---|---|
| 0 | Code RR | 8 | Code de motif de rejet qui indique la raison fournie par le composant pour rejeter l’offre. Cette valeur dépend du champ État. Pour obtenir une correspondance entre un état et un code RR, consultez le tableau 5.2-13. |
| 8 | Réservé | 24 | Réservé. N’utilisez pas. |
Tableau 5.2-13 Réponse FIRMWARE_UPDATE_OFFER – Valeurs du code RR
Les valeurs possibles pour l’octet de code RR sont décrites dans ce tableau.
| Code RR | Nom | Description |
|---|---|---|
| 0x00 | FIRMWARE_OFFER_REJECT_OLD_FW | L’offre a été rejetée, car la version du microprogramme proposé est antérieure ou identique au microprogramme actuel. |
| 0x01 | FIRMWARE_OFFER_REJECT_INV_COMPONENT | L’offre a été rejetée, car le microprogramme proposé n’est pas applicable à la plateforme du produit. Cela peut être dû à un ID de composant non pris en charge ou à une image proposée n’est pas compatible avec le matériel système. |
| 0x02 | FIRMWARE_UPDATE_OFFER SWAP_PENDING | Le microprogramme du composant a été mis à jour, mais un échange vers le nouveau microprogramme est en attente. Aucun traitement de mise à jour du microprogramme supplémentaire ne peut se produire tant que l’échange n’est pas terminé, généralement par le biais d’une réinitialisation. |
| 0x03 - 0x08 | (Réservé) | Réservé. N’utilisez pas. |
| 0x09 – 0xDF | (Réservé) | Réservé. N’utilisez pas. |
| 0xE0 – 0xFF | (Spécifique au fournisseur) | Ces valeurs sont utilisées par les concepteurs du protocole et la signification est spécifique au fournisseur. |
5.2.2.4 État
Tableau 5.2-14 Réponse FIRMWARE_UPDATE_OFFER – Disposition du statut
Les bits de l’octet de statut sont décrits dans ce tableau.
Tableau 5.2-15 Réponse FIRMWARE_UPDATE_OFFER – Bits d'état
| Bit Offset | Champ | Taille | Description |
|---|---|---|---|
| 0 | Statut | 8 | Cette valeur indique la décision du composant d’accepter, de pender, d’ignorer ou de rejeter l’offre. Le composant fournit la raison de la valeur du champ Code RR. Pour obtenir une correspondance entre le statut et le code RR, consultez le tableau 5.2-16. |
| 8 | Réservé | 24 | Réservé. N’utilisez pas. |
Les valeurs possibles pour l’octet Status sont décrites dans ce tableau.
Tableau 5.2-16 Réponse FIRMWARE_UPDATE_OFFER – Valeurs d'état
| Statut | Nom | Description |
|---|---|---|
| 0x00 | FIRMWARE_UPDATE_OFFER_SKIP | Le composant a décidé d'ignorer l'offre. L’hôte doit l’offrir de nouveau plus tard. |
| 0x01 | Offre de mise à jour du micrologiciel acceptée | Le composant a décidé d'accepter l'offre. |
| 0x02 | FIRMWARE_UPDATE_OFFER_REJECT | Le composant a décidé de rejeter l'offre. |
| 0x03 | FIRMWARE_UPDATE_OFFER_BUSY | L’appareil est occupé et l’hôte doit attendre que l’appareil soit prêt. |
| 0x04 | FIRMWARE_UPDATE_OFFER_COMMAND | Utilisé lorsque l’ID de composant dans les octets d’informations sur le composant (voir 5.1.2.1.1 Component Information) est défini sur 0xFE. Pour le code de commande défini sur la requête OFFER_NOTIFY_ON_READY, indique que l'accessoire est prêt à accepter des offres supplémentaires. |
| 0xFF | FIRMWARE_UPDATE_CMD_NOT_SUPPORTED | La demande d’offre n’est pas reconnue. |
5.2.3 Mappage avec le protocole HID
Le problème est transmis au composant par l'intermédiaire du mécanisme de rapport de sortie HID, en utilisant l'ID de rapport de l'utilitaire HID dédié à la mise à jour du microprogramme. Le TLC de l'utilitaire HID à utiliser est décrit dans l'annexe.
5.3 FIRMWARE_UPDATE_OFFER – Information
Si l’ID de composant dans les octets d’informations sur le composant (voir Informations sur le composant) est défini sur 0xFF, les bits (15 octets) sont redéfinis pour indiquer uniquement les informations sur l’offre, de l’hôte au composant. Ce mécanisme permet l’extensibilité et un moyen pour l’hôte de fournir des informations spécifiques à l’appareil, telles que la liste des offres de démarrage, la liste des offres de fin, la transaction de démarrage entière. Les paquets d’informations d’offre sont toujours acceptés immédiatement par le composant.
5.3.1 Commande
Le paquet de commandes FIRMWARE_UPDATE_OFFER -Information est défini comme suit :
Tableau 5.3-1 FIRMWARE_UPDATE_OFFER – Disposition de la commande d'information
5.3.1.1 Composant
Tableau 5.3-2 FIRMWARE_UPDATE_OFFER – Commande d'information – Disposition des composants
Les bits de l’octet composant sont décrits dans ce tableau.
Tableau 5.3-3 FIRMWARE_UPDATE_OFFER – Commande d'information – Bits de composants
| Bit Offset | Champ | Taille | Description |
|---|---|---|---|
| 0 | Code d’information | 8 | Cette valeur indique le type d’informations. Cette valeur n’est pas un masque de bits et ne peut être qu’une des valeurs possibles décrites dans le tableau 5.3-4. |
| 8 | Réservé. | 8 | Réservé. N’utilisez pas. |
| 16 | ID de composant | 8 | Défini sur 0xFF. |
| 24 | Jeton | L'hôte insère un jeton unique dans le paquet d'offres destiné au composant. Ce jeton doit être renvoyé par le composant dans la réponse à l'offre. |
Tableau 5.3-4 FIRMWARE_UPDATE_OFFER - Commande d'information - Valeurs du code d'informations
| Statut | Nom | Description |
|---|---|---|
| 0x00 | OFFER_INFO_START_ENTIRE_TRANSACTION | Indique que l'hôte est nouveau ou qu'il a été rechargé et que l'ensemble du traitement de l'offre (re)commence. |
| 0x01 | OFFER_INFO_START_OFFER_LIST | Indique le début de la liste des offres provenant de l'hôte si l’accessoire a des règles de téléchargement associées garantissant la mise à jour d’un sous-composant avant un autre dans le système. |
| 0x02 | OFFER_INFO_END_OFFER_LIST | Indique la fin de la liste des offres de l’hôte. |
5.3.1.2 Réservé B7 – B4
Réservé. N’utilisez pas.
5.3.1.3 Réservé B11 – B8
Réservé. N’utilisez pas.
5.3.1.4 Réservé B15 – B12
Réservé. N’utilisez pas.
5.3.2 Réponse
La réponse au paquet FIRMWARE_UPDATE_OFFER – Offer Information Response est définie comme suit.
Tableau 5.3-5 FIRMWARE_UPDATE_OFFER – Réponse d'information – Disposition
5.3.2.1 Jeton
Tableau 5.3-6 FIRMWARE_UPDATE_OFFER – Paquet d'informations – Disposition du jeton de réponse
Les bits de l’octet du jeton sont décrits dans ce tableau.
Tableau 5.3-7 FIRMWARE_UPDATE_OFFER – Information Response – Bits de jeton
| Bit Offset | Champ | Taille | Description |
|---|---|---|---|
| 0 | Réservé | 8 | Réservé. N’utilisez pas. |
| 8 | Réservé | 8 | Réservé. N’utilisez pas. |
| 16 | Réservé | 8 | Réservé. N’utilisez pas. |
| 24 | Jeton | 8 | Jeton permettant d’identifier l’hôte |
5.3.2.2 Réservé B7 – B4
Réservé. N’utilisez pas.
5.3.2.3 Raison de rejet (RR)
Tableau 5.3-8 FIRMWARE_UPDATE_OFFER – Réponse d'information – Disposition du code RR
Les bits de l'octet Reject Reason sont décrits dans ce tableau.
Tableau 5.3-9 FIRMWARE_UPDATE_OFFER – Réponse d'information sur l'offre – Bits du code RR
| Bit Offset | Champ | Taille | Description |
|---|---|---|---|
| 0 | Code RR | 8 | Code de motif de rejet qui indique la raison fournie par le composant pour rejeter l’offre. Les valeurs possibles sont décrites dans le tableau 5.3-10. Cette valeur dépend du champ État. |
| 8 | Réservé | 24 | Réservé. N’utilisez pas. |
Les valeurs possibles pour l’octet de code RR sont décrites dans ce tableau.
Tableau 5.3-10 FIRMWARE_UPDATE_OFFER – Réponse d'information – Valeurs du code RR
| Code RR | Nom | Description |
|---|---|---|
| 0x00 | FIRMWARE_OFFER_REJECT_OLD_FW | L’offre a été rejetée, car la version du microprogramme proposé est antérieure ou identique au microprogramme actuel. |
| 0x01 | FIRMWARE_OFFER_REJECT_INV_COMPONENT | L’offre a été rejetée, car le microprogramme proposé n’est pas applicable à la plateforme du produit. Cela peut être dû à un ID de composant non pris en charge ou à une image proposée n’est pas compatible avec le matériel système. |
| 0x02 | FIRMWARE_UPDATE_OFFER SWAP_PENDING | Le microprogramme du composant a été mis à jour, mais un échange vers le nouveau microprogramme est en attente. Aucun traitement de mise à jour du microprogramme supplémentaire ne peut se produire tant que l’échange n’est pas terminé, généralement par le biais d’une réinitialisation. |
| 0x03 - 0x08 | (Réservé) | Réservé. N’utilisez pas. |
| 0x09 – 0xDF | (Réservé) | Réservé. N’utilisez pas. |
| 0xE0 – 0xFF | (Spécifique au fournisseur) | Ces valeurs sont utilisées par les concepteurs du protocole et la signification est spécifique au fournisseur. |
5.3.2.4 État
Tableau 5.3-11 FIRMWARE_UPDATE_OFFER – Réponse d'information sur l'offre – Disposition du statut
Les bits de l'octet de statut sont décrits dans ce tableau.
Tableau 5.3-12 FIRMWARE_UPDATE_OFFER – Informations sur l'offre – Bits d'état de la réponse
| Bit Offset | Champ | Taille | Description |
|---|---|---|---|
| 0 | Statut | 8 | Ce champ doit être défini sur FIRMWARE_UPDATE_OFFER_ACCEPT. Cela indique que le composant a décidé d’accepter l’offre. |
| 8 | Réservé. | 24 | Réservé. N’utilisez pas. |
5.4 FIRMWARE_UPDATE_OFFER – Étendue
Si l’ID de composant dans les octets d’informations sur le composant est défini sur 0xFE, les bits (15 octets) sont redéfinis pour indiquer la commande d’offre de l’hôte vers le microprogramme de l’appareil. Ce mécanisme permet l’extensibilité et un moyen pour l’hôte de fournir des informations spécifiques à l’appareil. Les paquets de commande d'offre sont renvoyés lorsque le composant est prêt à répondre Accepté.
5.4.1 Commande
Si l’ID de composant dans les octets d’informations sur le composant est défini sur 0xFE, les quatre DWORD sont redéfinis comme suit :
Tableau 5.4-1 FIRMWARE_UPDATE_OFFER - Disposition de commande étendue
5.4.1.1 Composant
Tableau 5.4-2 FIRMWARE_UPDATE_OFFER – Paquet de commande étendu – Commande – Disposition des composants
Les bits de l’octet composant sont décrits dans ce tableau.
Tableau 5.4-3 FIRMWARE_UPDATE_OFFER - Commande étendue - Bits du composant
| Bit Offset | Champ | Taille | Description |
|---|---|---|---|
| 0 | Code de commande | 8 | Cette valeur indique le type de commande. Cette valeur n’est pas un masque de bits et ne peut être qu’une des valeurs possibles décrites dans le tableau 5.4-4. |
| 8 | Réservé. | 8 | Réservé. N’utilisez pas. |
| 16 | ID de composant | 8 | Défini sur 0xFE. |
| 24 | Jeton | L'hôte insère un jeton unique dans le paquet d'offres destiné au composant. Ce jeton doit être renvoyé par le composant dans la réponse à l'offre. |
Tableau 5.4-4 FIRMWARE_UPDATE_OFFER - Commande étendue - Valeurs du code de commande
| Statut | Nom | Description |
|---|---|---|
| 0x01 | OFFER_NOTIFY_ON_READY | Envoyé par l'hôte si l'offre a été précédemment rejetée par le composant. |
| 0x02 – 0xFF | Réservé | Réservé |
5.4.1.2 Réservé B7 – B4
Réservé. N’utilisez pas.
5.4.1.3 Réservé B11 – B8
Réservé. N’utilisez pas.
5.4.1.4 Réservé B15 – B12
Réservé. N’utilisez pas.
5.4.2 Réponse
La réponse de la commande FIRMWARE_UPDATE_OFFER – Offer de l'appareil peut ne pas être reçue immédiatement. La réponse est définie comme suit.
Tableau 5.4-5 FIRMWARE_UPDATE_OFFER – Commande étendue – Disposition du paquet de réponses
5.4.2.1 Jeton
Tableau 5.4-6 FIRMWARE_UPDATE_OFFER- Réponse au paquet de commandes de l'offre – Disposition des jetons
Les bits de l’octet Token sont décrits dans ce tableau.
Tableau 5.4-7 FIRMWARE_UPDATE_OFFER – Réponse à la commande d'offre – Bits de jeton
| Bit Offset | Champ | Taille | Description |
|---|---|---|---|
| 0 | Réservé | 8 | Réservé. N’utilisez pas. |
| 8 | Réservé | 8 | Réservé. N’utilisez pas. |
| 16 | Réservé | 8 | Réservé. N’utilisez pas. |
| 24 | Jeton | 8 | Jeton permettant d’identifier l’hôte. |
5.4.2.2 Réservé B7 – B4
Réservé. N’utilisez pas.
5.4.2.3 Raison du rejet
Tableau 5.4-8 FIRMWARE_UPDATE_OFFER – Réponse au paquet d'informations sur l'offre – Disposition du RR
Les bits de l'octet Reject Reason sont décrits dans ce tableau.
Tableau 5.4-9 FIRMWARE_UPDATE_OFFER – Réponse à la commande d'offre – Code RR
| Bit Offset | Champ | Taille | Description |
|---|---|---|---|
| 0 | Code RR | 8 | Cette valeur dépend du champ État. Pour connaître les valeurs de code RR possibles, consultez le tableau 5.4-10. |
| 8 | Réservé | 24 | Réservé. N’utilisez pas. |
Les valeurs possibles pour l’octet de code RR sont décrites dans ce tableau.
Tableau 5.4-10 FIRMWARE_UPDATE_OFFER- Offre d'un pack de commande – Valeurs du code RR
| Code RR | Nom | Description |
|---|---|---|
| 0x00 | FIRMWARE_OFFER_REJECT_OLD_FW | L’offre a été rejetée, car la version du microprogramme proposé est antérieure ou identique au microprogramme actuel. |
| 0x01 | FIRMWARE_OFFER_REJECT_INV_COMPONENT | L’offre a été rejetée, car le microprogramme proposé n’est pas applicable à la plateforme du produit. Cela peut être dû à un ID de composant non pris en charge ou à une image proposée n’est pas compatible avec le matériel système. |
| 0x02 | FIRMWARE_UPDATE_OFFER SWAP_PENDING | Le microprogramme du composant a été mis à jour, mais un échange vers le nouveau microprogramme est en attente. Aucun traitement de mise à jour du microprogramme supplémentaire ne peut se produire tant que l’échange n’est pas terminé, généralement par le biais d’une réinitialisation. |
| 0x03 - 0x08 | (Réservé) | Réservé. N’utilisez pas. |
| 0x09 – 0xDF | (Réservé) | Réservé. N’utilisez pas. |
| 0xE0 – 0xFF | (Spécifique au fournisseur) | Ces valeurs sont utilisées par les concepteurs du protocole et la signification est spécifique au fournisseur. |
5.4.2.4 État
Tableau 5.4-11 FIRMWARE_UPDATE_OFFER – Réponse au paquet de commandes de l'offre – Disposition de l'état
Les bits de l'octet de statut sont décrits dans ce tableau.
Tableau 5.4-12 FIRMWARE_UPDATE_OFFER- Réponse au paquet de commandes de l'offre – Code RR
| Bit Offset | Champ | Taille | Description |
|---|---|---|---|
| 0 | Statut | 8 | Ce champ doit être défini sur FIRMWARE_UPDATE_OFFER_ACCEPT. Cela indique que le composant a décidé d’accepter l’offre. |
| 8 | Réservé. | 24 | Réservé. N’utilisez pas. |
5.5 FIRMWARE_UPDATE_CONTENT
L’hôte envoie cette commande au microprogramme de l’appareil pour fournir le contenu du microprogramme (autrement dit, l’image du microprogramme). Le fichier image entier n’est pas censé s’adapter à une seule commande. L’hôte doit diviser l’image en blocs plus petits et chaque commande envoie un bloc de l’image à la fois.
Avec chaque commande, l’hôte indique des informations supplémentaires : s’il s’agit du premier bloc, du dernier bloc, et ainsi de suite, du microprogramme. Le composant principal du microprogramme de l’appareil accepte chaque bloc de l’image de microprogramme entrante, le stocke dans sa mémoire et doit répondre à chaque commande individuellement.
Lorsque le composant principal reçoit le dernier bloc, le composant valide l’intégralité de l’image du microprogramme (vérification CRC, validation de signature). En fonction des résultats de ces vérifications, une réponse appropriée (échec ou réussite) est retournée pour le dernier bloc.
5.5.1 Commande
Tableau 5.5-1 Présentation de la commande FIRMWARE_UPDATE_CONTENT
5.5.1.1 En-tête (B7 - B0)
Tableau 5.5-2 Disposition de l'en-tête de commande FIRMWARE_UPDATE_CONTENT
Les bits de l’en-tête FIRMWARE_UPDATE_CONTENT sont décrits dans ce tableau.
Tableau 5.5-3 FIRMWARE_UPDATE_CONTENT – Bits d'en-tête
| Bit Offset | Champ | Taille | Description |
|---|---|---|---|
| 0 | Drapeaux | 8 | Ce champ fournit des informations supplémentaires sur la commande. Cette valeur est un masque d’indicateurs à utiliser pour les transferts de données. Les valeurs possibles sont décrites dans le tableau 5.5-4. |
| 8 | Longueur des données | 8 | Longueur du champ de données applicable indiquant le nombre d’octets à écrire. Étant donné la taille de cette commande, la valeur maximale autorisée pour la longueur est de 52 octets. |
| 16 | Numéro de séquence | 16 | Cette valeur est créée par l’hôte et est unique pour chaque paquet de contenu émis. Le composant doit retourner le numéro de séquence dans sa réponse à cette demande. |
| 32 | Adresse du microprogramme | 32 | Little Endian (LSB First) Adresse d'écriture des données. L'adresse est indexée à partir de 0. Le microprogramme utilise ce paramètre comme décalage pour déterminer l’adresse si nécessaire lors du placement de l’image en mémoire. |
Les valeurs possibles pour l'octet Flags sont décrites dans ce tableau.
Tableau 5.5-4 FIRMWARE_UPDATE_OFFER – Paquet de commandes d'offre – Valeurs des indicateurs
| Drapeau | Nom | Description |
|---|---|---|
| 0x80 | FIRMWARE_UPDATE_FLAG_FIRST_BLOCK | Cet indicateur indique qu’il s’agit du premier bloc de l’image du microprogramme. |
| 0x40 | FIRMWARE_UPDATE_FLAG_LAST_BLOCK | Cet indicateur indique qu’il s’agit du dernier bloc de l’image du microprogramme et que l’image est prête à être validée. Il est important que le microprogramme actuel sur le composant effectue la validation sur l’ensemble de l’image de microprogramme téléchargée après avoir écrit ce bloc en mémoire non volatile. |
5.5.1.2 Données
Tableau 5.5-5 Disposition des données de commande du FIRMWARE_UPDATE_CONTENT
Les bits des données FIRMWARE_UPDATE_CONTENT sont décrits dans ce tableau.
Tableau 5.5-6 FIRMWARE_UPDATE_CONTENT – Bits de données de commande
| Bit Offset | Champ | Taille | Description |
|---|---|---|---|
| 64 | Données | Max 52. | Tableau d'octets à écrire. L’hôte envoie généralement des blocs de 4 octets en fonction de l’architecture du produit. Tous les octets inutilisés à la fin doivent être remplis de 0. |
5.5.2 Réponse
Tableau 5.5-7 FIRMWARE_UPDATE_CONTENT Mise en page de la réponse de commande
5.5.2.1 Numéro de séquence
Tableau 5.5-8 Réponse FIRMWARE_UPDATE_CONTENT - Numéro de séquence
réponse 
Les bits de la réponse FIRMWARE_UPDATE_CONTENT (3-0) sont décrits dans ce tableau.
Tableau 5.5-9 FIRMWARE_UPDATE_CONTENT – Commande – Bits de réponse
| Bit Offset | Champ | Taille | Description |
|---|---|---|---|
| 0 | Numéro de séquence | 16 | Ce champ est le numéro de séquence envoyé par l’hôte dans la requête. |
| 16 | Réservé | 16 | Réservé. N’utilisez pas. |
5.5.2.2 État
Tableau 5.5-10 Réponse FIRMWARE_UPDATE_CONTENT – Disposition du statut
Les bits de la réponse FIRMWARE_UPDATE_CONTENT (7-4) sont décrits dans ce tableau.
Tableau 5.5-11 FIRMWARE_UPDATE_OFFER – Réponse – Bits d'état
| Bit Offset | Champ | Taille | Description |
|---|---|---|---|
| 0 | Statut | 8 | Cette valeur indique le code d’état retourné par le composant d’appareil. Il ne s'agit pas d'un bit à bit et il peut s'agir de l'une des valeurs décrites dans le tableau 5.5-12. |
| 8 | Réservé | 24 | Réservé. N’utilisez pas. |
Les valeurs possibles pour l’octet Status sont décrites dans ce tableau.
Tableau 5.5-12 Réponse FIRMWARE_UPDATE_OFFER – Valeurs des codes d'état
| Drapeau | Nom | Description |
|---|---|---|
| 0x00 | FIRMWARE_UPDATE_SUCCESS | La demande s’est terminée avec succès. |
| 0x01 | FIRMWARE_UPDATE_ERROR_PREPARE | Le composant n’était pas prêt à recevoir le contenu du microprogramme. S’il est utilisé, ce code est généralement utilisé dans une réponse au premier bloc. Par exemple, erreur d'effacement sur la mémoire flash. |
| 0x02 | FIRMWARE_UPDATE_ERROR_WRITE | La requête n’a pas pu enregistrer les octets. |
| 0x03 | FIRMWARE_UPDATE_ERROR_COMPLETE | La requête n'a pas pu établir l'échange en réponse à FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
| 0x04 | FIRMWARE_UPDATE_ERROR_VERIFY | La vérification du DWORD a échoué, en réponse à FIRMWARE_UPDATE_FLAG_VERIFY. |
| 0x05 | FIRMWARE_UPDATE_ERROR_CRC | Le CRC de l'image du microprogramme a échoué, en réponse à FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
| 0x06 | FIRMWARE_UPDATE_ERROR_SIGNATURE | La vérification de la signature du microprogramme a échoué en réponse à FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
| 0x07 | FIRMWARE_UPDATE_ERROR_VERSION | Échec de la vérification de la version du microprogramme en réponse à FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
| 0x08 | FIRMWARE_UPDATE_SWAP_PENDING | Le microprogramme a déjà été mis à jour et un échange est en attente. Aucune autre commande de mise à jour du microprogramme ne peut être acceptée tant que l’accessoire n’a pas été réinitialisé. |
| 0x09 | FIRMWARE_UPDATE_ERROR_INVALID_ADDR | Le microprogramme a détecté une adresse de destination non valide dans le contenu des données de message. |
| 0x0A | FIRMWARE_UPDATE_ERROR_NO_OFFER | La commande FIRMWARE_UPDATE_OFFER a été reçue sans recevoir d’abord une offre de mise à jour du microprogramme valide et acceptée. |
| 0x0B | FIRMWARE_UPDATE_ERROR_INVALID | Erreur générale pour la commande FIRMWARE_UPDATE_OFFER, comme une longueur de données applicable invalide. |
5.5.2.3 Réservé B8 – B11
Réservé. N’utilisez pas.
5.5.2.4 Réservé B12 – B15
Réservé. N’utilisez pas.
6 Annexe 1 : Exemple de séquence de commandes de programmation de mise à jour du microprogramme
6.1 Exemple 1
Tenez compte du microprogramme d’appareil suivant :
Composant principal - ID de composant 1 - Microprogramme actuel version 7.0.1
Sous-composant - ID de composant 2 - Microprogramme actuel version 12.4.54
Sous-composant - ID de composant 3 - Microprogramme actuel version 4.4.2
Sous-composant - ID de composant 4 - Microprogramme actuel version 23.32.9
L’hôte a ces trois images de micrologiciel :
ID de composant 1 - Microprogramme version 7.1.3
ID de composant 2 - Firmware version 12.4.54
ID du composant 3 - Firmware version 4.5.0
La séquence sera :
L'hôte offre : ID du composant 1 – Version du microprogramme 7.1.3
Le composant principal accepte l’offre
L’hôte envoie l’image du microprogramme
Le composant principal accepte le microprogramme, le valide
Offres de l'hôte : ID du composant 2 – Version du microprogramme 12.4.54
Le composant principal rejette l’offre
Offres de l'hôte : ID du composant 3 – Version du microprogramme 4.5.0
Le composant principal accepte l’offre
L’hôte envoie l’image du microprogramme
Le composant principal accepte le microprogramme, le valide
Étant donné que toutes les offres n’ont pas été rejetées, l’hôte répète toutes les offres.
L'hôte offre : ID du composant 1 – Version du microprogramme 7.1.3
Le composant rejette
Offres de l'hôte : ID du composant 2 – Version du microprogramme 12.4.54
Le composant rejette
Offres de serveur : Composant ID 3 - Version du microprogramme 4.5.0
Le composant rejette
6.2 Exemple 2
Tenez compte du microprogramme d’appareil suivant :
Composant principal - ID de composant 1 - Microprogramme actuel version 7.0.1
Sous-composant - ID de composant 2 - Microprogramme actuel version 12.4.54
Sous-composant - ID de composant 3 - Microprogramme actuel version 7.4.2
Sous-composant - ID de composant 4 - Microprogramme actuel version 23.32.9
L’hôte a ces trois images de firmware :
ID de composant 1 - Microprogramme version 8.0.0
ID de composant 2 - Firmware version 12.4.54
ID de composant 3 - Version de firmware 9.0.0
En outre, l’implémentation exige que la version du microprogramme des sous-composants ne soit pas inférieure à la version du microprogramme exécutée sur le composant principal. L'hôte n'est pas au courant de cette exigence et c'est au composant principal d'assurer cette règle.
La séquence sera :
L'hôte propose : ID du composant 1 – Version du microprogramme 8.0.0
Le composant primaire rejette l'offre (parce que le composant ID 3 n'est pas encore mis à jour).
Offres de l'hôte : ID du composant 2 – Version du microprogramme 12.4.54
Le composant primaire rejette
L'hôte propose : ID du composant 3 – Version du microprogramme 9.0.0
Le composant principal accepte l’offre
L’hôte envoie l’image du microprogramme
Le composant principal accepte le microprogramme, le valide
Parce que toutes les offres n'ont pas été rejetées, l'hôte revoit toutes les offres.
L'hôte propose : ID du composant 1 – Version du microprogramme 8.0.0
Le composant principal accepte l’offre
L’hôte envoie l’image du microprogramme
Le composant principal accepte le microprogramme, le valide
Offres de l'hôte : ID du composant 2 – Version du microprogramme 12.4.54
Le composant primaire rejette
L'hôte propose : ID du composant 3 – Version du microprogramme 9.0.0
Le composant primaire rejette