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 podría tener subcomponentes, que requieren imágenes de firmware independientes. La especificación permite que el componente esté a cargo para decidir si 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 lista para aceptarla.
Nota
CFU está disponible en Windows 10, versión 2004 (Windows 10 actualización de mayo de 2020) y versiones posteriores.
Contenido
- 1 Introducción
- 2 Arquitectura de hardware compatible
- 3 Requisitos previos del protocolo
- 4 Introducción al protocolo CFU
- Secuencia de comandos de programación de actualización de firmware 4.1
- 4.1.1 Estado: notificación inicializada del host
- 4.1.2 Estado: notificación de OFFER_INFO_START_OFFER_LIST
- 4.1.3 Estado: Enviar comando FIRMWARE_UPDATE_OFFER
- Estado 4.1.4: Enviar 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: Lista de ofertas de reproducción
- 4.1.8 Estado: el dispositivo está ocupado
- Secuencia de comandos de programación de actualización de firmware 4.1
- 5 Formato de paquete de protocolo CFU
- 6 Apéndice 1: Secuencia de comandos de programación de actualización de firmware de ejemplo
Tablas
Tabla 5.1-1 GET_FIRMWARE_VERSION diseño de respuesta
Tabla 5.1-2 GET_FIRMWARE_VERSION respuesta: diseño de encabezado
Tabla 5.1-3 GET_FIRMWARE_VERSION respuesta: bits de encabezado
Tabla 5.1-4 GET_FIRMWARE_VERSION respuesta: diseño de las propiedades y la versión del componente
Tabla 5.1-5 GET_FIRMWARE_VERSION respuesta: versiones de componente y bits de propiedades
Tabla 5.2-1 FIRMWARE_UPDATE_OFFER diseño del comando
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 de FIRMWARE_UPDATE_OFFER: bits de versión de firmware
Tabla 5.2-6 comando de FIRMWARE_UPDATE_OFFER: diseño específico del proveedor
Tabla 5.2-7 FIRMWARE_UPDATE_OFFER Comando: Misc. y Versión del protocolo
Tabla 5.2-8 diseño de token de respuesta FIRMWARE_UPDATE_OFFER
Tabla 5.2-9 FIRMWARE_UPDATE_OFFER respuesta: diseño de token
Tabla 5.2-10 FIRMWARE_UPDATE_OFFER respuesta: bits de token
Tabla 5.2-11 FIRMWARE_UPDATE_OFFER respuesta: Rechazar diseño de motivo
Tabla 5.2-12 FIRMWARE_UPDATE_OFFER respuesta: rechazar bits de motivo
Tabla 5.2-13 FIRMWARE_UPDATE_OFFER valores de código RR de respuesta
Tabla 5.2-14 FIRMWARE_UPDATE_OFFER diseño de estado de respuesta
Tabla 5.2-15 FIRMWARE_UPDATE_OFFER Respuesta: Bits de estado
Tabla 5.2-16 FIRMWARE_UPDATE_OFFER valores de estado de respuesta
Tabla 5.3-1 FIRMWARE_UPDATE_OFFER: Diseño del comando de información
Tabla 5.3-2 FIRMWARE_UPDATE_OFFER- Comando de información- Diseño de componente
Tabla 5.3-3 FIRMWARE_UPDATE_OFFER - Comando de información - Bits de componente
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 - Respuesta de información - Diseño de código RR
Tabla 5.3-9 FIRMWARE_UPDATE_OFFER- Respuesta de información de la oferta- Bits de código RR
Tabla 5.3-10 FIRMWARE_UPDATE_OFFER- Respuesta de información- Valores de código RR
Tabla 5.3-11 FIRMWARE_UPDATE_OFFER: Diseño de estado de respuesta de la información de la oferta
Tabla 5.3-12 FIRMWARE_UPDATE_OFFER- Información de la oferta- Bits de estado de respuesta
Tabla 5.4-1 FIRMWARE_UPDATE_OFFER: diseño de comandos extendidos
Tabla 5.4-2 FIRMWARE_UPDATE_OFFER - Paquete de comando extendido - 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 paquete de comando 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 rr de respuesta de paquetes de información
Tabla 5.4-9 FIRMWARE_UPDATE_OFFER- Respuesta del comando de oferta- Código RR
Tabla 5.4-10 FIRMWARE_UPDATE_OFFER- Paquete de comando de oferta: valores de código RR
Tabla 5.4-11 FIRMWARE_UPDATE_OFFER: Diseño de estado de respuesta del paquete de la oferta
Tabla 5.4-12 FIRMWARE_UPDATE_OFFER: Código RR de respuesta de paquetes de comandos de oferta
Tabla 5.5-1 FIRMWARE_UPDATE_CONTENT Diseño de comandos
Tabla 5.5-2 FIRMWARE_UPDATE_CONTENT Diseño del encabezado de comando
Tabla 5.5-3 FIRMWARE_UPDATE_CONTENT bits de encabezado
Tabla 5.5-4 FIRMWARE_UPDATE_OFFER- Paquete de comandos de oferta: valores de marca
Tabla 5.5-5 FIRMWARE_UPDATE_CONTENT Diseño de datos de comandos
Tabla 5.5-6 FIRMWARE_UPDATE_CONTENT Bits de datos de comandos
Tabla 5.5-7 FIRMWARE_UPDATE_CONTENT Diseño de respuesta de comandos
Tabla 5.5-8 FIRMWARE_UPDATE_CONTENT respuesta: número de secuencia
Tabla 5.5-9 FIRMWARE_UPDATE_CONTENT - Comando - Bits de respuesta
Tabla 5.5-10 FIRMWARE_UPDATE_CONTENT diseño de estado de respuesta
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 bien 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, omnipresente y tiene compatibilidad integrada de Windows en 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 podría tener subcomponentes, que requieren imágenes de firmware independientes.
Nota
El proceso de entrega de un componente sobre el firmware 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 aceptar 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 mecanismo de optimización porque la imagen de firmware se envía al componente solo si puede /listo para aceptarla.
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 que se usa para generar una síntesis 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 la confianza de 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 suele ser 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 que se escribe 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. |
| Hardware | Una pieza física de silicio en el equipo. |
| 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. |
| Segment | 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 recomendadas y más allá del ámbito 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 de bajada de un componente visible para el sistema. Estos componentes se conocen como subcomponentes en esta especificación. |
| TLC | Colección de nivel superior 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 se ha iniciado otra. |
1.2 Ámbito
1.2.1 Goals
Se requiere una solución independiente de bus para evitar un nuevo protocolo para cada tipo de bus. HID es ubicua 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 subcomponentes para reenviar a los subcomponentes. Los subcomponentes también pueden realizar comprobaciones de validez en su firmware y devolver 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 a través de herramientas autorizadas y actualizar dispositivos en el mercado a través de Windows Update.
Flexibilidad para admitir el firmware en el desarrollo o el firmware en el mercado.
La capacidad de segmentar una imagen de firmware grande en segmentos más pequeños para facilitar que el componente acepte la imagen de firmware.
1.2.2 No Goals
Defina 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 esperado que se ejecute 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 subcomponente.
2 Arquitectura de hardware compatible
Para admitir un diseño de hardware flexible, el protocolo admite un dispositivo de varios componentes 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 de varios componentes 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 allí). 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 perquisites y los procedimientos recomendados que se deben implementar para aprovechar este protocolo:
Uso de imágenes atómicas
No se usa una imagen de firmware para un componente 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 el segmento final se reciba del remitente. Las comprobaciones de integridad se deben realizar 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 los 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 y no se realiza correctamente, el dispositivo no debe invocar el nuevo firmware y 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á cifrada.
Protección de reversión
Las directivas de reversión se aplican mediante el componente principal y son específicas de la implementación. El firmware actual del componente valida las imágenes de firmware entrantes en directivas internas, como el número de versión, debe ser más reciente, o el tipo de versión no se puede cambiar de versión a depuración, etc. El protocolo permite que la mensajería indique que se acepta una actualización incluso si infringe las directivas de reversión.
4 Introducción al protocolo CFU
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 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 reenviar todas las ofertas de firmware al dispositivo hasta que se resuelvan todas las dependencias.
Secuencia de comandos de programación de actualización de firmware 4.1
Esta es la secuencia de comandos de CFU para actualizar la imagen de firmware.
4.1.1 Estado: notificación inicializada del host
Una vez que el host se inicializa y ha identificado un conjunto de ofertas que debe enviar al dispositivo, el host emite un comando de 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 de OFFER_INFO_START_OFFER_LIST
En este estado, el 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 sobre la imagen de firmware, de modo que el firmware actual del componente pueda decidir si aceptar, escribir, 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 preparar 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, consulte 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 en la imagen real recibida. El componente debe comprobar cada propiedad de imagen de 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, se FIRMWARE_UPDATE_OFFER_ACCEPT estado aceptando la oferta.
Si el firmware del dispositivo está ocupado y el componente principal no puede aceptar esta o la siguiente oferta actualmente, envía una respuesta ocupada con FIRMWARE_UPDATE_OFFER_BUSY estado.
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 Estado: OFFER_INFO_START_OFFER_LIST Notificación).
Estado 4.1.4: 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 FIRMWARE_UPDATE CONTENT independiente. El componente principal debe generar un paquete de respuesta para cada comando.
Cada FIRMWARE_UPDATE comando CONTENT describe una dirección de desplazamiento que incluye una carga de firmware parcial. 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, lo que indica al dispositivo que este 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, 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 comprobación CRC para comprobar la integridad de toda la imagen de firmware.
Si la comprobación crc se realiza correctamente, la comprobació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 es 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 para 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 restablecimiento e informa de que el host se ha realizado correctamente. Normalmente, el componente no inicia un autoservicio de restablecimiento. 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: Lista de ofertas de reproducción
El host determina si necesita volver a enviar todas las ofertas. Ese caso puede producirse si anteriormente el componente principal había omitido algunas ofertas y aceptó algunas ofertas. 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 ocupada a una oferta.
El host envía un comando OFFER_NOTIFY_ON_READY, al que el dispositivo no responde con 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 siguiente comando, hasta que se recibe una respuesta válida para el comando anterior que envió.
En caso de que el componente no responda dentro de 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 reconocible para el 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 firmware 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 GET_FIRMWARE_VERSION Diseño de respuesta
Encabezado 5.1.2.1
Tabla 5.1-2 GET_FIRMWARE_VERSION respuesta: diseño de encabezado
El encabezado de la respuesta proporciona la siguiente información.
Tabla 5.1-3 GET_FIRMWARE_VERSION respuesta: bits de encabezado
| Desplazamiento de bits | Campo | Size | Descripción |
|---|---|---|---|
| 0 | Recuento de componentes | 8 | El 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 | Rsvd | 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 fw debe ser 0010b. |
| 28 | Rsvd | 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 Propiedades y versión del componente
Para cada componente, se usan dos DWORD para describir las propiedades del componente hasta 7 componentes. Si el número de componentes del encabezado es menor que 7, la DWORDS sin usar al final de la respuesta debe establecerse en 0.
Tabla 5.1-4 GET_FIRMWARE_VERSION Respuesta: Diseño de las propiedades y la versión del componente
Cada información específica del componente se describe en dos DWORD de la siguiente manera:
Tabla 5.1-5 GET_FIRMWARE_VERSION respuesta: versiones de componente y bits de propiedades
| Desplazamiento de bits | Campo | Size | 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. Dependiendo 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 Condicional obligatorio: 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 una manera específica de implementación. Un proveedor podría usar estos bits para codificar información como: - Tipo de firmware: pre-release/self-host/production; debug/retail - 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 de implementación. |
5.1.3 Asignación a HID
Esto se implementa como una solicitud de obtención de características HID con un tamaño de respuesta de 60 bytes, además del identificador de informe. La longitud del informe de características admite toda la respuesta GET_FIRMWARE_VERSION. No hay datos asociados a la solicitud Obtener característica 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 siguiente manera.
Tabla 5.2-1 FIRMWARE_UPDATE_OFFER diseño del comando
5.2.1.1 Información del componente
Tabla 5.2-2 comando FIRMWARE_UPDATE_OFFER: diseño de información de componentes
Los bits del byte información de componentes se describen en esta tabla.
Tabla 5.2-3 comando FIRMWARE_UPDATE_OFFER: bits de información de componentes
| Desplazamiento de bits | Campo | Size | 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 se puede usar para indicar que esta oferta es para el segmento i-ésima de la imagen completa. Se puede enviar una oferta independiente al componente principal que contiene el segmento i+1 de la imagen, etc. |
| 8 | Reservado | 6 | Campos reservados. El remitente debe establecerlos en 0. El receptor debe omitir este valor. |
| 14 | I | 1 | Forzar el restablecimiento inmediato (I) - Este valor de bit se usa para indicar al componente que se restablece inmediatamente después de que se complete la descarga del firmware y se compruebe para invocarlo inmediatamente. - Esta marca está pensada para la fase de desarrollo. |
| 15 | V | 1 | Forzar la versión de ignore (V) - Esta marca está pensada para la imagen de firmware de versión preliminar o depuración. Indica al componente que no rechaza 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 los identificadores de componente son los siguientes: 1 - 0xDF: Válido 0xE0 - 0xFD: Reservado. No lo use. 0xFF: la oferta es un paquete de información de oferta especial. Consulte FIRMWARE_UPDATE_OFFER Información para obtener más información. 0xFE: la oferta es un paquete de comandos de oferta especial. Consulte FIRMWARE_UPDATE_OFFER sección Extendida para obtener más información. |
| 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 remitentes de comandos de 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. |
Versión de firmware 5.2.1.2
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
El formato de la versión de firmware no es obligatorio por esta especificación; sin embargo, a continuación se indica una guía recomendada.
Tabla 5.2-5 FIRMWARE_UPDATE_OFFER Comando: Bits de versión de firmware
| Desplazamiento de bits | Campo | Size | Descripción |
|---|---|---|---|
| 0 | Variant | 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 utilizada para firmar el firmware. |
| 8 | Minor Version | 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 | Major Version | 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, nuevas actualizaciones importantes al firmware, etc. |
5.2.1.3 Específico del proveedor
Estos cuatro bytes se pueden usar para codificar cualquier información personalizada de la oferta específica de la implementación del proveedor.
5.2.1.4 Misc. y versión del protocolo
Estos cuatro bytes se pueden usar para codificar cualquier información personalizada de la oferta específica de la implementación del proveedor.
Tabla 5.2-6 FIRMWARE_UPDATE_OFFER Comando: Diseño específico del proveedor
Los bits del byte específico del proveedor se describen en esta tabla.
Tabla 5.2-7 FIRMWARE_UPDATE_OFFER Comando: Error y versión del protocolo
| Desplazamiento de bits | Campo | Size | Descripción |
|---|---|---|---|
| 0 | Versión del protocolo | 4 | Este campo debe establecerse en 0010b que indica que el host o la oferta corresponde a la versión 2 del protocolo CFU. |
| 4 | Reservado | 4 | Reservado. No lo use. |
| 8 | Reservado | 8 | Reservado. No lo use. |
| 16 | Específico del proveedor | 16 | Este campo se puede usar para codificar cualquier información personalizada de la oferta específica de la implementación del proveedor. |
5.2.2 Respuesta
El paquete de FIRMWARE_UPDATE_OFFER respuesta se define de la siguiente manera.
Tabla 5.2-8 FIRMWARE_UPDATE_OFFER Diseño del token de respuesta
Token 5.2.2.1
Tabla 5.2-9 FIRMWARE_UPDATE_OFFER Respuesta: Diseño de token
Los bits del byte token se describen en esta tabla.
Tabla 5.2-10 FIRMWARE_UPDATE_OFFER Respuesta: Bits de token
| Desplazamiento de bits | Campo | Size | Descripción |
|---|---|---|---|
| 0 | Reservado | 8 | Reservado. No lo use. |
| 8 | Reservado | 8 | Reservado. No lo use. |
| 16 | Reservado | 8 | Reservado. No lo use. |
| 24 | Token | 8 | Token para identificar el host. |
5.2.2.2 Reservado (B7 - B4)
Reservado. No lo use.
5.2.2.3 Motivo de rechazo (RR)
Tabla 5.2-11 FIRMWARE_UPDATE_OFFER respuesta: Rechazar diseño de motivo
Tabla 5.2-12 FIRMWARE_UPDATE_OFFER respuesta: rechazar bits de motivo
Los bits del byte Reject Reason se describen en esta tabla.
| Desplazamiento de bits | Campo | Size | 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 obtener una asignación de código de estado a RR, consulte la tabla 5.2-13. |
| 8 | Reservado | 24 | Reservado. No lo use. |
Tabla 5.2-13 FIRMWARE_UPDATE_OFFER valores de código RR de respuesta
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 | Sin embargo, el firmware del componente se ha actualizado un intercambio al nuevo firmware 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 lo use. |
| 0x09: 0xDF | (Reservado) | Reservado. No lo use. |
| 0xE0: 0xFF | (Específico del proveedor) | Los diseñadores del protocolo usan estos valores y el significado es específico del proveedor. |
5.2.2.4 Estado
Tabla 5.2-14 FIRMWARE_UPDATE_OFFER diseño de estado de respuesta
Los bits del byte Status se describen en esta tabla.
Tabla 5.2-15 FIRMWARE_UPDATE_OFFER respuesta: bits de estado
| Desplazamiento de bits | Campo | Size | Descripción |
|---|---|---|---|
| 0 | Estado | 8 | Este valor indica la decisión del componente de aceptar, lápiz, omitir o rechazar la oferta. El componente proporciona el motivo del valor del campo Código RR. Para obtener una asignación de código de estado a RR, consulte la tabla 5.2-16. |
| 8 | Reservado | 24 | Reservado. No lo use. |
Los valores posibles para el byte Status se describen en esta tabla.
Tabla 5.2-16 FIRMWARE_UPDATE_OFFER valores de estado de respuesta
| Estado | Nombre | Descripción |
|---|---|---|
| 0x00 | FIRMWARE_UPDATE_OFFER_SKIP | El componente ha decidido omitir la oferta. El host debe ofrecerlo de nuevo más tarde. |
| 0x01 | FIRMWARE_UPDATE_OFFER_ACCEPT | El componente ha decidido aceptar la oferta. |
| 0x02 | FIRMWARE_UPDATE_OFFER_REJECT | El componente ha decidido rechazar la oferta. |
| 0x03 | FIRMWARE_UPDATE_OFFER_BUSY | El dispositivo está ocupado y el host debe esperar hasta que el dispositivo esté listo. |
| 0x04 | FIRMWARE_UPDATE_OFFER_COMMAND | Se usa cuando el identificador de componente en los bytes de información del componente (vea 5.1.2.1.1 Información del componente) se establece en 0xFE. En Código de comando establecido en OFFER_NOTIFY_ON_READY solicitud, 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 Asignación al protocolo HID
El mensaje se emite al componente a través del mecanismo de informe de salida HID , mediante el identificador de informe de la utilidad HID dedicado para la actualización de firmware. TLC de la utilidad HID que se usará en el Apéndice.
5.3 FIRMWARE_UPDATE_OFFER: información
Si el id. de componente en los bytes de información del componente (vea Información del componente) se establece en 0xFF, los bits (15 bytes) se vuelven a definir para indicar solo información de la 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 Start Offer List, End Offer List, Start Entire Transaction. El componente siempre acepta inmediatamente los paquetes de información de la oferta.
5.3.1 (Comando)
El paquete FIRMWARE_UPDATE_OFFER -Information Command 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 componente
Los bits del byte Component se describen en esta tabla.
Tabla 5.3-3 FIRMWARE_UPDATE_OFFER - Comando de información - Bits de componente
| Desplazamiento de bits | Campo | Size | 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 lo use. |
| 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 vuelto a cargar y que todo el procesamiento de la oferta es (re)starting. |
| 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 use.
5.3.1.3 Reservado B11 - B8
Reservado. No lo use.
5.3.1.4 Reservado B15 - B12
Reservado. No lo use.
5.3.2 Respuesta
La respuesta del paquete de respuesta de información de la oferta FIRMWARE_UPDATE_OFFER se define como se indica a continuación.
Tabla 5.3-5 FIRMWARE_UPDATE_OFFER: Diseño de respuesta de información
Token 5.3.2.1
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 | Size | Descripción |
|---|---|---|---|
| 0 | Reservado | 8 | Reservado. No lo use. |
| 8 | Reservado | 8 | Reservado. No lo use. |
| 16 | Reservado | 8 | Reservado. No lo use. |
| 24 | Token | 8 | Token para identificar el host |
5.3.2.2 Reserved B7 - B4
Reservado. No lo use.
5.3.2.3 Motivo de rechazo (RR)
Tabla 5.3-8 FIRMWARE_UPDATE_OFFER - Respuesta de información - Diseño de código RR
Los bits del byte Reject Reason se describen en esta tabla.
Tabla 5.3-9 FIRMWARE_UPDATE_OFFER- Respuesta de información de la oferta- Bits de código RR
| Desplazamiento de bits | Campo | Size | 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 lo use. |
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 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 | Sin embargo, el firmware del componente se ha actualizado un intercambio al nuevo firmware 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 lo use. |
| 0x09: 0xDF | (Reservado) | Reservado. No lo use. |
| 0xE0: 0xFF | (Específico del proveedor) | Los diseñadores del protocolo usan estos valores y el significado es específico del proveedor. |
5.3.2.4 Estado
Tabla 5.3-11 FIRMWARE_UPDATE_OFFER: Diseño del estado de respuesta de la información de la oferta
Los bits del byte Status se describen en esta tabla.
Tabla 5.3-12 FIRMWARE_UPDATE_OFFER - Información de la oferta - Bits de estado de respuesta
| Desplazamiento de bits | Campo | Size | 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 lo use. |
5.4 FIRMWARE_UPDATE_OFFER: extendido
Si el id. de componente en 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 del 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 comandos extendidos
Componente 5.4.1.1
Tabla 5.4-2 FIRMWARE_UPDATE_OFFER - Paquete de comando extendido - 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 | Size | 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 lo use. |
| 16 | Id. de componente | 8 | Establezca 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ó anteriormente la oferta. |
| 0x02: 0xFF | Reservado | Reservado |
5.4.1.2 Reservado B7 - B4
Reservado. No lo use.
5.4.1.3 Reservado B11 - B8
Reservado. No lo use.
5.4.1.4 Reservado B15 - B12
Reservado. No lo use.
Respuesta 5.4.2
Es posible que la respuesta FIRMWARE_UPDATE_OFFER: Comando de oferta del dispositivo no se reciba inmediatamente. La respuesta se define de la siguiente manera.
Tabla 5.4-5 FIRMWARE_UPDATE_OFFER: diseño de respuesta de paquetes de comandos extendidos
Token 5.4.2.1
Tabla 5.4-6 FIRMWARE_UPDATE_OFFER: respuesta de paquete de comando de oferta: diseño de token
Los bits del byte token se describen en esta tabla.
Tabla 5.4-7 FIRMWARE_UPDATE_OFFER: respuesta de comando de oferta: bits de token
| Desplazamiento de bits | Campo | Size | Descripción |
|---|---|---|---|
| 0 | Reservado | 8 | Reservado. No lo use. |
| 8 | Reservado | 8 | Reservado. No lo use. |
| 16 | Reservado | 8 | Reservado. No lo use. |
| 24 | Token | 8 | Token para identificar el host. |
5.4.2.2 Reservado B7 - B4
Reservado. No lo use.
5.4.2.3 Motivo de rechazo
Tabla 5.4-8 FIRMWARE_UPDATE_OFFER: Diseño rr de respuesta de paquetes de información
Los bits del byte Reject Reason se describen en esta tabla.
Tabla 5.4-9 FIRMWARE_UPDATE_OFFER- Respuesta de comando de oferta - Código RR
| Desplazamiento de bits | Campo | Size | Descripción |
|---|---|---|---|
| 0 | Código RR | 8 | Este valor depende del campo Estado. Para conocer los posibles valores de RR Code, vea Tabla 5.4-10. |
| 8 | Reservado | 24 | Reservado. No lo use. |
Los valores posibles para el byte de CÓDIGO RR se describen en esta tabla.
Tabla 5.4-10 FIRMWARE_UPDATE_OFFER- Paquete de comando 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 | Sin embargo, el firmware del componente se ha actualizado un intercambio al nuevo firmware 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 lo use. |
| 0x09: 0xDF | (Reservado) | Reservado. No lo use. |
| 0xE0: 0xFF | (Específico del proveedor) | Los diseñadores del protocolo usan estos valores 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 paquete de comando 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 comando de oferta
| Desplazamiento de bits | Campo | Size | 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 lo use. |
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 todo el archivo de imagen se ajuste a 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 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.
Comando 5.5.1
Tabla 5.5-1 FIRMWARE_UPDATE_CONTENT Diseño del comando
Encabezado 5.5.1.1 (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 FIRMWARE_UPDATE_CONTENT bits de encabezado
| Desplazamiento de bits | Campo | Size | Descripción |
|---|---|---|---|
| 0 | Marcas | 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 los 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 | Sequence Number | 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 de firmware | 32 | Little Endian (LSB First) Address (Dirección LSB) para escribir los datos. La dirección se basa en 0. El firmware lo usa como desplazamiento para determinar la dirección según sea necesario al colocar la imagen en memoria. |
Los valores posibles para el byte Flags se describen en esta tabla.
Tabla 5.5-4 FIRMWARE_UPDATE_OFFER- Paquete de comando de oferta: valores de marca
| Marca | 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 diseño de datos de comandos
Los bits de los datos de FIRMWARE_UPDATE_CONTENT se describen en esta tabla.
Tabla 5.5-6 FIRMWARE_UPDATE_CONTENT bits de datos de comandos
| Desplazamiento de bits | Campo | Size | Descripción |
|---|---|---|---|
| 64 | data | 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. Los bytes sin usar al final deben ser 0 rellenados. |
Respuesta 5.5.2
Tabla 5.5-7 FIRMWARE_UPDATE_CONTENT diseño de respuesta de comandos
Número de secuencia 5.5.2.1
Tabla 5.5-8 FIRMWARE_UPDATE_CONTENT respuesta: número de secuencia
Los bits de la FIRMWARE_UPDATE_CONTENT Respuesta (3-0) se describen en esta tabla.
Tabla 5.5-9 FIRMWARE_UPDATE_CONTENT - Comando - Bits de respuesta
| Desplazamiento de bits | Campo | Size | Descripción |
|---|---|---|---|
| 0 | Sequence Number | 16 | Este campo es el número de secuencia enviado por el host en la solicitud. |
| 16 | Reservado | 16 | Reservado. No lo use. |
5.5.2.2 Estado
Tabla 5.5-10 FIRMWARE_UPDATE_CONTENT diseño de estado de respuesta
Los bits de la FIRMWARE_UPDATE_CONTENT Respuesta (7-4) se describen en esta tabla.
Tabla 5.5-11 FIRMWARE_UPDATE_OFFER - Respuesta - Bits de estado
| Desplazamiento de bits | Campo | Size | Descripción |
|---|---|---|---|
| 0 | Estado | 8 | Este valor indica el código de estado devuelto por el componente de dispositivo. Esto no es bit a bit y puede ser uno de los valores descritos en la tabla 5.5-12. |
| 8 | Reservado | 24 | Reservado. No lo use. |
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
| Marca | 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 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 de DWORD, en respuesta a FIRMWARE_UPDATE_FLAG_VERIFY. |
| 0x05 | FIRMWARE_UPDATE_ERROR_CRC | CRC de la imagen de firmware no se pudo responder a FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
| 0x06 | FIRMWARE_UPDATE_ERROR_SIGNATURE | Error de comprobación de firma de firmware en respuesta a FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
| 0x07 | FIRMWARE_UPDATE_ERROR_VERSION | Error en la comprobación de la versión de 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 general del comando FIRMWARE_UPDATE_OFFER, como una longitud de datos aplicable no válida. |
5.5.2.3 Reservado B8 - B11
Reservado. No lo use.
5.5.2.4 Reservado B12 - B15
Reservado. No lo use.
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 del firmware actual 7.0.1
Subcomponente: id. de componente 2: versión del firmware actual 12.4.54
Subcomponente: id. de componente 3: versión del firmware actual 4.4.2
Subcomponente: id. de componente 4: versión del 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á:
Ofertas de host: Id. de componente 1: versión de 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 host reproduce 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 actual del firmware 7.0.1
Subcomponente: id. de componente 2: versión actual del firmware 12.4.54
Subcomponente: id. de componente 3: versión actual del firmware 7.4.2
Subcomponente: id. de componente 4: versión actual del firmware 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 está al componente principal para 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
El componente principal rechaza
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 host reproduce todas 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
El componente principal rechaza
Ofertas de host: Id. de componente 3: versión de firmware 9.0.0
El componente principal rechaza