Especificación del protocolo de actualización de firmware de componentes (CFU)
Esta especificación describe un protocolo HID genérico para actualizar el firmware de los componentes presentes en un equipo o accesorios. La especificación permite que un componente acepte firmware sin interrumpir la operación del dispositivo durante una descarga. La especificación admite configuraciones en las que el componente que acepta el firmware puede tener subcomponentes, que requieren imágenes de firmware independientes. La especificación permite a los componentes a cargo decidir si se debe aceptar el firmware. También actúa como una optimización porque la imagen de firmware solo se envía al componente si es capaz o listo para aceptarla.
Nota
CFU está disponible en Windows 10, versión 2004 (Actualización de mayo de 2020 de Windows 10) y versiones posteriores.
Contenido
- 1 Introducción
- 2 Arquitectura de hardware compatible
- 3 Requisitos previos del protocolo
- 4 Información general sobre protocolos CFU
- 4.1 Secuencia de comandos de programación de actualización de firmware
- Estado 4.1.1: Notificación de inicialización del host
- 4.1.2 Estado: Notificación OFFER_INFO_START_OFFER_LIST
- 4.1.3 Estado: Enviar comando FIRMWARE_UPDATE_OFFER
- 4.1.4 Estado: Envío de firmware
- 4.1.5 Estado de decisión: ¿Hay más ofertas
- 4.1.6 Estado: Notificación de OFFER_INFO_END_OFFER_LIST
- 4.1.7 Estado de decisión: Reproducción de lista de ofertas
- estado 4.1.8: el dispositivo está ocupado
- 4.1 Secuencia de comandos de programación de actualización de firmware
- Formato de Paquete del Protocolo CFU 5
- 6 Apéndice 1: Secuencia de comandos de programación de actualización de firmware de ejemplo
Tablas
Tabla 5.1-1 Estructura de respuesta de GET_FIRMWARE_VERSION
tabla 5.1-2 Respuesta de GET_FIRMWARE_VERSION - Diseño de encabezado
tabla 5.1-3 Respuesta de GET_FIRMWARE_VERSION - Bits de encabezado
Tabla 5.1-4 Respuesta de GET_FIRMWARE_VERSION - Versión del componente y diseño de propiedades
Tabla 5.1-5 Respuesta de GET_FIRMWARE_VERSION - Versión del componente y bits de propiedades
Tabla 5.2-1 Disposición del Comando FIRMWARE_UPDATE_OFFER
Tabla 5.2-2 Comando FIRMWARE_UPDATE_OFFER - Diseño de información de componentes
Tabla 5.2-3 Comando FIRMWARE_UPDATE_OFFER - Bits de información de componentes
Tabla 5.2-4 Comando FIRMWARE_UPDATE_OFFER - Diseño de versión de firmware
Tabla 5.2-5 Comando FIRMWARE_UPDATE_OFFER - Bits de versión de firmware
Tabla 5.2-6 Comando FIRMWARE_UPDATE_OFFER - Diseño específico del proveedor
Tabla 5.2-7 Comando FIRMWARE_UPDATE_OFFER - Varios y versión del protocolo
Tabla 5.2-8 Diseño del token de respuesta de FIRMWARE_UPDATE_OFFER
Tabla 5.2-9 Respuesta de FIRMWARE_UPDATE_OFFER - Diseño del token
Tabla 5.2-10 Respuesta de FIRMWARE_UPDATE_OFFER - Bits de token
Tabla 5.2-11 Respuesta de FIRMWARE_UPDATE_OFFER - Diseño de motivo de rechazo
Tabla 5.2-12 Respuesta de FIRMWARE_UPDATE_OFFER - Bits de motivo de rechazo
Tabla 5.2-13 Valores de código de RR de respuesta de FIRMWARE_UPDATE_OFFER
Tabla 5.2-14 Diseño de estado de respuesta de FIRMWARE_UPDATE_OFFER
Tabla 5.2-15 Respuesta de FIRMWARE_UPDATE_OFFER - Bits de estado
Tabla 5.2-16 Valores de estado de respuesta de FIRMWARE_UPDATE_OFFER
Tabla 5.3-1 FIRMWARE_UPDATE_OFFER - Diseño de comandos de información
Tabla 5.3-2 FIRMWARE_UPDATE_OFFER - Comando de información - Diseño de componentes
Tabla 5.3-3 Comando FIRMWARE_UPDATE_OFFER - Comando de información - Bits de componentes
Tabla 5.3-4 FIRMWARE_UPDATE_OFFER - Comando de información - Valores de código de información
Tabla 5.3-5 FIRMWARE_UPDATE_OFFER - Diseño de respuesta de información
Tabla 5.3-6 FIRMWARE_UPDATE_OFFER - Diseño del token de respuesta de paquetes de información
Tabla 5.3-7 FIRMWARE_UPDATE_OFFER - Respuesta de información - Bits de token
Tabla 5.3-8 FIRMWARE_UPDATE_OFFER - Diseño de respuesta - Diseño de código de RR
Tabla 5.3-9 FIRMWARE_UPDATE_OFFER - Respuesta de información de oferta - Bits de código de RR
Tabla 5.3-10 FIRMWARE_UPDATE_OFFER - Respuesta de información - Valores de código de RR
Tabla 5.3-11 FIRMWARE_UPDATE_OFFER - Diseño de estado de respuesta de información de oferta
Tabla 5.3-12 FIRMWARE_UPDATE_OFFER - Información de oferta - Bits de estado de respuesta
Tabla 5.4-1 FIRMWARE_UPDATE_OFFER - Diseño de comandos extendido
Tabla 5.4-2 FIRMWARE_UPDATE_OFFER - Paquete de comandos extendidos - Comando - Diseño de componentes
Tabla 5.4-3 FIRMWARE_UPDATE_OFFER - Comando extendido - Bits de componente
Tabla 5.4-4 FIRMWARE_UPDATE_OFFER - Comando extendido - Valores de código de comando
Tabla 5.4-5 FIRMWARE_UPDATE_OFFER - Diseño de respuesta de paquetes de comandos extendidos
Tabla 5.4-6 FIRMWARE_UPDATE_OFFER - Respuesta de paquetes de comandos de oferta - Diseño de token
Tabla 5.4-7 FIRMWARE_UPDATE_OFFER - Respuesta del comando de oferta - Bits de token
Tabla 5.4-8 FIRMWARE_UPDATE_OFFER - Diseño de RR de respuesta de paquetes de información de oferta
Tabla 5.4-9 FIRMWARE_UPDATE_OFFER - Respuesta del comando de oferta - Código RR
Tabla 5.4-10 FIRMWARE_UPDATE_OFFER - Paquete de comandos de oferta - Valores de código RR
Tabla 5.4-11 FIRMWARE_UPDATE_OFFER - Diseño de estado de respuesta de paquetes de comandos de oferta
Tabla 5.4-12 FIRMWARE_UPDATE_OFFER - Código RR de respuesta de paquete de comandos de oferta
Tabla 5.5-1 Estructura del Comando FIRMWARE_UPDATE_CONTENT
Tabla 5.5-2 Diseño de encabezado de comando FIRMWARE_UPDATE_CONTENT
Tabla 5.5-3 Bits de encabezado de FIRMWARE_UPDATE_CONTENT
Tabla 5.5-4 FIRMWARE_UPDATE_OFFER - Paquete de comandos de oferta - Valores de indicador
Tabla 5.5-5 Diseño de datos de comando FIRMWARE_UPDATE_CONTENT
Tabla 5.5-6 Bits de datos de comando FIRMWARE_UPDATE_CONTENT
Tabla 5.5-7 Diseño de respuesta de comando FIRMWARE_UPDATE_CONTENT
Tabla 5.5-8 Respuesta de FIRMWARE_UPDATE_CONTENT - Número de secuencia
Tabla 5.5-9 FIRMWARE_UPDATE_CONTENT - Comando - Bits de respuesta
Tabla 5.5-10 Diseño de estado de respuesta de FIRMWARE_UPDATE_CONTENT
Tabla 5.5-11 FIRMWARE_UPDATE_OFFER - Respuesta - Bits de estado
Tabla 5.5-12 FIRMWARE_UPDATE_OFFER - Respuesta - Valores de código de estado
1 Introducción
Los equipos y accesorios actuales tienen componentes internos que realizan operaciones complejas. Para garantizar un producto de calidad, es necesario actualizar con frecuencia el comportamiento de estos dispositivos en fases posteriores de desarrollo o después de que se hayan enviado a los clientes. La actualización podría corregir problemas funcionales o de seguridad identificados o una necesidad de agregar nuevas características. Una gran parte de la lógica compleja está en el firmware que se ejecuta en el dispositivo, que es actualizable.
Esta especificación describe un protocolo HID genérico para actualizar el firmware de los componentes presentes en un equipo o sus accesorios. La implementación de HID está fuera del ámbito de la especificación.
Algunas de las características del protocolo son:
El protocolo se basa en HID, es omnipresente y tiene compatibilidad con Windows de serie a través de varios buses de interconexión, como USB e I2C. Por lo tanto, se puede aprovechar la misma solución de software (controlador) para actualizar el firmware de todos los componentes.
Nota
Dado que la especificación está basada en paquetes, es fácil adaptarla a escenarios que no son HID.
La especificación permite que un componente acepte firmware sin interrumpir la operación del dispositivo durante la descarga. Permite una mejor experiencia para los usuarios porque no tienen que esperar a que se complete el proceso de actualización de firmware antes de poder reanudar otras tareas. El nuevo firmware se puede invocar en una sola operación atómica a la vez que tiene un impacto mínimo en el usuario.
La especificación admite configuraciones en las que el componente que acepta el firmware puede tener subcomponentes, que requieren imágenes de firmware independientes.
Nota
El proceso de transferencia del firmware de un componente al subcomponente está fuera del ámbito de esta especificación.
La especificación admite el concepto de una oferta y se basa en el componente a cargo para decidir si acepta el firmware. La decisión de aceptar el nuevo firmware no es trivial. Puede haber dependencias entre el tipo de firmware o la versión y el tipo o versión subyacentes del hardware al que se aplica el nuevo firmware. Una oferta también actúa como un mecanismo de optimización porque la imagen de firmware se envía al componente solo si este es capaz de aceptarla o está listo para hacerlo.
1.1 Glosario
| Término | Descripción |
|---|---|
| Id. de componente | En un dispositivo con varios componentes, un identificador de componente identifica de forma única cada componente. |
| CRC | Comprobación de redundancia cíclica Algoritmo hash no criptográfico usado para generar un resumen o huella digital de un bloque de datos. El CRC se usa como comprobación para garantizar que el bloque de datos no ha cambiado desde que se calculó el CRC. El CRC no es infalible, pero proporciona confianza en que los datos se recibieron correctamente. |
| Dispositivo | Colección de componentes (un componente principal y cero o más subcomponentes). El dispositivo es visible para el sistema operativo como una sola unidad. El host interactúa con el dispositivo, que normalmente es el componente principal. Un equipo puede tener varios dispositivos en él. Con respecto a esta especificación, las comunicaciones a 2 dispositivos diferentes son totalmente independientes. |
| Controlador | Controlador escrito mediante el marco de Windows Driver Foundation (WDF). |
| Firmware | Código que se ejecuta en el hardware físico. El firmware es actualizable y normalmente reside en la memoria programable asociada al hardware. |
| Equipamiento | Una pieza física de silicio en el ordenador. |
| Componente principal | Una pieza de hardware en un equipo y el firmware para él. En el contexto de esta especificación, un componente es la entidad que necesita y acepta la actualización de firmware. |
| Segmento | Una imagen de firmware de un componente se puede segmentar en segmentos más pequeños. Cada segmento es una imagen de firmware pequeña. |
| Id. de segmento | Si un firmware de un componente se segmenta en segmentos más pequeños, el identificador de segmento es el identificador único del segmento. |
| Firma | Un medio criptográfico para determinar si la imagen de firmware se ha modificado por medios no autorizados. Las firmas son opcionales, pero se recomiendan y están fuera del alcance de esta especificación. |
| Subcomponente | En función de la arquitectura de hardware, no todos los componentes pueden ser visibles para el sistema operativo, ya que pueden estar conectados después de un componente que es visible para el sistema. Estos componentes se conocen como subcomponentes en esta especificación. |
| Tratado de Libre Comercio | Colección de nivel superior de HID. |
| Token | Identificador de una sesión de host. Un host crea un token y lo envía en comandos y el dispositivo lo devuelve en la respuesta. Los tokens se pueden usar para serializar determinadas transacciones o para identificar que se ha perdido una sesión y otra iniciada. |
1.2 Ámbito
1.2.1 Objetivos
Se requiere una solución independiente de bus para evitar un nuevo protocolo para cada tipo de bus. HID es omnipresente y aborda ese requisito.
La capacidad de admitir la actualización de firmware para un dispositivo de varios componentes, donde un componente actúa como componente principal y otros son subcomponentes conectados al componente principal. Cada componente requiere su propio firmware con dependencias no triviales entre sí.
Un modelo de controlador común para descargar la imagen de firmware en el componente. A continuación, el componente tiene algoritmos específicos de subcomponente para reenviar a los subcomponentes. Los subcomponentes también pueden realizar comprobaciones de validez en su firmware y volver a pasar los resultados al componente principal.
La capacidad de admitir la actualización de firmware mientras la operación del dispositivo está en curso.
La capacidad de actualizar o revertir el firmware en dispositivos de producción mediante herramientas autorizadas, y actualizar los dispositivos en el mercado a través de Windows Update.
Flexibilidad para admitir firmware en desarrollo o firmware en el mercado.
La capacidad de segmentar una imagen de firmware grande en segmentos más pequeños para que el componente acepte la imagen de firmware.
1.2.2 No objetivos
Definir el formato interno de la imagen de firmware: para el host, la imagen de firmware es un conjunto de entradas de dirección y carga.
Firmar, cifrar o validar el firmware aceptado: esta especificación no describe cómo firmar y cifrar las imágenes de firmware. Es necesario que el firmware actual previsto que se ejecuta en el componente valide el firmware que se está descargando.
Definir un mecanismo sobre cómo interactúa el componente con los subcomponentes: el host interactúa con el dispositivo como una sola unidad, normalmente el componente principal. El componente debe actuar como un puente para la comunicación relacionada con el firmware de subcomponente.
2 Arquitectura de hardware compatible
Para admitir un diseño de hardware flexible, el protocolo admite un dispositivo multicomponente donde cada componente requiere su propia imagen de firmware. En el diseño, un componente es el componente principal y los subcomponentes dependientes están conectados a ese componente principal. Cada componente se describe de forma única mediante un identificador de componente.
El dispositivo multicomponente es visible para el sistema operativo como una sola unidad. El host solo interactúa con el dispositivo, normalmente el componente principal mediante este protocolo CFU. La comunicación entre el componente y sus subcomponentes está fuera del ámbito de esta especificación.
En un equipo, puede haber muchos dispositivos diferentes (donde un dispositivo puede tener uno o varios componentes). En el contexto de este protocolo, la comunicación con cada dispositivo es independiente. Cada dispositivo tiene una instancia correspondiente del host.
3 Requisitos previos del protocolo
En esta sección se enumeran los prerrequisitos y los procedimientos recomendados que se deben implementar para aprovechar este protocolo.
Uso de imágenes atómicas
Una imagen de firmware de un componente no se usa hasta que se haya descargado correctamente toda la imagen de firmware. En caso de que el firmware se divida en varios segmentos, la imagen no se debe usar hasta que se reciba el segmento final del remitente. Las comprobaciones de integridad deben realizarse en la imagen final. Se recomienda que el transporte, que se use para entregar la imagen de firmware, tenga mecanismos de corrección de errores y reintento implementados para evitar una descarga repetida en caso de errores de transporte.
La actualización del firmware no debe interrumpir la operación del dispositivo
El dispositivo que acepta la imagen de firmware debe poder funcionar durante la actualización. El dispositivo debe tener memoria adicional para almacenar y validar el firmware entrante, mientras que su firmware actual no se sobrescribe.
Autenticación e integridad
El implementador decide que factores que constituyen una imagen de firmware auténtica. Se recomienda que el firmware actual del componente debe validar al menos el CRC de la imagen de firmware entrante. El firmware actual también debe emplear firmas digitales o otros algoritmos de detección de errores. Si se produce un error en la validación, el firmware rechaza la actualización. Recuperación de errores
Si la imagen de firmware se descarga sin éxito, el dispositivo no debe invocar el nuevo firmware y debe seguir funcionando con el firmware existente. El host puede reintentar la actualización. La frecuencia de reintento es específica de la implementación.
Confidencialidad
Opcional. Se puede cifrar un segmento de firmware. Las técnicas de cifrado y descifrado están fuera del ámbito de esta especificación. Esta especificación trata la carga del firmware como un flujo de datos, independientemente de si está cifrado.
Protección contra reversión
El componente principal aplica las políticas de reversión, las cuales son específicas de la implementación. El firmware actual del componente valida las imágenes de firmware entrantes según políticas internas, en las que el número de versión debe ser más reciente, ni se puede cambiar el tipo de versión de lanzamiento a depuración, etc. El protocolo permite a la mensajería indicar que se acepta una actualización incluso si infringe las directivas de reversión.
Información general sobre el protocolo CFU 4
El protocolo CFU es un conjunto de comandos y respuestas necesarios para enviar las nuevas imágenes de firmware desde el host al dispositivo para el que está previsto el firmware.
En un nivel alto, el protocolo recorre en iteración todas las imágenes de firmware que se van a enviar al dispositivo. Para cada imagen de firmware, el host ofrece para enviar el archivo al dispositivo. Solo si el dispositivo acepta la oferta, el host envía el archivo.
Para admitir casos en los que un pedido de actualización de dispositivo tiene dependencias, es posible que el dispositivo no acepte determinadas ofertas en el primer paso, por lo que el protocolo permite al host volver a enviar todas las ofertas de firmware al dispositivo hasta que se resuelvan todas las dependencias.
4.1 Secuencia de comandos de programación de actualizaciones de firmware
Esta es la secuencia de comandos de CFU para actualizar la imagen de firmware.
4.1.1 Estado: Notificación de inicialización del host
Una vez que el host se inicializa y ha identificado un conjunto de ofertas que necesita enviar al dispositivo, el host emite un comando OFFER_INFO_START_ENTIRE_TRANSACTION para indicar al componente que el host está inicializado. El propósito de este comando es notificar al firmware del dispositivo actual que hay disponible una nueva instancia del host. Esta notificación es útil cuando una instancia anterior del host finaliza inesperadamente. El dispositivo debe completar este comando correctamente.
4.1.2 Estado: Notificación OFFER_INFO_START_OFFER_LIST
En este estado, host emite el comando OFFER_INFO_START_OFFER_LIST para indicar que está listo para enviar las ofertas al firmware del dispositivo actual. El componente principal del dispositivo debe completar este comando correctamente.
Este comando es útil porque el host puede enviar todas las ofertas al dispositivo más de una vez.
4.1.3 Estado: Enviar FIRMWARE_UPDATE_OFFER comando
El host envía una oferta al componente principal (o su subcomponente) para comprobar si el componente desea aceptar o rechazar el firmware. La oferta contiene todos los metadatos necesarios de la imagen de firmware, de modo que el firmware actual del componente pueda decidir si aceptar, posponer, omitir o rechazar la oferta.
La oferta puede ser para el componente principal o el subcomponente. Si el componente puede aceptar la oferta, se prepara para recibir el firmware. Esto puede implicar la preparación de un banco de memoria para recibir la imagen de firmware entrante. Es posible que el componente no acepte la oferta, por ejemplo, que el componente ya tenga una versión de firmware más reciente (o la misma) que el host pretende enviar. Por más motivos, vea los ejemplos descritos en el Apéndice 1: Secuencia de comandos de programación de actualización de firmware de ejemplo.
Incluso si se acepta una oferta, el componente principal puede seguir rechazando la imagen de firmware después de la descarga de errores de integridad o reversión de las comprobaciones de la imagen real recibidas. El componente debe comprobar cada propiedad de la imagen del firmware independientemente de cualquier información de la oferta.
El host emite el comando FIRMWARE_UPDATE_OFFER para notificar al componente principal sobre la imagen de firmware que el host pretende enviar.
Si el componente acepta la oferta, tendrá el estado FIRMWARE_UPDATE_OFFER_ACCEPT, aceptando así la oferta.
Si el firmware del dispositivo está ocupado y el componente principal no puede aceptar esto o la siguiente oferta actualmente, envía una respuesta ocupada con estado FIRMWARE_UPDATE_OFFER_BUSY.
Si el firmware actual está interesado en la oferta, sin embargo, no puede aceptar la oferta (por ejemplo, debido a una dependencia de una actualización que falta para el subcomponente), responde con un FIRMWARE_UPDATE_OFFER_SKIP que indica que está interesado en este firmware, pero no puede aceptarlo. A continuación, el host continúa con la siguiente oferta y debe volver a ofrecer este firmware más adelante.
Si el firmware actual no está interesado en la oferta (por ejemplo, es una versión anterior), responde con un estado de FIRMWARE_UPDATE_OFFER_REJECT que proporciona el motivo de rechazo adecuado. Este estado no indica que el host no puede volver a enviar esta oferta en el futuro. El host normalmente envía cada oferta cada vez que inicializa o vuelve a enviar la lista de ofertas al dispositivo (consulte la notificación Estado: OFFER_INFO_START_OFFER_LIST).
4.1.4 Estado: Enviar firmware
En este estado, el host comienza a enviar la imagen de firmware al componente principal, para el que el componente ha aceptado previamente la oferta.
Dado que es probable que el contenido de la imagen de firmware supere los límites de carga de un solo comando, el host divide las imágenes de firmware en paquetes. El host envía cada paquete secuencialmente en un comando independiente de CONTENIDO de ACTUALIZACIÓN DE FIRMWARE. El componente principal debe generar un paquete de respuesta para cada comando.
Cada comando FIRMWARE_UPDATE CONTENT describe una dirección de desplazamiento que incluye una carga útil parcial de firmware. El componente usa el desplazamiento para determinar la dirección en la que se debe almacenar la carga parcial del firmware. El dispositivo escribe el contenido en una ubicación adecuada y confirma el comando mediante el envío de una respuesta.
Para el primer paquete que envía el host, establece la marca FIRMWARE_UPDATE_FLAG_FIRST_BLOCK, que indica al dispositivo que es el primer paquete de la imagen de firmware. Si el dispositivo aún no se ha preparado para recibir el firmware, puede hacerlo en este momento.
Para el último paquete que el host envía, establece la marca FIRMWARE_UPDATE_FLAG_LAST_BLOCK.
Después de que el firmware actual del dispositivo haya escrito la carga de firmware parcial incluida en este comando, debe realizar comprobaciones de validación y autenticación en la imagen de firmware entrante antes de enviar una respuesta. Esto incluye mínimamente:
Una verificación CRC para asegurar la integridad de toda la imagen del firmware.
Si la comprobación CRC se realiza correctamente, se puede llevar a cabo la verificación opcional de una firma de la imagen entrante.
Después de la comprobación de firma opcional, una comprobación de versión para asegurarse de que la nueva versión de firmware sea la misma o más reciente que el firmware existente.
En caso de que la imagen de firmware entrante se divida en segmentos más pequeños, depende del firmware actual determinar si es el último segmento de la imagen de firmware y, posteriormente, incluir todos los segmentos como parte de la validación.
Si se superan las comprobaciones anteriores, el firmware actual puede configurar el dispositivo para cambiar a la nueva imagen en el siguiente reinicio e informa al host del éxito. Normalmente, el componente no inicia un autorreinicialización. Esto es para evitar interrupciones en cualquier software, firmware, entidades de hardware con las que interactúa el componente. Sin embargo, eso no es un requisito y puede variar en función de la implementación.
Si se produce un error en los pasos de comprobación, el firmware no debe configurar un intercambio en el siguiente restablecimiento y debe indicar una respuesta de error al host.
4.1.5 Estado de decisión: ¿Hay más ofertas?
En este estado, el host determina si hay más ofertas para enviar al dispositivo.
4.1.6 Estado: Notificación de OFFER_INFO_END_OFFER_LIST
Este estado se alcanza cuando el host ha enviado todas las ofertas al componente principal en el firmware del dispositivo actual. El host envía el comando OFFER_INFO_END_OFFER_LIST para indicar que ha enviado todas las ofertas al componente.
El dispositivo debe completar este comando correctamente.
4.1.7 Estado de decisión: Reproducción de lista de ofertas
El host determina si necesita volver a enviar todas las ofertas. Ese caso podría producirse si el componente principal había omitido algunas ofertas y aceptado otras. El host debe volver a reproducir la lista de ofertas.
Puede haber otra lógica específica de implementación que pueda dar lugar a una decisión de reproducir la lista de ofertas.
4.1.8 Estado: el dispositivo está ocupado
Este estado implica que un dispositivo devolvió una respuesta de ocupado a una oferta.
El host envía un comando OFFER_NOTIFY_ON_READY al que el dispositivo no responde con la aceptación hasta que el dispositivo esté libre.
5 Formato de paquete de protocolo CFU
El protocolo CFU se implementa como conjunto de comandos y respuestas. El protocolo es secuencial por naturaleza. Para cada comando que el host envía a un componente, se espera que el componente responda (a menos que se indique explícitamente lo contrario en esta especificación). El host no envía el comando siguiente, hasta que se recibe una respuesta válida para el comando anterior que envió.
En caso de que el componente no responda en un período o envíe una respuesta no válida, el host puede reiniciar el proceso desde el principio. Este protocolo no define un valor de tiempo de espera específico.
Hay comandos para obtener la información de versión del firmware actual en el componente; para enviar la oferta y enviar la imagen de firmware.
Sin embargo, el host no necesita retener una oferta en función de la respuesta recibida del componente principal sobre la información de la versión consultada. La información se hace accesible para registro u otros fines.
5.1 GET_FIRMWARE_VERSION
Obtiene las versiones de firmware actuales del componente principal (y sus subcomponentes). El comando no tiene ningún argumento.
5.1.1 Comando
El host envía este comando para consultar las versiones de los firmwares actuales en el componente principal (y sus subcomponentes). El host puede usarlo para confirmar si el firmware se actualizó correctamente. Al recibir este comando, el componente principal responde con la versión de firmware para sí misma y todos los subcomponentes.
5.1.2 Respuesta
El componente responde con la versión de firmware del componente principal y los subcomponentes. El tamaño de respuesta es de 60 bytes, lo que permite la información de versión de hasta siete componentes (uno principal y hasta seis subcomponentes).
Tabla 5.1-1 Estructura de respuesta de GET_FIRMWARE_VERSION
5.1.2.1 Encabezado
tabla 5.1-2 Respuesta de GET_FIRMWARE_VERSION - Diseño de encabezado
El encabezado de la respuesta proporciona la siguiente información.
tabla 5.1-3 Respuesta de GET_FIRMWARE_VERSION - Bits de encabezado
| Desplazamiento de bits | Campo | Tamaño | Descripción |
|---|---|---|---|
| 0 | Recuento de componentes | 8 | Número de componentes descargables administrados a través de este mecanismo para este componente. El recuento de componentes determina el tamaño máximo de la tabla. Actualmente se admiten hasta 7 componentes para asegurarse de que la respuesta puede caber en los 60 bytes permitidos. |
| 8 | Reservado | 16 | Campos reservados. El remitente debe establecerlos en 0. El receptor debe omitir este valor. |
| 24 | Versión del protocolo | 4 | Los bits de revisión de actualización de firmware representan la revisión del protocolo de actualización FW que se está usando actualmente en el transporte. Para la interfaz definida aquí, la revisión de actualización de firmware debe ser 0010b. |
| 28 | Reservado | 3 | Campos reservados. El remitente debe establecerlos en 0. El receptor debe omitir este valor. |
| 31 | E | 1 | La marca de extensión es un enlace de protocolo futuro para permitir que se notifiquen componentes adicionales. |
5.1.2.2 Versión y propiedades del componente
Para cada componente, se utilizan dos DWORDs para describir sus propiedades, hasta un máximo de 7 componentes por cada uno. Si el recuento de componentes del encabezado es menor que 7, los DWORDS sin usar al final de la respuesta deben establecerse a 0.
Tabla 5.1-4 GET_FIRMWARE_VERSION Respuesta - Versión del Componente y Diseño de Propiedades
Cada información específica del componente se describe en dos DWORD de la siguiente manera:
Tabla 5.1-5 Respuesta de GET_FIRMWARE_VERSION - Versión del componente y bits de propiedades
| Desplazamiento de bits | Campo | Tamaño | Descripción |
|---|---|---|---|
| 0 | Versión de firmware | 32 | Devuelve la versión del firmware actual de ese componente. Esta especificación no exige ningún formato específico para la versión de firmware. Consulte la sección Versión de firmware para obtener instrucciones. |
| 32 | Banco | 2 | Opcional. En función de la arquitectura, el hardware del componente puede tener varios bancos en los que se puede almacenar el firmware. Dependiendo de la implementación, el remitente puede especificar el banco en el que el firmware existe actualmente. Este campo es Obligatorio condicional: la compatibilidad es opcional; sin embargo, no se debe usar para ningún otro propósito. |
| 34 | Reservado | 2 | Campos reservados. El remitente debe establecerlos en 0. El receptor debe omitir este valor. |
| 36 | Específico del proveedor | 4 | Campo específico del proveedor que se puede usar de manera específica para la implementación. Un proveedor podría usar estos bits para codificar información como: - Tipo de firmware: versión preliminar, autohospedaje/producción; depuración/venta al por menor - Fase de desarrollo - Id. de producto, para evitar que los componentes reciban firmware para otros productos mediante el mismo protocolo de actualización. |
| 40 | Id. de componente | 8 | Identificador único del componente. |
| 48 | Específico del proveedor | 16 | Campo específico del proveedor que se puede usar de una manera específica para la implementación. |
5.1.3 Asignación a HID
Esto se implementa como una solicitud de la característica Get de HID con un tamaño de respuesta de 60 bytes, incluyendo el identificador de informe. La longitud del informe de características es suficiente para incluir toda la respuesta de GET_FIRMWARE_VERSION. No hay datos asociados a la solicitud de función "Get Feature" del host.
5.2 FIRMWARE_UPDATE_OFFER
Determina si el componente principal acepta o rechaza un firmware.
5.2.1 Comando
El host envía este comando al componente para determinar si acepta o rechaza un firmware. El host debe enviar una oferta y el componente debe aceptar la oferta para que el host pueda enviar el firmware.
El paquete FIRMWARE_UPDATE_OFFER Comando se define de la manera siguiente.
Tabla 5.2-1 FIRMWARE_UPDATE_OFFER Diseño de comandos
5.2.1.1 Información del componente
Tabla 5.2-2 FIRMWARE_UPDATE_OFFER Comando: Diseño de información de componentes
comando 
Los bits del byte de información del componente se describen en esta tabla.
Tabla 5.2-3 Comando FIRMWARE_UPDATE_OFFER - Bits de información de componentes
| Desplazamiento de bits | Campo | Tamaño | Descripción |
|---|---|---|---|
| 0 | Número de segmento | 8 | Este campo se usa en caso de que el firmware de un componente se segmente en segmentos más pequeños. Si se usa, este valor indica el segmento contenido en el paquete de carga posterior. Por ejemplo, si la imagen de firmware del componente es muy grande y el componente principal solo puede tomar partes más pequeñas de la imagen a la vez, este campo puede usarse para indicar que esta oferta es para el i-th segmento de la imagen completa. Se puede enviar una oferta independiente al componente principal que contiene el i+1º segmento de la imagen, etc. |
| 8 | Reservado | 6 | Campos reservados. El remitente debe establecerlos en 0. El receptor debe omitir este valor. |
| 14 | Yo | 1 | Forzar el restablecimiento inmediato (I) - Este valor del bit se utiliza para indicar al componente que debe reiniciarse inmediatamente después de que se complete y verifique la descarga del firmware, para así invocarlo de inmediato. - Este indicador está pensado para la fase de desarrollo. |
| 15 | V | 1 | Forzar la versión de omitir (V) - Esta marca está pensada para una versión preliminar o una imagen de firmware de depuración. Indica al componente que no debe rechazar el firmware en función de la versión del firmware. - Esta marca está pensada para la fase de desarrollo. Se puede usar para revertir intencionadamente a una versión de firmware anterior. - El firmware de producción debe omitir esta marca. |
| 16 | Id. de componente | 8 | Este byte se usa para escenarios de varios componentes. Este campo se puede usar para identificar el subcomponente para el que se pretende la oferta. Si no se usa, el valor debe ser 0. Los valores posibles de identificadores de componente son los siguientes: 1 - 0xDF: Válido 0xE0 - 0xFD: Reservado. No usar. 0xFF: la oferta es un paquete de información de oferta especial. Consulte la información sobre FIRMWARE_UPDATE_OFFER para más detalles. 0xFE: la oferta es un paquete de comandos de oferta especial. Consulte la sección extendida de FIRMWARE_UPDATE_OFFER para más detalles. |
| 24 | Token | 8 | El host inserta un token único en el paquete de oferta al componente. El componente debe devolver este token en la respuesta de la oferta. Esto resulta útil si es necesario que el componente distinga entre los distintos hosts o tipos de hosts. Los valores exactos que se van a usar son específicos de la implementación. Por ejemplo, se puede usar un valor para un controlador y otro para la aplicación. Esto permite que el firmware del dispositivo actual tenga en cuenta posibles varios remitentes de comandos CFU. Una posible implementación puede ser aceptar el primer comando de CFU y rechazar todos los demás comandos con tokens diferentes hasta que se completen las primeras transacciones de CFU. |
5.2.1.2 Versión de firmware
Estos cuatro bytes representan la versión de 32 bits del firmware. Esta especificación no exige el formato de la versión de firmware. Se recomienda lo siguiente.
Tabla 5.2-4 FIRMWARE_UPDATE_OFFER Comando: Diseño de versión de firmware
comando 
El formato de la versión de firmware no es obligatorio para esta especificación; sin embargo, se recomienda seguir una guía.
Tabla 5.2-5 Comando FIRMWARE_UPDATE_OFFER - Bits de versión de firmware
| Desplazamiento de bits | Campo | Tamaño | Descripción |
|---|---|---|---|
| 0 | Variante | 8 | Este campo se puede describir para distinguir entre un firmware de versión preliminar y un firmware de producción. Puede indicar el tipo de firma que se usa para firmar el firmware. |
| 8 | Versión menor | 16 | Este valor de campo debe actualizarse para cada compilación del firmware. Este valor de campo debe actualizarse para cada compilación del firmware. |
| 24 | Versión principal | 8 | Este campo es la versión principal de la imagen de firmware. Este campo debe actualizarse al enviar una nueva línea de producto, actualizaciones nuevas principales al firmware, etc. |
5.2.1.3 Específico del proveedor
Estos cuatro bytes se pueden usar para codificar cualquier información personalizada en la oferta que es específica para la implementación del proveedor.
5.2.1.4 Varios y versión del protocolo
Estos cuatro bytes se pueden usar para codificar cualquier información personalizada en la oferta que sea específica de la implementación del proveedor.
Tabla 5.2-6 FIRMWARE_UPDATE_OFFER Comando: Diseño específico del proveedor
comando 
Los bits del byte específico del proveedor se describen en esta tabla.
Tabla 5.2-7 Comando FIRMWARE_UPDATE_OFFER - Varios y versión del protocolo
| Desplazamiento de bits | Campo | Tamaño | Descripción |
|---|---|---|---|
| 0 | Versión del protocolo | 4 | Este campo debe establecerse en 0010b que indique que el host o oferta corresponde a la versión 2 del protocolo CFU. |
| 4 | Reservado | 4 | Reservado. No usar. |
| 8 | Reservado | 8 | Reservado. No usar. |
| 16 | Específico del proveedor | 16 | Este campo se puede usar para codificar cualquier información personalizada de la oferta que sea específica de la implementación por parte del proveedor. |
5.2.2 Respuesta
El paquete de respuesta de FIRMWARE_UPDATE_OFFER se define de la siguiente manera.
Tabla 5.2-8 Diseño del token de respuesta de FIRMWARE_UPDATE_OFFER
5.2.2.1 Token
Tabla 5.2-9 Respuesta de FIRMWARE_UPDATE_OFFER - Diseño del token
Los bits del byte token se describen en esta tabla.
Tabla 5.2-10 Respuesta de FIRMWARE_UPDATE_OFFER - Bits de token
| Desplazamiento de bits | Campo | Tamaño | Descripción |
|---|---|---|---|
| 0 | Reservado | 8 | Reservado. No usar. |
| 8 | Reservado | 8 | Reservado. No usar. |
| 16 | Reservado | 8 | Reservado. No usar. |
| 24 | Token | 8 | Token para identificar el host. |
5.2.2.2 Reservado (B7 - B4)
Reservado. No usar.
5.2.2.3 Motivo de rechazo (RR)
Tabla 5.2-11 Respuesta de FIRMWARE_UPDATE_OFFER - Diseño de motivo de rechazo
Tabla 5.2-12 Respuesta de FIRMWARE_UPDATE_OFFER - Bits de motivo de rechazo
Los bits del byte Reject Reason se describen en esta tabla.
| Desplazamiento de bits | Campo | Tamaño | Descripción |
|---|---|---|---|
| 0 | Código RR | 8 | Código de motivo de rechazo que indica el motivo proporcionado por el componente para rechazar la oferta. Este valor depende del campo Estado. Para consultar una asignación de estado a código RR, consulte la tabla 5.2-13. |
| 8 | Reservado | 24 | Reservado. No usar. |
Tabla 5.2-13 Valores de código de RR de respuesta de FIRMWARE_UPDATE_OFFER
Los valores posibles para el byte de CÓDIGO RR se describen en esta tabla.
| Código RR | Nombre | Descripción |
|---|---|---|
| 0x00 | FIRMWARE_OFFER_REJECT_OLD_FW | La oferta se rechazó porque la versión del firmware ofrecido es anterior o igual que el firmware actual. |
| 0x01 | FIRMWARE_OFFER_REJECT_INV_COMPONENT | La oferta se rechazó porque el firmware ofrecido no es aplicable a la plataforma del producto. Esto puede deberse a un identificador de componente no compatible o a una imagen ofrecida no es compatible con el hardware del sistema. |
| 0x02 | FIRMWARE_UPDATE_OFFER SWAP_PENDING | El firmware del componente se ha actualizado, sin embargo, un intercambio al nuevo firmware está pendiente. No se puede realizar ningún procesamiento adicional de actualización de firmware hasta que se haya completado el intercambio, normalmente a través de un restablecimiento. |
| 0x03 - 0x08 | (Reservado) | Reservado. No usar. |
| 0x09 - 0xDF | (Reservado) | Reservado. No utilizar. |
| 0xE0 - 0xFF | (Específico del proveedor) | Estos valores los usan los diseñadores del protocolo y el significado es específico del proveedor. |
5.2.2.4 Estado
Tabla 5.2-14 Diseño de estado de respuesta de FIRMWARE_UPDATE_OFFER
Los bits del byte Status se describen en esta tabla.
Tabla 5.2-15 Respuesta de FIRMWARE_UPDATE_OFFER - Bits de estado
| Desplazamiento de bits | Campo | Tamaño | Descripción |
|---|---|---|---|
| 0 | Estado | 8 | Este valor indica la decisión del componente de aceptar, esperar, omitir o rechazar la oferta. El componente proporciona el motivo en el valor del campo Código RR. Para consultar una asignación de estado a código RR, consulte la tabla 5.2-16. |
| 8 | Reservado | 24 | Reservado. No usar. |
Los valores posibles para el byte Status se describen en esta tabla.
Tabla 5.2-16 Valores de estado de respuesta de FIRMWARE_UPDATE_OFFER
| Estado | Nombre | Descripción |
|---|---|---|
| 0x00 | FIRMWARE_UPDATE_OFFER_SKIP | El componente ha decidido pasar por alto la oferta. El anfitrión debe volver a ofrecerlo más tarde. |
| 0x01 | ACEPTAR_OFERTA_DE_ACTUALIZACIÓN_DE_FIRMWARE | El componente ha decidido aceptar la oferta. |
| 0x02 | OFERTA_DE_ACTUALIZACIÓN_DE_FIRMWARE_RECHAZADA | El componente ha decidido rechazar la oferta. |
| 0x03 | Oferta de actualización de firmware ocupada | El dispositivo está ocupado y el host debe esperar hasta que el dispositivo esté listo. |
| 0x04 | FIRMWARE_UPDATE_OFFER_COMMAND | Se usa cuando el ID de Componente en los bytes de información del componente (vea 5.1.2.1.1 Información del componente) se configura en 0xFE. Para el código de comando configurado en la solicitud OFFER_NOTIFY_ON_READY, indica que el accesorio está listo para aceptar ofertas adicionales. |
| 0xFF | FIRMWARE_UPDATE_CMD_NOT_SUPPORTED | No se reconoce la solicitud de oferta. |
5.2.3 Protocolo de asignación a HID
El mensaje se emite al componente mediante el mecanismo de informe de salida HID, utilizando el ID de informe de utilidad HID dedicado para la actualización del firmware. El TLC de la utilidad HID que se usará se describe en el Apéndice.
5.3 FIRMWARE_UPDATE_OFFER - Información
Si el ID del componente en los bytes de información del componente (vea Información del componente) está establecido en 0xFF, los bits dentro de los 15 bytes se redefinen para indicar únicamente información de oferta, desde el host al componente. Este mecanismo permite la extensibilidad y una manera de que el host proporcione información específica al dispositivo, como Iniciar lista de ofertas, finalizar lista de ofertas, iniciar transacción completa. Los paquetes de información de la oferta siempre son aceptados inmediatamente por el componente.
5.3.1 Comando
El paquete FIRMWARE_UPDATE_OFFER -Information Comando se define de la siguiente manera:
Tabla 5.3-1 FIRMWARE_UPDATE_OFFER: Diseño del comando de información
Componente 5.3.1.1
Tabla 5.3-2 FIRMWARE_UPDATE_OFFER - Comando de información - Diseño de componentes
Los bits del byte Componente se describen en esta tabla.
Tabla 5.3-3 Comando FIRMWARE_UPDATE_OFFER - Comando de información - Bits de componentes
| Desplazamiento de bits | Campo | Tamaño | Descripción |
|---|---|---|---|
| 0 | Código de información | 8 | Este valor indica el tipo de información. Este valor no es una máscara de bits y solo puede ser uno de los valores posibles descritos en la tabla 5.3-4. |
| 8 | Reservado. | 8 | Reservado. No usar. |
| 16 | Id. de componente | 8 | Establézcalo en 0xFF. |
| 24 | Token | El host inserta un token único en el paquete de oferta al componente. El componente debe devolver este token en la respuesta de la oferta. |
Tabla 5.3-4 FIRMWARE_UPDATE_OFFER: Comando de información: valores de código de información
| Estado | Nombre | Descripción |
|---|---|---|
| 0x00 | OFFER_INFO_START_ENTIRE_TRANSACTION | Indica que el host es nuevo o se ha recargado y que todo el procesamiento de la oferta se está (re)iniciando. |
| 0x01 | OFFER_INFO_START_OFFER_LIST | Indica el principio de la lista de ofertas del host en caso de que el accesorio tenga reglas de descarga asociadas a garantizar que se actualice un subcomponente antes de otro subcomponente en el sistema. |
| 0x02 | OFFER_INFO_END_OFFER_LIST | Indica el final de la lista de ofertas del host. |
5.3.1.2 Reservado B7 - B4
Reservado. No lo utilices.
5.3.1.3 Reservado B11 - B8
Reservado. No usar.
5.3.1.4 Reservado B15 - B12
Reservado. No usar.
5.3.2 Respuesta
La respuesta del paquete de respuesta de FIRMWARE_UPDATE_OFFER - Información de oferta se define de la manera siguiente.
Tabla 5.3-5 FIRMWARE_UPDATE_OFFER - Diseño de respuesta de información
5.3.2.1 Token
Tabla 5.3-6 FIRMWARE_UPDATE_OFFER: Diseño del token de respuesta de paquetes de información
Los bits del byte token se describen en esta tabla.
Tabla 5.3-7 FIRMWARE_UPDATE_OFFER - Respuesta de información - Bits de token
| Desplazamiento de bits | Campo | Tamaño | Descripción |
|---|---|---|---|
| 0 | Reservado | 8 | Reservado. No usar. |
| 8 | Reservado | 8 | Reservado. No usar. |
| 16 | Reservado | 8 | Reservado. No utilizar. |
| 24 | Token | 8 | Token para identificar el host |
5.3.2.2 Reservado B7 - B4
Reservado. No usar.
5.3.2.3 Motivo de rechazo (RR)
Tabla 5.3-8 FIRMWARE_UPDATE_OFFER - Diseño de respuesta - Diseño de código de RR
Los bits del byte Reject Reason se describen en esta tabla.
Tabla 5.3-9 FIRMWARE_UPDATE_OFFER - Respuesta de información de oferta - Bits de código de RR
| Desplazamiento de bits | Campo | Tamaño | Descripción |
|---|---|---|---|
| 0 | Código RR | 8 | Código de motivo de rechazo que indica el motivo proporcionado por el componente para rechazar la oferta. Los valores posibles se describen en la tabla 5.3-10. Este valor depende del campo Estado. |
| 8 | Reservado | 24 | Reservado. No usar. |
Los valores posibles para el byte de CÓDIGO RR se describen en esta tabla.
Tabla 5.3-10 FIRMWARE_UPDATE_OFFER - Respuesta de información - Valores de código de RR
| Código RR | Nombre | Descripción |
|---|---|---|
| 0x00 | FIRMWARE_OFFER_REJECT_OLD_FW | La oferta se rechazó porque la versión del firmware ofrecido es anterior o igual que el firmware actual. |
| 0x01 | FIRMWARE_OFFER_REJECT_INV_COMPONENT | La oferta se rechazó porque el firmware ofrecido no es aplicable a la plataforma del producto. Esto puede deberse a un identificador de componente no compatible o a una imagen ofrecida no es compatible con el hardware del sistema. |
| 0x02 | FIRMWARE_UPDATE_OFFER SWAP_PENDING | El firmware del componente se ha actualizado, sin embargo, un cambio al nuevo firmware está pendiente. No se puede realizar ningún procesamiento adicional de actualización de firmware hasta que se haya completado el intercambio, normalmente a través de un restablecimiento. |
| 0x03 - 0x08 | (Reservado) | Reservado. No usar. |
| 0x09 - 0xDF | (Reservado) | Reservado. No usar. |
| 0xE0 — 0xFF | (Específico del proveedor) | Estos valores los usan los diseñadores del protocolo y el significado es específico del proveedor. |
5.3.2.4 Estado
Tabla 5.3-11 FIRMWARE_UPDATE_OFFER - Diseño de estado de respuesta de información de oferta
Los bits del byte Status se describen en esta tabla.
Tabla 5.3-12 FIRMWARE_UPDATE_OFFER - Información de oferta - Bits de estado de respuesta
| Desplazamiento de bits | Campo | Tamaño | Descripción |
|---|---|---|---|
| 0 | Estado | 8 | Este campo debe establecerse en FIRMWARE_UPDATE_OFFER_ACCEPT. Esto indica que el componente ha decidido aceptar la oferta. |
| 8 | Reservado. | 24 | Reservado. No usar. |
5.4 FIRMWARE_UPDATE_OFFER - Extendido
Si el identificador de componente de los bytes de información del componente se establece en 0xFE, los bits (15 bytes) se vuelven a definir para indicar el comando de oferta desde el host al firmware del dispositivo. Este mecanismo permite la extensibilidad y una manera de que el host proporcione información específica al dispositivo. Los paquetes de comando de oferta se devuelven cuando el componente está listo para responder "Aceptado."
5.4.1 Comando
Si el identificador de componente de los bytes de información del componente se establece en 0xFE, los cuatro DWORD se vuelven a definir de la siguiente manera:
Tabla 5.4-1 FIRMWARE_UPDATE_OFFER- Diseño de comando extendido
Componente 5.4.1.1
Tabla 5.4-2 FIRMWARE_UPDATE_OFFER - Paquete de comandos extendidos - Comando - Diseño de componentes
Los bits del byte Componente se describen en esta tabla.
Tabla 5.4-3 FIRMWARE_UPDATE_OFFER - Comando extendido - Bits de componente
| Desplazamiento de bits | Campo | Tamaño | Descripción |
|---|---|---|---|
| 0 | Código de comando | 8 | Este valor indica el tipo de comando. Este valor no es una máscara de bits y solo puede ser uno de los valores posibles descritos en la tabla 5.4-4. |
| 8 | Reservado. | 8 | Reservado. No usar. |
| 16 | Id. de componente | 8 | Establecer en 0xFE. |
| 24 | Token | El host inserta un token único en el paquete de oferta al componente. El componente debe devolver este token en la respuesta de la oferta. |
Tabla 5.4-4 FIRMWARE_UPDATE_OFFER: comando extendido: valores de código de comando
| Estado | Nombre | Descripción |
|---|---|---|
| 0x01 | OFFER_NOTIFY_ON_READY | Enviado por el host si el componente rechazó previamente la oferta. |
| 0x02 - 0xFF | Reservado | Reservado |
5.4.1.2 Reservado B7 - B4
Reservado. No usar.
5.4.1.3 Reservado B11 - B8
Reservado. No usar.
5.4.1.4 Reservado B15 - B12
Reservado. No usar.
Respuesta 5.4.2
Es posible que la respuesta FIRMWARE_UPDATE_OFFER - Comando de oferta del dispositivo no se reciba de inmediato. La respuesta se define de la manera siguiente.
Tabla 5.4-5 FIRMWARE_UPDATE_OFFER: Diseño de respuesta de paquetes de comandos extendidos
5.4.2.1 Token
Tabla 5.4-6 FIRMWARE_UPDATE_OFFER - Respuesta de paquetes de comandos de oferta - Diseño de token
Los bits del byte token se describen en esta tabla.
Tabla 5.4-7 FIRMWARE_UPDATE_OFFER - Respuesta del comando de oferta - Bits de token
| Desplazamiento de bits | Campo | Tamaño | Descripción |
|---|---|---|---|
| 0 | Reservado | 8 | Reservado. No utilizar. |
| 8 | Reservado | 8 | Reservado. No usar. |
| 16 | Reservado | 8 | Reservado. No usar. |
| 24 | Token | 8 | Token para identificar el host. |
5.4.2.2 Reservado B7 - B4
Reservado. No utilizar.
5.4.2.3 Motivo de rechazo
Tabla 5.4-8 FIRMWARE_UPDATE_OFFER - Diseño de RR de respuesta de paquetes de información de oferta
Los bits del byte Reject Reason se describen en esta tabla.
Tabla 5.4-9 FIRMWARE_UPDATE_OFFER - Respuesta del comando de oferta - Código RR
| Desplazamiento de bits | Campo | Tamaño | Descripción |
|---|---|---|---|
| 0 | Código RR | 8 | Este valor depende del campo Estado. Para conocer los posibles valores de RR Code, consulte la tabla 5.4-10. |
| 8 | Reservado | 24 | Reservado. No usar. |
Los valores posibles para el byte de CÓDIGO RR se describen en esta tabla.
Tabla 5.4-10 FIRMWARE_UPDATE_OFFER - Paquete de comandos de oferta - Valores de código RR
| Código RR | Nombre | Descripción |
|---|---|---|
| 0x00 | FIRMWARE_OFFER_REJECT_OLD_FW | La oferta se rechazó porque la versión del firmware ofrecido es anterior o igual que el firmware actual. |
| 0x01 | FIRMWARE_OFFER_REJECT_INV_COMPONENT | La oferta se rechazó porque el firmware ofrecido no es aplicable a la plataforma del producto. Esto puede deberse a un identificador de componente no compatible o a una imagen ofrecida no es compatible con el hardware del sistema. |
| 0x02 | FIRMWARE_UPDATE_OFFER SWAP_PENDING | El firmware del componente se ha actualizado, sin embargo, un cambio al nuevo firmware está pendiente. No se puede realizar ningún procesamiento adicional de actualización de firmware hasta que se haya completado el intercambio, normalmente a través de un restablecimiento. |
| 0x03 - 0x08 | (Reservado) | Reservado. No usar. |
| 0x09 - 0xDF | (Reservado) | Reservado. No usar. |
| 0xE0 — 0xFF | (Específico del proveedor) | Estos valores los usan los diseñadores del protocolo y el significado es específico del proveedor. |
5.4.2.4 Estado
Tabla 5.4-11 FIRMWARE_UPDATE_OFFER - Diseño de estado de respuesta de paquetes de comandos de oferta
Los bits del byte Status se describen en esta tabla.
Tabla 5.4-12 FIRMWARE_UPDATE_OFFER - Código RR de respuesta de paquete de comandos de oferta
| Desplazamiento de bits | Campo | Tamaño | Descripción |
|---|---|---|---|
| 0 | Estado | 8 | Este campo debe establecerse en FIRMWARE_UPDATE_OFFER_ACCEPT. Esto indica que el componente ha decidido aceptar la oferta. |
| 8 | Reservado. | 24 | Reservado. No usar. |
5.5 FIRMWARE_UPDATE_CONTENT
El host envía este comando al firmware del dispositivo para proporcionar el contenido del firmware (es decir, la imagen de firmware). No se espera que el archivo de imagen completo quepa en un solo comando. El host debe dividir la imagen en bloques más pequeños y cada comando envía un bloque de la imagen a la vez.
Con cada comando, el host indica información adicional, ya sea el primer bloque, el último bloque, etc., del firmware. El componente principal del firmware del dispositivo acepta cada bloque de la imagen de firmware entrante, lo almacena en su memoria y debe responder a cada comando individualmente.
Cuando el componente principal recibe el último bloque, el componente valida toda la imagen de firmware (comprobación de CRC, validación de firma). En función de los resultados de esas comprobaciones, se devuelve una respuesta adecuada (error o éxito) para el último bloque.
5.5.1 Comando
Tabla 5.5-1 FIRMWARE_UPDATE_CONTENT Diseño de comandos
5.5.1.1 Encabezado (B7 - B0)
Tabla 5.5-2 FIRMWARE_UPDATE_CONTENT Diseño del encabezado de comando
Los bits del encabezado de FIRMWARE_UPDATE_CONTENT se describen en esta tabla.
Tabla 5.5-3 Bits de encabezado de FIRMWARE_UPDATE_CONTENT
| Desplazamiento de bits | Campo | Tamaño | Descripción |
|---|---|---|---|
| 0 | Banderas | 8 | Este campo proporciona información adicional sobre el comando. Este valor es una máscara de marcas que se van a usar para las transferencias de datos. Los valores posibles se describen en la tabla 5.5-4. |
| 8 | Longitud de datos | 8 | Longitud del campo Datos aplicable que indica el número de bytes que se van a escribir. Dado el tamaño de este comando, el valor máximo permitido para la longitud es de 52 bytes. |
| 16 | Número de secuencia | 16 | El host crea este valor y es único para cada paquete de contenido emitido. El componente debe devolver el número de secuencia en su respuesta a esta solicitud. |
| 32 | Dirección del firmware | 32 | Dirección Little Endian (LSB First) para escribir los datos. La dirección está basada en 0. El firmware lo utiliza como desplazamiento para determinar la dirección cuando sea necesario al colocar la imagen en la memoria. |
Los valores posibles para el byte Flags se describen en esta tabla.
Tabla 5.5-4 FIRMWARE_UPDATE_OFFER - Paquete de comandos de oferta - Valores de indicador
| Bandera | Nombre | Descripción |
|---|---|---|
| 0x80 | FIRMWARE_UPDATE_FLAG_FIRST_BLOCK | Esta marca indica que este es el primer bloque de la imagen de firmware. |
| 0x40 | FIRMWARE_UPDATE_FLAG_LAST_BLOCK | Esta marca indica que este es el último bloque de la imagen de firmware y que la imagen está lista para validarse. Es importante que el firmware actual del componente realice la validación en toda la imagen de firmware descargada después de escribir este bloque en memoria no volátil. |
5.5.1.2 Datos
Tabla 5.5-5 FIRMWARE_UPDATE_CONTENT Disposición de datos del comando
Los bits de los datos de FIRMWARE_UPDATE_CONTENT se describen en esta tabla.
Tabla 5.5-6 Bits de datos de comando FIRMWARE_UPDATE_CONTENT
| Desplazamiento de bits | Campo | Tamaño | Descripción |
|---|---|---|---|
| 64 | Datos | Máx 52. | Matriz de bytes que se va a escribir. El host normalmente envía bloques de 4 bytes en función de la arquitectura del producto. Todos los bytes sin usar al final deben rellenarse con ceros. |
5.5.2 Respuesta
Tabla 5.5-7 Diseño de respuesta del comando FIRMWARE_UPDATE_CONTENT
5.5.2.1 Número de secuencia
Tabla 5.5-8 Respuesta de FIRMWARE_UPDATE_CONTENT - Número de secuencia
Los bits de la respuesta FIRMWARE_UPDATE_CONTENT (3-0) se describen en esta tabla.
Tabla 5.5-9 FIRMWARE_UPDATE_CONTENT - Comando - Bits de respuesta
| Desplazamiento de bits | Campo | Tamaño | Descripción |
|---|---|---|---|
| 0 | Número de secuencia | 16 | Este campo es el número de secuencia enviado por el host en la solicitud. |
| 16 | Reservado | 16 | Reservado. No usar. |
5.5.2.2 Estado
Tabla 5.5-10 Diseño de estado de respuesta de FIRMWARE_UPDATE_CONTENT
Los bits de la respuesta FIRMWARE_UPDATE_CONTENT (7-4) se describen en esta tabla.
Tabla 5.5-11 FIRMWARE_UPDATE_OFFER - Respuesta - Bits de estado
| Desplazamiento de bits | Campo | Tamaño | Descripción |
|---|---|---|---|
| 0 | Estado | 8 | Este valor indica el código de estado devuelto por el componente del dispositivo. Esto no es una operación a nivel de bits y puede ser uno de los valores descritos en la Tabla 5.5-12. |
| 8 | Reservado | 24 | Reservado. No usar. |
Los valores posibles para el byte Status se describen en esta tabla.
Tabla 5.5-12 FIRMWARE_UPDATE_OFFER - Respuesta - Valores de código de estado
| Bandera | Nombre | Descripción |
|---|---|---|
| 0x00 | FIRMWARE_UPDATE_SUCCESS | La solicitud se completó correctamente. |
| 0x01 | FIRMWARE_UPDATE_ERROR_PREPARE | El componente no estaba preparado para recibir el contenido del firmware. Si se usa, este código se usa normalmente en una respuesta al primer bloque. Por ejemplo, borre el error en la memoria flash. |
| 0x02 | FIRMWARE_UPDATE_ERROR_WRITE | La solicitud no pudo escribir los bytes. |
| 0x03 | FIRMWARE_UPDATE_ERROR_COMPLETE | La solicitud no pudo configurar el intercambio en respuesta a FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
| 0x04 | FIRMWARE_UPDATE_ERROR_VERIFY | Error en la comprobación del DWORD, en respuesta a FIRMWARE_UPDATE_FLAG_VERIFY. |
| 0x05 | Error de actualización de firmware CRC | Se produjo un error en el CRC de la imagen de firmware en respuesta a FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
| 0x06 | FIRMWARE_UPDATE_ERROR_SIGNATURE | Error en la verificación de la firma del firmware en respuesta a FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
| 0x07 | FIRMWARE_UPDATE_ERROR_VERSION | Error en la verificación de la versión del firmware en respuesta a FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
| 0x08 | FIRMWARE_UPDATE_SWAP_PENDING | El firmware ya se ha actualizado y hay un intercambio pendiente. No se pueden aceptar más comandos de actualización de firmware hasta que se haya restablecido el accesorio. |
| 0x09 | FIRMWARE_UPDATE_ERROR_INVALID_ADDR | El firmware ha detectado una dirección de destino no válida dentro del contenido de datos del mensaje. |
| 0x0A | FIRMWARE_UPDATE_ERROR_NO_OFFER | El comando FIRMWARE_UPDATE_OFFER se recibió sin recibir primero una oferta de actualización de firmware válida y aceptada. |
| 0x0B | FIRMWARE_UPDATE_ERROR_INVALID (Error de actualización de firmware no válido) | Error general del comando FIRMWARE_UPDATE_OFFER, como una longitud de datos aplicable no válida. |
5.5.2.3 Reservado B8 - B11
Reservado. No usar.
5.5.2.4 Reservado B12 - B15
Reservado. No usar.
6 Apéndice 1: Secuencia de comandos de programación de actualización de firmware de ejemplo
6.1 Ejemplo 1
Tenga en cuenta el siguiente firmware del dispositivo:
Componente principal: id. de componente 1: versión de firmware actual 7.0.1
Subcomponente - ID de componente 2 - Versión de firmware actual 12.4.54
Subcomponente - ID de Componente 3 - Versión de Firmware Actual 4.4.2
Subcomponente - ID de componente 4 - Versión de firmware actual 23.32.9
El host tiene estas tres imágenes de firmware:
Id. de componente 1: versión de firmware 7.1.3
ID de componente 2: versión de firmware 12.4.54
ID de componente 3 - Versión de firmware 4.5.0
La secuencia será:
Ofrecimientos del host: ID del componente 1 - Versión del firmware 7.1.3
El componente principal acepta la oferta.
El host envía la imagen de firmware
El componente principal acepta firmware, lo valida.
Ofertas de host: ID de componente 2 - Versión de firmware 12.4.54
El componente principal rechaza la oferta.
Ofertas de host: ID de componente 3 - Versión de firmware 4.5.0
El componente principal acepta la oferta.
El host envía la imagen de firmware
El componente principal acepta firmware, lo valida.
Dado que no se rechazaron todas las ofertas, el anfitrión muestra todas las ofertas.
Ofertas de host: ID de componente 1 - Versión de firmware 7.1.3
Rechazos de componentes
Ofertas de host: ID de componente 2 - Versión de firmware 12.4.54
Rechazos de componentes
Ofertas de host: ID de componente 3 - Versión de firmware 4.5.0
Rechazos de componentes
6.2 Ejemplo 2
Tenga en cuenta el siguiente firmware del dispositivo:
Componente principal: id. de componente 1: versión de firmware actual 7.0.1
Subcomponente: ID de componente 2 - Versión de firmware actual 12.4.54
Subcomponente - ID de componente 3 - Versión de firmware actual 7.4.2
Subcomponente - ID de componente 4 - Versión de firmware actual 23.32.9
El host tiene estas tres imágenes de firmware:
Id. de componente 1: versión de firmware 8.0.0
Id. de componente 2 - Versión de firmware 12.4.54
ID de componente 3: versión de firmware 9.0.0
Además, la implementación requiere que la versión de firmware de los subcomponentes no sea menor que la versión de firmware que se ejecuta en el componente principal. El host no es consciente de ese requisito y depende del componente primario garantizar esta regla.
La secuencia será:
Ofertas de host: ID de componente 1 - Versión de firmware 8.0.0
El componente principal rechaza (porque el identificador de componente 3 aún no se ha actualizado)
Ofertas de host: ID de componente 2 - Versión de firmware 12.4.54
Rechazos del componente principal
Ofertas de host: ID de componente 3 - Versión de firmware 9.0.0
El componente principal acepta la oferta
El host envía la imagen de firmware
El componente principal acepta firmware, lo valida.
Dado que no se rechazaron todas las ofertas, el anfitrión reproduce las ofertas.
Ofertas de host: ID de componente 1 - Versión de firmware 8.0.0
El componente principal acepta la oferta
El host envía la imagen de firmware
El componente principal acepta firmware, lo valida.
Ofertas de host: ID de componente 2 - Versión de firmware 12.4.54
Rechazos del componente principal
Ofertas de host: ID de componente 3 - Versión de firmware 9.0.0
Rechazos del componente principal