Especificação do protocolo CFU (Component Firmware Update)
Essa especificação descreve um protocolo HID genérico para atualizar o firmware para componentes presentes em um computador ou acessórios. A especificação permite que um componente aceite firmware sem interromper a operação do dispositivo durante um download. A especificação dá suporte a configurações em que o componente que aceita o firmware pode ter subcomponentes, que exigem imagens de firmware separadas. A especificação permite que o componente responsável decida se aceita o firmware. Ele também atua como uma otimização porque a imagem de firmware só é enviada para o componente se ela for capaz ou pronta para aceitá-la.
Nota
A CFU está disponível no Windows 10, versão 2004 (Atualização do Windows 10 de maio de 2020) e versões posteriores.
Conteúdo
- 1 Introdução
- 2 Arquitetura de hardware com suporte
- Pré-requisitos de protocolo 3
- 4 Visão geral do protocolo CFU
- sequência de comandos de programação de atualização do firmware 4.1
- 4.1.1 Estado: notificação de Inicialização do Host
- 4.1.2 Estado: notificação OFFER_INFO_START_OFFER_LIST
- 4.1.3 Estado: enviar o comando FIRMWARE_UPDATE_OFFER
- 4.1.4 Estado: enviar firmware
- 4.1.5 Estado da decisão: Há mais ofertas
- 4.1.6 Estado: notificação OFFER_INFO_END_OFFER_LIST
- 4.1.7 Estado da decisão: Repetir lista de ofertas
- estado 4.1.8: o dispositivo está ocupado
- sequência de comandos de programação de atualização do firmware 4.1
- 5 Formato de pacote do protocolo CFU
- 6 Apêndice 1: Exemplo de sequência de comandos de programação de atualização de firmware
Tabelas
Table 5.1-1 Layout de resposta GET_FIRMWARE_VERSION
Tabela5.1-2 Resposta GET_FIRMWARE_VERSION - Layout do cabeçalho
Tabela5.1-3 Resposta GET_FIRMWARE_VERSION - Bits de cabeçalho
Tabela 5.1-4 Resposta de GET_FIRMWARE_VERSION – Versão do Componente e Layout das Propriedades
Tabela 5.1-5 Resposta de GET_FIRMWARE_VERSION – Versão do Componente e Bits das Propriedades
Tabela 5.2-1 Layout do comando FIRMWARE_UPDATE_OFFER
Tabela 5.2-2 Comando FIRMWARE_UPDATE_OFFER - Layout de Informações do Componente
Tabela 5.2-3 Comando FIRMWARE_UPDATE_OFFER - Bits de Informações do Componente
Tabela 5.2-4 Comando FIRMWARE_UPDATE_OFFER - Layout da versão do firmware
Tabela 5.2-5 Comando FIRMWARE_UPDATE_OFFER - Bits da versão do firmware
Tabela 5.2-6 Comando FIRMWARE_UPDATE_OFFER - Layout específico do fornecedor
Comando de FIRMWARE_UPDATE_OFFER da Tabela 5.2-7 – Misc. e Versão de protocolo
Tabela 5.2-8 Layout do token de resposta FIRMWARE_UPDATE_OFFER
Tabela 5.2-9 Resposta FIRMWARE_UPDATE_OFFER - Layout de token
Tabela 5.2-10 Resposta FIRMWARE_UPDATE_OFFER - Bits de token
Tabela 5.2-11 Resposta FIRMWARE_UPDATE_OFFER - Layout do motivo da rejeição
Tabela 5.2-12 Resposta FIRMWARE_UPDATE_OFFER - Bits do motivo da rejeição
Tabela 5.2-13 Valores do código RR da resposta FIRMWARE_UPDATE_OFFER
Tabela 5.2-14 Layout do status da resposta FIRMWARE_UPDATE_OFFER
Tabela 5.2-15 Resposta FIRMWARE_UPDATE_OFFER - Bits de status
Tabela 5.2-16 Valores de Status de Resposta FIRMWARE_UPDATE_OFFER
Tabela 5.3-1 FIRMWARE_UPDATE_OFFER - Layout do comando de informações
Tabela 5.3-2 FIRMWARE_UPDATE_OFFER - Comando de informações - Layout do componente
Tabela 5.3-3 FIRMWARE_UPDATE_OFFER - Comando de informações - Bits de componentes
Tabela 5.3-4 FIRMWARE_UPDATE_OFFER – Comando de Informação – Valores de Código de Informação
Tabela 5.3-5 FIRMWARE_UPDATE_OFFER - Layout da resposta de informações
Tabela 5.3-6 FIRMWARE_UPDATE_OFFER - Layout do token de resposta do pacote de informações
Tabela 5.3-7 FIRMWARE_UPDATE_OFFER - Resposta de informações - Bits de token
Tabela 5.3-8 FIRMWARE_UPDATE_OFFER - Resposta de informações - Layout do código RR
Tabela 5.3-9 FIRMWARE_UPDATE_OFFER - Resposta de informações da oferta - Bits do código RR
Tabela 5.3-10 FIRMWARE_UPDATE_OFFER- Resposta de informações - Valores do código RR
Tabela 5.3-11 FIRMWARE_UPDATE_OFFER - Layout do status da resposta de informações da oferta
Tabela 5.3-12 FIRMWARE_UPDATE_OFFER - Informações da oferta - Bits de status da resposta
Tabela 5.4-1 FIRMWARE_UPDATE_OFFER - Layout do comando estendido
Tabela 5.4-2 FIRMWARE_UPDATE_OFFER - Pacote do comando estendido - Comando - Layout do componente
Tabela 5.4-3 FIRMWARE_UPDATE_OFFER – Comando Estendido – Bits de componente
Tabela 5.4-4 FIRMWARE_UPDATE_OFFER - Comando estendido - Valores do código do comando
Tabela 5.4-5 FIRMWARE_UPDATE_OFFER - Layout de resposta do pacote do comando estendido
Tabela 5.4-6 FIRMWARE_UPDATE_OFFER- Resposta do pacote do comando da oferta - Layout do token
Tabela 5.4-7 FIRMWARE_UPDATE_OFFER – Resposta do comando da oferta – Bits de token
Tabela 5.4-8 FIRMWARE_UPDATE_OFFER – Layout RR de Resposta do Pacote de Informações da Oferta
Tabela 5.4-9 FIRMWARE_UPDATE_OFFER - Resposta do comando de Oferta – Código RR
Tabela 5.4-10 FIRMWARE_UPDATE_OFFER - Pacote do comando de Oferta – Valores de Código RR
Tabela 5.4-11 FIRMWARE_UPDATE_OFFER - Layout do status da resposta do pacote do comando de oferta
Tabela 5.4-12 FIRMWARE_UPDATE_OFFER- Código RR da resposta do pacote do comando de oferta
Tabela 5.5-1 Layout do comando FIRMWARE_UPDATE_CONTENT
Tabela 5.5-2 Layout do cabeçalho do comando FIRMWARE_UPDATE_CONTENT
Tabela 5.5-3 Bits de cabeçalho FIRMWARE_UPDATE_CONTENT
Tabela 5.5-4 FIRMWARE_UPDATE_OFFER- Pacote do comando de oferta – Valores de sinalizador
Tabela 5.5-5 Layout de dados do cabeçalho do comando FIRMWARE_UPDATE_CONTENT
Tabela 5.5-6 Bits de dados do comando de FIRMWARE_UPDATE_CONTENT
Tabela 5.5-7 Layout da resposta do comando FIRMWARE_UPDATE_CONTENT
Tabela 5.5-8 Resposta de FIRMWARE_UPDATE_CONTENT – Número de Sequência
Tabela 5.5-9 FIRMWARE_UPDATE_CONTENT - Comando - Bits de resposta
Tabela 5.5-10 Layout do status da resposta FIRMWARE_UPDATE_CONTENT
Tabela 5.5-11 FIRMWARE_UPDATE_OFFER - Resposta - Bits de status
Tabela 5.5-12 Resposta FIRMWARE_UPDATE_OFFER- - Valores do código de status
1 Introdução
Os computadores e acessórios de hoje têm componentes internos que executam operações complexas. Para garantir um produto de qualidade, é necessário atualizar frequentemente o comportamento desses dispositivos em estágios posteriores de desenvolvimento ou depois que eles forem enviados aos clientes. A atualização pode corrigir problemas funcionais ou de segurança identificados ou a necessidade de adicionar novos recursos. Uma grande parte da lógica complexa está no firmware em execução no dispositivo, que é atualizável.
Essa especificação descreve um protocolo HID genérico para atualizar o firmware para componentes presentes em um computador ou seus acessórios. A implementação de HID está além do escopo da especificação.
Alguns dos recursos do protocolo são:
O protocolo é baseado no HID-onipresente e tem suporte interno do Windows em vários barramentos de interconexão, como USB e I2C. Portanto, a mesma solução de software (driver) pode ser aproveitada para atualizar o firmware para todos os componentes.
Nota
Como a especificação é baseada em pacotes, é simples adaptá-la a cenários não HID.
A especificação permite que um componente aceite firmware sem interromper a operação do dispositivo durante o download. Ele permite uma experiência melhor para os usuários, pois eles não precisam esperar que o processo de atualização de firmware seja concluído antes que eles possam retomar outras tarefas. O novo firmware pode ser invocado em uma única operação atômica em um momento que tenha impacto mínimo sobre o usuário.
A especificação dá suporte a configurações em que o componente que aceita o firmware pode ter subcomponentes, que exigem imagens de firmware separadas.
Nota
O processo de um componente transferir o firmware para o subcomponente está fora do escopo desta especificação.
A especificação suporta o conceito de uma oferta e depende do componente responsável por decidir se aceitará o firmware. A decisão de aceitar um novo firmware não é trivial. Pode haver dependências entre o tipo de firmware e/ou a versão e o tipo/versão subjacente do hardware ao qual o novo firmware se aplica. Uma oferta também atua como um mecanismo de otimização porque a imagem de firmware é enviada para o componente somente se ela for capaz /pronta para aceitá-la.
1.1 Glossário
| Prazo | Descrição |
|---|---|
| ID do componente | Em um dispositivo com vários componentes, uma ID de componente identifica exclusivamente cada componente. |
| CRC | Verificação de redundância cíclica Um algoritmo de hash não criptográfico usado para produzir um resumo ou impressão digital de um bloco de dados. O CRC é usado como uma verificação para fornecer garantia de que o bloco de dados não foi alterado desde que o CRC foi calculado. O CRC não é infalível, mas fornece confiança de que os dados foram recebidos corretamente. |
| Dispositivo | Uma coleção de componentes (um componente primário e zero ou mais subcomponentes). O dispositivo é visível para o sistema operacional como uma única unidade. O host interage com o dispositivo, que normalmente é o componente principal. Um computador pode ter vários dispositivos nele. Com relação a essa especificação, as comunicações com dois dispositivos diferentes são totalmente independentes. |
| Motorista | Um driver escrito usando a estrutura do WDF (Windows Driver Foundation). |
| Firmware | O código em execução no hardware físico. O firmware é atualizável e geralmente reside na memória programável associada ao hardware. |
| Hardware | Um pedaço físico de silício no computador. |
| Componente primário | Um pedaço de hardware em um computador e o firmware para ele. No contexto dessa especificação, um componente é a entidade que precisa e aceita a atualização de firmware. |
| Segment | Uma imagem de firmware para um componente pode ser segmentada em segmentos menores. Cada segmento é uma imagem de firmware pequena. |
| ID do Segmento | Se um firmware de um componente for segmentado em segmentos menores, a ID do segmento será o identificador exclusivo para o segmento. |
| Assinatura | Um meio criptográfico para determinar se a imagem de firmware foi alterada por meios não autorizados. As assinaturas são opcionais, mas recomendadas e estão fora do escopo desta especificação. |
| Subcomponente | Dependendo da arquitetura de hardware, nem todos os componentes podem estar visíveis para o sistema operacional, pois podem estar conectados downstream de um componente visível ao sistema. Esses componentes são chamados de subcomponentes nesta especificação. |
| TLC | Coleção de nível superior da HID. |
| Símbolo | Um identificador para uma sessão de host. Um host cria um token e o envia em comandos e o dispositivo o retorna na resposta. Os tokens podem ser usados para serializar determinadas transações ou para identificar se uma sessão foi perdida e outra iniciada. |
Escopo 1.2
1.2.1 Metas
É necessária uma solução independente de barramento para evitar um novo protocolo para cada tipo de barramento. HID é onipresente e atende a esse requisito.
A capacidade de dar suporte à atualização de firmware para um dispositivo de vários componentes, em que um componente atua como o componente primário e outros são subcomponentes conectados ao componente primário. Cada componente requer seu próprio firmware com dependências não triviais entre si.
Um modelo de driver comum para baixar a imagem de firmware para o componente. Em seguida, o componente tem algoritmos específicos de subcomponente para encaminhamento aos subcomponentes. Os subcomponentes também podem executar verificações de validade em seu firmware e passar os resultados de volta para o componente primário.
A capacidade de dar suporte à atualização de firmware enquanto a operação do dispositivo está em andamento.
A capacidade de atualizar ou reverter o firmware em dispositivos de produção por meio de ferramentas autorizadas e atualizar dispositivos no mercado por meio do Windows Update.
A flexibilidade para dar suporte a firmware em desenvolvimento/firmware já no mercado.
A capacidade de segmentar uma imagem de firmware grande em segmentos menores para facilitar a aceitação da imagem de firmware pelo componente.
1.2.2 Sem objetivos
Defina o formato interno da imagem de firmware: para o host, a imagem de firmware é um conjunto de entradas de endereço e conteúdo.
Assinar/criptografar/validar o firmware aceito: essa especificação não descreve como assinar e criptografar as imagens de firmware. É necessário que o firmware atual esperado em execução no componente valide o firmware que está sendo baixado.
Defina um mecanismo sobre como o componente interage com os subcomponentes: o host interage com o dispositivo como uma única unidade, normalmente o componente primário. O componente deve atuar como uma ponte para comunicação relacionada ao firmware de subcomponente.
2 Arquitetura de hardware com suporte
Para dar suporte a um design de hardware flexível, o protocolo dá suporte a um dispositivo de vários componentes em que cada componente requer sua própria imagem de firmware. No design, um componente é o componente primário e os subcomponentes dependentes são conectados a esse componente primário. Cada componente é descrito exclusivamente por uma ID de componente.
O dispositivo multifator é visível para o sistema operacional como uma única unidade. O host interage apenas com o dispositivo, normalmente o componente primário usando esse protocolo CFU. A comunicação entre o componente e seus subcomponentes está além do escopo dessa especificação.
Em um computador, pode haver muitos dispositivos diferentes (em que um dispositivo pode ter um ou mais componentes lá). No contexto desse protocolo, a comunicação com cada dispositivo é independente. Cada dispositivo tem uma instância correspondente do host.
3 Pré-requisitos de protocolo
Esta seção lista os requisitos e as práticas recomendadas que devem ser implementadas para aproveitar este protocolo:
Uso de imagem atômica
Uma imagem de firmware para um componente não é usada até que toda a imagem de firmware tenha sido baixada com êxito. Caso o firmware seja dividido em vários segmentos, a imagem não deverá ser usada até que o segmento final seja recebido do remetente. As verificações de integridade devem ser executadas na imagem final. É recomendável que o transporte, que está sendo usado para entregar a imagem de firmware, tenha mecanismos de correção de erro e repetição ativos para evitar um download repetido caso ocorram erros de transporte.
A atualização do firmware não deve interromper a operação do dispositivo
O dispositivo que aceita a imagem de firmware deve ser capaz de operar durante a atualização. O dispositivo deve ter memória extra para armazenar e validar o firmware de entrada, enquanto seu firmware atual não é substituído.
Autenticação e integridade
O implementador decide quais são os fatores que constituem uma imagem de firmware autêntica. É recomendável que o firmware atual do componente deva pelo menos validar o CRC da imagem de firmware de entrada. O firmware atual também deve empregar assinatura digital ou outros algoritmos de detecção de erros. Se a validação falhar, o firmware rejeitará a atualização. Falha na Recuperação
Se a imagem de firmware for baixada e não tiver êxito, o dispositivo não deverá invocar o novo firmware e continuar operando com o firmware existente. O host pode repetir a atualização. A frequência de repetição é específica para a implementação.
Confidencialidade
Opcional. Um segmento de firmware pode ser criptografado. As técnicas de criptografia e descriptografia estão além do escopo dessa especificação. Essa especificação trata o conteúdo do firmware como um fluxo de dados, independentemente de ser criptografado.
Proteção de reversão
As políticas de reversão são impostas pelo componente primário e são específicas para a implementação. O firmware atual no componente valida as imagens de firmware recebidas em relação às políticas internas, como o número da versão deve ser mais recente, ou o tipo de versão não pode ser alternado de versão para depuração, e assim por diante. O protocolo permite que as mensagens indiquem que uma atualização é aceita mesmo que esteja violando políticas de reversão.
Visão geral do protocolo 4 CFU
O protocolo CFU é um conjunto de comandos e respostas que são necessários para enviar as novas imagens de firmware do host para o dispositivo para o qual o firmware se destina.
Em um alto nível, o protocolo itera sobre todas as imagens de firmware a serem enviadas ao dispositivo. Para cada imagem de firmware, o host oferece para enviar o arquivo para o dispositivo. Somente se o dispositivo aceitar a oferta, o host enviará o arquivo.
Para dar suporte a casos em que uma ordem de atualização de dispositivo tem dependências, o dispositivo pode não aceitar determinadas ofertas na primeira passagem, portanto, o protocolo permite que o host reenvia todas as ofertas de firmware para o dispositivo até que todas as dependências sejam resolvidas.
4.1 Sequência de comandos de programação de atualização de firmware
Aqui está a sequência de comandos CFU para atualizar a imagem de firmware.
4.1.1 Estado: notificação de Inicialização do Host
Depois que o host se inicializa e identifica um conjunto de ofertas que precisa enviar para o dispositivo, o host emite um comando OFFER_INFO_START_ENTIRE_TRANSACTION para indicar ao componente que o host está agora inicializado. A finalidade desse comando é notificar o firmware do dispositivo atual de que uma nova instância do host está disponível. Essa notificação é útil quando uma instância anterior do host é encerrada inesperadamente. O dispositivo deve concluir esse comando com êxito.
4.1.2 Estado: notificação OFFER_INFO_START_OFFER_LIST
Nesse estado, o host emite o comando OFFER_INFO_START_OFFER_LIST para indicar que ele está pronto para enviar as ofertas para o firmware do dispositivo atual. O componente primário do dispositivo deve concluir esse comando com êxito.
Esse comando é útil porque o host pode enviar todas as ofertas para o dispositivo mais de uma vez.
Estado 4.1.3: Enviar o comando FIRMWARE_UPDATE_OFFER
O host envia uma oferta para o componente primário (ou seu subcomponente) para verificar se o componente deseja aceitar/rejeitar o firmware. A oferta contém todos os metadados necessários da imagem de firmware, para que o firmware atual do componente possa decidir se aceita, adia, ignora ou rejeita a oferta.
A oferta pode ser para o componente primário ou para o subcomponente. Se o componente puder aceitar a oferta, ele se preparará para receber o firmware. Isso pode envolver a preparação de um banco de memória para receber a imagem de firmware de entrada. O componente pode não aceitar a oferta, por exemplo, o componente pode já ter uma versão de firmware mais recente (ou a mesma) que o host pretende enviar. Por mais motivos, consulte os exemplos descritos no Apêndice 1: exemplo de sequência de comandos de programação de atualização de firmware.
Mesmo que uma oferta seja aceita, o componente principal ainda poderá rejeitar a imagem do firmware após o download por falha nas verificações de integridade e/ou reversão em relação à imagem real recebida. O componente deve verificar cada propriedade da imagem do firmware independentemente de qualquer informação na oferta.
O host emite o comando FIRMWARE_UPDATE_OFFER para notificar o componente primário sobre a imagem de firmware que o host pretende enviar.
Se o componente aceitar a oferta, ele terá o status FIRMWARE_UPDATE_OFFER_ACCEPT, confirmando a aceitação.
Se o firmware do dispositivo estiver ocupado e o componente primário não for capaz de aceitar essa ou a próxima oferta no momento, ele enviará uma resposta ocupada com FIRMWARE_UPDATE_OFFER_BUSY status.
Se o firmware atual estiver interessado na oferta, mas não puder aceitá-la (por exemplo, devido a uma dependência de uma atualização faltante para um subcomponente), ele responderá com um FIRMWARE_UPDATE_OFFER_SKIP, indicando que está interessado na oferta, mas não pode aceitá-la. Em seguida, o host prossegue para a próxima oferta e deverá re-oferecer esse firmware mais tarde.
Se o firmware atual não estiver interessado na oferta (por exemplo, é uma versão mais antiga), ele responderá com um status FIRMWARE_UPDATE_OFFER_REJECT fornecendo o motivo de rejeição apropriado. Esse status não indica que o host não pode reenviar essa oferta no futuro. O host normalmente envia cada oferta ao inicializar ou reenviar a lista de ofertas para o dispositivo (consulte a Notificação de Estado: OFFER_INFO_START_OFFER_LIST).
4.1.4 Estado: Enviar firmware
Nesse estado, o host começa a enviar a imagem de firmware para o componente primário, para o qual o componente aceitou anteriormente a oferta.
Como o conteúdo da imagem de firmware provavelmente ultrapassará os limites de carga de um único comando, o host divide as imagens de firmware em pacotes. O host envia cada pacote sequencialmente em um comando FIRMWARE_UPDATE CONTENT separado. O componente primário deve gerar um pacote de resposta para cada comando.
Cada comando FIRMWARE_UPDATE CONTENT descreve um endereço de offset que inclui uma carga parcial de firmware. O componente usa o deslocamento para determinar o endereço em que a carga útil parcial do firmware deve ser armazenada. O dispositivo grava o conteúdo em um local apropriado e reconhece o comando enviando uma resposta.
Para o primeiro pacote que o host envia, ele define o sinalizador FIRMWARE_UPDATE_FLAG_FIRST_BLOCK, indicando ao dispositivo que este é o primeiro pacote da imagem de firmware. Se o dispositivo ainda não tiver se preparado para receber o firmware, ele poderá fazê-lo no momento.
Para o último pacote que o host envia, ele define o sinalizador FIRMWARE_UPDATE_FLAG_LAST_BLOCK.
Depois que o firmware atual no dispositivo tiver gravado o conteúdo parcial do firmware incluído neste comando, ele deve executar verificações de validação e autenticação na imagem de firmware de entrada antes de enviar uma resposta. Isso inclui minimamente:
Uma verificação de CRC para garantir a integridade de toda a imagem do firmware.
Se a verificação de CRC for bem-sucedida, a assinatura da imagem de entrada pode ser verificada opcionalmente.
Após a verificação de assinatura opcional, uma verificação de versão para garantir que a nova versão do firmware seja a mesma ou mais recente que o firmware existente.
Caso a imagem de firmware de entrada tenha sido dividida em segmentos menores, cabe ao firmware atual determinar se é o último segmento da imagem de firmware e, posteriormente, incluir todos os segmentos como parte da validação.
Se as verificações anteriores forem aprovadas, o firmware atual poderá configurar o dispositivo para trocar para a nova imagem na próxima reinicialização e informar o sucesso ao host. Normalmente, o componente não inicia uma redefinição automática. Isso é para evitar interrupções em qualquer software, firmware, entidades de hardware com as quais o componente está interagindo. No entanto, isso não é um requisito e pode variar dependendo da implementação.
Se as etapas de verificação falharem, o firmware não deverá configurar uma troca na próxima redefinição e deve indicar uma resposta de falha ao host.
4.1.5 Estado de decisão: há mais ofertas
Nesse estado, o host determina se há mais ofertas para enviar ao dispositivo.
4.1.6 Estado: notificação OFFER_INFO_END_OFFER_LIST
Esse estado é atingido quando o host envia todas as ofertas para o componente primário no firmware do dispositivo atual. O host envia o comando OFFER_INFO_END_OFFER_LIST para indicar que enviou todas as ofertas para o componente.
O dispositivo deve concluir esse comando com êxito.
4.1.7 Estado da decisão: Repetir lista de ofertas
O anfitrião determina se precisa reenviar todas as ofertas. Esse caso poderia ocorrer se anteriormente o componente primário tivesse ignorado algumas ofertas e aceitado algumas ofertas. O host deve reproduzir a lista de ofertas novamente.
Pode haver outras lógicas específicas de implementação que possam resultar na decisão de reexibir a lista de ofertas.
Estado 4.1.8: o dispositivo está ocupado
Esse estado implica que um dispositivo retornou uma resposta ocupada a uma oferta.
O host envia um comando OFFER_NOTIFY_ON_READY, para o qual o dispositivo não responde com aceitação até que o dispositivo seja gratuito.
5 Formato de pacote de protocolo CFU
O protocolo CFU é implementado como um conjunto de comandos e respostas. O protocolo é sequencial por natureza. Para cada comando que o host envia a um componente, espera-se que o componente responda (a menos que explicitamente declarado de outra forma nesta especificação). O host não envia o próximo comando até que uma resposta válida seja recebida para o comando anterior enviado.
Caso o componente não responda dentro de um período ou envie uma resposta inválida, o host poderá reiniciar o processo desde o início. Esse protocolo não define um valor de tempo limite específico.
Há comandos para obter as informações de versão do firmware atual no componente; para enviar a oferta e enviar a imagem de firmware.
No entanto, o host não precisa suspender uma oferta com base na resposta recebida do componente primário sobre as informações de versão consultadas. As informações são tornadas detectáveis para registro ou outras finalidades.
5.1 GET_FIRMWARE_VERSION
Obtém as versões de firmware atuais do componente primário (e seus subcomponentes). O comando não tem argumentos.
Comando 5.1.1
Esse comando é enviado pelo host para consultar as versões dos firmwares atuais no componente primário (e seus subcomponentes). O host pode usá-lo para confirmar se o firmware foi atualizado com êxito. Ao receber esse comando, o componente primário responde com a versão do firmware para si mesmo e todos os subcomponentes.
Resposta 5.1.2
O componente responde com a versão de firmware do componente primário e os subcomponentes. O tamanho da resposta é de 60 bytes, permitindo informações de versão para até sete componentes (um primário e até seis subcomponentes).
Table 5.1-1 Layout de resposta GET_FIRMWARE_VERSION
Layout de Resposta 
5.1.2.1 Cabeçalho
Tabela5.1-2 Resposta GET_FIRMWARE_VERSION - Layout do cabeçalho
Resposta 
O cabeçalho da resposta fornece as informações a seguir.
Tabela5.1-3 Resposta GET_FIRMWARE_VERSION - Bits de cabeçalho
| Deslocamento de bit | Campo | Tamanho | Descrição |
|---|---|---|---|
| 0 | Contagem de componentes | 8 | O número de componentes para download gerenciados por meio desse mecanismo para este Componente. A Contagem de Componentes determina o tamanho máximo da tabela. Atualmente, há suporte para até 7 componentes para garantir que a resposta possa se ajustar aos 60 bytes permitidos. |
| 8 | Rsvd | 16 | Campos reservados. O remetente deve defini-los como 0. O receptor deve ignorar esse valor. |
| 24 | Versão do protocolo | 4 | Os bits de revisão da atualização do firmware representam a revisão do protocolo de atualização do FW que está sendo usada no momento no transporte. Para a interface definida neste documento, a Revisão de Atualização de Firmware deve ser 0010b. |
| 28 | Rsvd | 3 | Campos reservados. O remetente deve defini-los como 0. O receptor deve ignorar esse valor. |
| 31 | E | 1 | O sinalizador de extensão é um mecanismo de protocolo futuro para habilitar componentes adicionais a serem reportados. |
5.1.2.2 Versão e propriedades do componente
Para cada componente, dois DWORDs são usados para descrever as propriedades de até 7 componentes. Se a contagem de componentes no cabeçalho for menor que 7, o DWORDS não utilizado no final da resposta deverá ser definido como 0.
Tabela 5.1-4 Resposta de GET_FIRMWARE_VERSION – Versão do Componente e Layout das Propriedades
Resposta 
Cada informação específica do componente é descrita em dois DWORDs da seguinte maneira:
Tabela 5.1-5 Resposta de GET_FIRMWARE_VERSION – Versão do Componente e Bits das Propriedades
| Deslocamento de bit | Campo | Tamanho | Descrição |
|---|---|---|---|
| 0 | Versão do firmware | 32 | Retorna a versão do firmware atual para esse componente. Essa especificação não exige nenhum formato específico para a versão do firmware. Consulte a seção Versão do Firmware para obter diretrizes. |
| 32 | Banco | 2 | Opcional. Dependendo da arquitetura, o hardware do componente pode ter vários bancos nos quais o firmware pode ser armazenado. Dependendo da implementação, o remetente pode especificar o banco no qual o firmware existe atualmente. Esse campo é Obrigatório Condicional – o suporte é opcional, no entanto, não deve ser usado para nenhuma outra finalidade. |
| 34 | Reservado | 2 | Campos reservados. O remetente deve defini-los como 0. O receptor deve ignorar esse valor. |
| 36 | Específicos do fornecedor | 4 | Campo específico do fornecedor, para ser utilizado de maneira particular em uma implementação. Um fornecedor pode usar esses bits para codificar informações como: - Tipo de firmware: pré-lançamento/auto-hospedagem/produção; depuração/varejo – Fase de desenvolvimento – ID do produto, para impedir que os componentes recebam firmware para outros produtos usando o mesmo protocolo de atualização. |
| 40 | ID do componente | 8 | Um identificador exclusivo para o componente. |
| 48 | Específicos do fornecedor | 16 | Campo específico do fornecedor que pode ser utilizado de forma específica para implementação. |
5.1.3 Mapeamento para HID
Isso é implementado como uma solicitação HID Get Feature com um tamanho de resposta de 60 bytes, além da ID do Relatório. O comprimento do relatório de recursos acomoda toda a resposta GET_FIRMWARE_VERSION. Não há dados associados à solicitação Obter Recurso do host.
5.2 OFERTA_DE_ATUALIZAÇÃO_DE_FIRMWARE
Determina se o componente primário aceita ou rejeita um firmware.
Comando 5.2.1
O host envia esse comando para o componente para determinar se ele aceita ou rejeita um firmware. O host deve enviar uma oferta e o componente deve aceitar a oferta antes que o host possa enviar o firmware.
O pacote de comando FIRMWARE_UPDATE_OFFER é definido da seguinte maneira.
Tabela 5.2-1 Layout do comando FIRMWARE_UPDATE_OFFER
Esquema de Comando 
5.2.1.1 Informações do componente
Tabela 5.2-2 Comando FIRMWARE_UPDATE_OFFER - Layout de Informações do Componente
Comando 
Os bits do byte de Informação do Componente são descritos nesta tabela.
Tabela 5.2-3 Comando FIRMWARE_UPDATE_OFFER - Bits de Informações do Componente
| Deslocamento de bit | Campo | Tamanho | Descrição |
|---|---|---|---|
| 0 | Número do Segmento | 8 | Esse campo é usado caso o firmware para um componente seja segmentado em segmentos menores. Se usado, esse valor indica o segmento contido no pacote de conteúdo subsequente. Por exemplo, se a imagem de firmware do componente for muito grande e o componente primário só puder usar partes menores da imagem por vez, esse campo poderá ser usado para indicar que essa oferta é para o i-th segmento da imagem completa. Uma oferta separada pode ser enviada para o componente primário que contém o i+1º segmento da imagem e assim por diante. |
| 8 | Reservado | 6 | Campos reservados. O remetente deve defini-los como 0. O receptor deve ignorar esse valor. |
| 14 | I | 1 | Forçar reinicialização imediata (I) - Esse valor de bit é usado para indicar ao componente que deve se reinicializar imediatamente após a conclusão do download do firmware e verificado para invocá-lo imediatamente. - Este sinalizador destina-se à fase de desenvolvimento. |
| 15 | V | 1 | Forçar ignorar a versão (V) - Este sinalizador destina-se à imagem de firmware de pré-lançamento ou depuração. Indica ao componente para não rejeitar o firmware com base na versão do firmware. - Este sinalizador destina-se à fase de desenvolvimento. Ele pode ser usado para reverter intencionalmente para uma versão anterior do firmware. - Esse sinalizador deve ser ignorado pelo firmware de produção. |
| 16 | ID do componente | 8 | Esse byte é usado para cenários de vários componentes. Esse campo pode ser usado para identificar o subcomponente para o qual a oferta se destina. Se não for usado, o valor deverá ser 0. Os valores possíveis de IDs de componente são os seguintes: 1 – 0xDF: Válido 0xE0 - 0xFD: Reservado. Não use. 0xFF: a oferta é um pacote de informações de oferta especial. Consulte as informações do FIRMWARE_UPDATE_OFFER para obter detalhes. 0xFE: a oferta é um pacote do comando de oferta especial. Consulte a seção estendida FIRMWARE_UPDATE_OFFER para obter detalhes. |
| 24 | Símbolo | 8 | O host insere um token exclusivo no pacote de oferta para o componente. O componente deve devolver este token na resposta da oferta. Isso será útil se houver a necessidade de o componente distinguir entre os diferentes hosts/tipos de hosts. Os valores exatos a serem usados são específicos para a implementação. Por exemplo, um valor pode ser usado para um driver e outro para o aplicativo. Isso permite que o firmware de dispositivo atual contabilize possíveis vários remetentes de comandos CFU. Uma implementação possível pode ser aceitar o primeiro comando CFU e rejeitar todos os outros comandos com tokens diferentes até que as primeiras transações de CFU sejam concluídas. |
Versão do firmware 5.2.1.2
Esses quatro bytes representam a versão de 32 bits do firmware. O formato da versão do firmware não é exigido por essa especificação. Recomenda-se o seguinte.
Tabela 5.2-4 Comando FIRMWARE_UPDATE_OFFER - Layout da versão do firmware
Comando 
O formato para a versão do firmware não é exigido por essa especificação, no entanto, a seguir está uma diretriz recomendada.
Tabela 5.2-5 Comando de FIRMWARE_UPDATE_OFFER – Bits de versão do firmware
| Deslocamento de bit | Campo | Tamanho | Descrição |
|---|---|---|---|
| 0 | Variante | 8 | Esse campo pode ser descrito para distinguir entre um firmware de pré-lançamento e um firmware de produção. Pode indicar o tipo de assinatura usado para assinar o firmware. |
| 8 | Versão secundária | 16 | Esse valor de campo deve ser atualizado para cada build do firmware. Esse valor de campo deve ser atualizado para cada build do firmware. |
| 24 | Versão principal | 8 | Esse campo é a versão principal da imagem de firmware. Esse campo deve ser atualizado ao enviar uma nova linha de produtos, novas atualizações importantes para o firmware e assim por diante. |
5.2.1.3 Específico do fornecedor
Esses quatro bytes podem ser usados para codificar qualquer informação personalizada na oferta específica à implementação do fornecedor.
5.2.1.4 Diversos e versão do protocolo
Esses quatro bytes podem ser usados para codificar qualquer informação personalizada na oferta que seja específica à implementação do fornecedor.
Tabela 5.2-6 Comando FIRMWARE_UPDATE_OFFER - Layout específico do fornecedor
Comando 
Os bits do byte específico do fornecedor são descritos nesta tabela.
Comando de FIRMWARE_UPDATE_OFFER da Tabela 5.2-7 – Misc. e Versão de protocolo
| Deslocamento de bit | Campo | Tamanho | Descrição |
|---|---|---|---|
| 0 | Versão do protocolo | 4 | Esse campo deve ser definido como 0010b indicando que o host/oferta corresponde à versão 2 do protocolo CFU. |
| 4 | Reservado | 4 | Reservado. Não use. |
| 8 | Reservado | 8 | Reservado. Não use. |
| 16 | Específicos do fornecedor | 16 | Esse campo pode ser usado para codificar qualquer informação personalizada na oferta que seja específica para a implementação do fornecedor. |
Resposta 5.2.2
O pacote de resposta FIRMWARE_UPDATE_OFFER é definido da seguinte maneira.
Tabela 5.2-8 Layout do token de resposta FIRMWARE_UPDATE_OFFER
layout do token de resposta 
5.2.2.1 Token
Tabela 5.2-9 Resposta FIRMWARE_UPDATE_OFFER - Layout de token
Os bits do byte de Token são descritos nesta tabela.
Tabela 5.2-10 Resposta FIRMWARE_UPDATE_OFFER - Bits de token
| Deslocamento de bit | Campo | Tamanho | Descrição |
|---|---|---|---|
| 0 | Reservado | 8 | Reservado. Não use. |
| 8 | Reservado | 8 | Reservado. Não use. |
| 16 | Reservado | 8 | Reservado. Não use. |
| 24 | Símbolo | 8 | Token para identificar o host. |
5.2.2.2 Reservado (B7 – B4)
Reservado. Não use.
5.2.2.3 Motivo de Rejeição (RR)
Tabela 5.2-11 Resposta FIRMWARE_UPDATE_OFFER - Layout do motivo da rejeição
resposta 
Tabela 5.2-12 Resposta FIRMWARE_UPDATE_OFFER - Bits do motivo da rejeição
Os bits do byte de Motivo de Rejeição são descritos nesta tabela.
| Deslocamento de bit | Campo | Tamanho | Descrição |
|---|---|---|---|
| 0 | Código RR | 8 | O Código de Motivo de Rejeição que indica o motivo fornecido pelo componente para rejeitar a oferta. Esse valor depende do campo Status. Para obter um mapeamento de status para código RR, consulte a Tabela 5.2-13. |
| 8 | Reservado | 24 | Reservado. Não use. |
Tabela 5.2-13 Valores do código RR da resposta FIRMWARE_UPDATE_OFFER
Os valores possíveis para o byte de código RR são descritos nesta tabela.
| Código RR | Nome | Descrição |
|---|---|---|
| 0x00 | FIRMWARE_OFFER_REJECT_OLD_FW | A oferta foi rejeitada porque a versão do firmware oferecido é mais antiga ou igual ao firmware atual. |
| 0x01 | FIRMWARE_OFFER_REJECT_INV_COMPONENT | A oferta foi rejeitada porque o firmware oferecido não é aplicável à plataforma do produto. Isso pode ser devido a uma ID de componente sem suporte ou a imagem oferecida não é compatível com o hardware do sistema. |
| 0x02 | FIRMWARE_UPDATE_OFFER SWAP_PENDING | O firmware do componente foi atualizado, no entanto, uma troca para o novo firmware está pendente. Nenhum processamento de Atualização de Firmware adicional pode ocorrer até que a troca seja concluída, normalmente por meio de uma redefinição. |
| 0x03 - 0x08 | (Reservado) | Reservado. Não use. |
| 0x09 - 0xDF | (Reservado) | Reservado. Não use. |
| 0xE0 - 0xFF | (Específico do fornecedor) | Esses valores são usados pelos designers do protocolo e o significado é específico do fornecedor. |
5.2.2.4 Status
Tabela 5.2-14 Layout do status da resposta FIRMWARE_UPDATE_OFFER
Layout de Status de Resposta 
Os bits do byte de Status são descritos nesta tabela.
Tabela 5.2-15 Resposta FIRMWARE_UPDATE_OFFER - Bits de status
| Deslocamento de bit | Campo | Tamanho | Descrição |
|---|---|---|---|
| 0 | Estado | 8 | Esse valor indica a decisão do componente de aceitar, suspender, ignorar ou rejeitar a oferta. O componente fornece o motivo para o valor do campo de código RR. Para obter um mapeamento de status para código RR, consulte a Tabela 5.2-16. |
| 8 | Reservado | 24 | Reservado. Não use. |
Os valores possíveis para o byte de Status são descritos nesta tabela.
Tabela 5.2-16 Valores de Status de Resposta FIRMWARE_UPDATE_OFFER
| Estado | Nome | Descrição |
|---|---|---|
| 0x00 | FIRMWARE_UPDATE_OFFER_SKIP | O componente decidiu ignorar a oferta. O anfitrião deve oferecê-lo novamente mais tarde. |
| 0x01 | FIRMWARE_UPDATE_OFFER_ACCEPT | O componente decidiu aceitar a oferta. |
| 0x02 | FIRMWARE_UPDATE_OFFER_REJECT | O componente decidiu rejeitar a oferta. |
| 0x03 | FIRMWARE_UPDATE_OFFER_BUSY | O dispositivo está ocupado e o host deve aguardar até que o dispositivo esteja pronto. |
| 0x04 | FIRMWARE_UPDATE_OFFER_COMMAND | Usado quando a ID do Componente nos bytes de Informações do Componente (consulte 5.1.2.1.1 Informações do Componente) é definida como 0xFE. Para o código de comando definido como solicitação OFFER_NOTIFY_ON_READY, indica que o acessório está pronto para aceitar ofertas adicionais. |
| 0xFF | FIRMWARE_UPDATE_CMD_NOT_SUPPORTED | A solicitação de oferta não é reconhecida. |
5.2.3 Mapeamento para o protocolo HID
A mensagem é emitida para o componente através do mecanismo Relatório de saída HID usando a ID de relatório do utilitário HID dedicado para atualização de firmware. O TLC do Utilitário HID a ser utilizado é descrito no Apêndice.
5.3 FIRMWARE_UPDATE_OFFER – Informações
Se o ID do Componente nos bytes de Informações do Componente (consulte Informações do Componente) estiver definido como 0xFF, então os 15 bytes serão redefinidos para indicar apenas Informações da Oferta, do Host para o componente. Esse mecanismo permite extensibilidade e uma maneira de o Host fornecer informações específicas ao dispositivo, como Iniciar Lista de Ofertas, Lista de Ofertas Finais, Iniciar Transação Inteira. Os pacotes de Informações da Oferta são sempre aceitos imediatamente pelo componente.
Comando 5.3.1
O pacote de comando FIRMWARE_UPDATE_OFFER -Information é definido da seguinte maneira:
Tabela 5.3-1 FIRMWARE_UPDATE_OFFER – Layout do Comando de Informações
Componente 5.3.1.1
Tabela 5.3-2 FIRMWARE_UPDATE_OFFER – Comando de Informações – Layout do Componente
Os bits do byte de componente são descritos nesta tabela.
Tabela 5.3-3 FIRMWARE_UPDATE_OFFER - Comando de informações - Bits de componentes
| Deslocamento de bit | Campo | Tamanho | Descrição |
|---|---|---|---|
| 0 | Código de informações | 8 | Esse valor indica o tipo de informação. Esse valor não é uma máscara de bits e pode ser apenas um dos valores possíveis descritos na Tabela 5.3-4. |
| 8 | Reservado. | 8 | Reservado. Não use. |
| 16 | ID do componente | 8 | Definido como 0xFF. |
| 24 | Símbolo | O anfitrião insere um token exclusivo no pacote de oferta para o componente. Esse token deve ser retornado pelo componente na resposta da oferta. |
Tabela 5.3-4 FIRMWARE_UPDATE_OFFER – Comando de informações – Valores de código de informações
| Estado | Nome | Descrição |
|---|---|---|
| 0x00 | OFFER_INFO_START_ENTIRE_TRANSACTION | Indica que o servidor é novo ou foi reinicializado, e todo o processamento da oferta está (re)iniciando. |
| 0x01 | OFFER_INFO_START_OFFER_LIST | Indica o início da lista de ofertas do host caso o Acessório tenha regras de download associadas à garantia de que um subcomponente seja atualizado antes de outro subcomponente no sistema. |
| 0x02 | OFFER_INFO_END_OFFER_LIST | Indica o final da lista de ofertas do host. |
5.3.1.2 Reservado B7 - B4
Reservado. Não use.
5.3.1.3 Reservado B11 - B8
Reservado. Não use.
5.3.1.4 Reservado B15 - B12
Reservado. Não use.
Resposta 5.3.2
A resposta do pacote FIRMWARE_UPDATE_OFFER – A resposta do pacote Resposta de informações da oferta é definida da seguinte forma.
Tabela 5.3-5 FIRMWARE_UPDATE_OFFER - Layout da resposta de informações
5.3.2.1 Token
Tabela 5.3-6 FIRMWARE_UPDATE_OFFER - Layout do token de resposta do pacote de informações
Os bits do byte de Token são descritos nesta tabela.
Tabela 5.3-7 FIRMWARE_UPDATE_OFFER - Resposta de informações - Bits de token
| Deslocamento de bit | Campo | Tamanho | Descrição |
|---|---|---|---|
| 0 | Reservado | 8 | Reservado. Não use. |
| 8 | Reservado | 8 | Reservado. Não use. |
| 16 | Reservado | 8 | Reservado. Não use. |
| 24 | Símbolo | 8 | Token para identificar o host |
5.3.2.2 Reservado B7 - B4
Reservado. Não use.
5.3.2.3 Motivo de Rejeição (RR)
Tabela 5.3-8 FIRMWARE_UPDATE_OFFER - Resposta de informações - Layout do código RR
Os bits do byte 'Motivo de Rejeição' são descritos nesta tabela.
Tabela 5.3-9 FIRMWARE_UPDATE_OFFER - Resposta de informações da oferta - Bits do código RR
| Deslocamento de bit | Campo | Tamanho | Descrição |
|---|---|---|---|
| 0 | Código RR | 8 | O Código de Motivo de Rejeição que indica o motivo fornecido pelo componente para rejeitar a oferta. Os valores possíveis são descritos na Tabela 5.3-10. Esse valor depende do campo Status. |
| 8 | Reservado | 24 | Reservado. Não use. |
Os valores possíveis para o byte de código RR são descritos nesta tabela.
Tabela 5.3-10 FIRMWARE_UPDATE_OFFER- Resposta de informações - Valores do código RR
| Código RR | Nome | Descrição |
|---|---|---|
| 0x00 | FIRMWARE_OFFER_REJECT_OLD_FW | A oferta foi rejeitada porque a versão do firmware oferecido é mais antiga ou igual ao firmware atual. |
| 0x01 | FIRMWARE_OFFER_REJECT_INV_COMPONENT | A oferta foi rejeitada porque o firmware oferecido não é aplicável à plataforma do produto. Isso pode ser devido a uma ID de componente sem suporte ou a imagem oferecida não é compatível com o hardware do sistema. |
| 0x02 | FIRMWARE_UPDATE_OFFER SWAP_PENDING | O firmware do componente foi atualizado, no entanto, uma troca para o novo firmware está pendente. Nenhum processamento de Atualização de Firmware adicional pode ocorrer até que a troca seja concluída, normalmente por meio de uma redefinição. |
| 0x03 - 0x08 | (Reservado) | Reservado. Não use. |
| 0x09 - 0xDF | (Reservado) | Reservado. Não use. |
| 0xE0 — 0xFF | (Específico do fornecedor) | Esses valores são usados pelos designers do protocolo e o significado é específico do fornecedor. |
5.3.2.4 Status
Tabela 5.3-11 FIRMWARE_UPDATE_OFFER - Layout do status da resposta de informações da oferta
Os bits do byte de Status são descritos nesta tabela.
Tabela 5.3-12 FIRMWARE_UPDATE_OFFER - Informações da oferta - Bits de status da resposta
| Deslocamento de bit | Campo | Tamanho | Descrição |
|---|---|---|---|
| 0 | Estado | 8 | Esse campo deve ser definido como FIRMWARE_UPDATE_OFFER_ACCEPT. Isso indica que o componente decidiu aceitar a oferta. |
| 8 | Reservado. | 24 | Reservado. Não use. |
5.4 FIRMWARE_UPDATE_OFFER - Estendido
Se a ID do componente nos bytes de Informações do Componente estiver definida como 0xFE, os bits (15 bytes) serão redefinidos para indicar o Comando de Oferta do host para o firmware do dispositivo. Esse mecanismo permite extensibilidade e uma maneira de o host fornecer informações específicas ao dispositivo. Os Pacotes do comando de Oferta são retornados quando o componente está pronto para responder com Aceito.
Comando 5.4.1
Se a ID do componente nos bytes de Informações do Componente estiver definida como 0xFE, os quatro DWORDs serão redefinidos da seguinte maneira:
Tabela 5.4-1 FIRMWARE_UPDATE_OFFER – Layout de Comando Estendido
Componente 5.4.1.1
Tabela 5.4-2 FIRMWARE_UPDATE_OFFER - Pacote do comando estendido - Comando - Layout do componente
Os bits do byte de componente são descritos nesta tabela.
Tabela 5.4-3 FIRMWARE_UPDATE_OFFER – Comando Estendido – Bits de componente
| Deslocamento de bit | Campo | Tamanho | Descrição |
|---|---|---|---|
| 0 | Código de comando | 8 | Esse valor indica o tipo de comando. Esse valor não é uma máscara de bits e só pode ser um dos valores possíveis descritos na Tabela 5.4-4. |
| 8 | Reservado. | 8 | Reservado. Não use. |
| 16 | ID do componente | 8 | Definido como 0xFE. |
| 24 | Símbolo | O host insere um token exclusivo no pacote de oferta destinado ao componente. Esse token deve ser retornado pelo componente na resposta da oferta. |
Tabela 5.4-4 FIRMWARE_UPDATE_OFFER – Comando Estendido – Valores de Código de Comando
| Estado | Nome | Descrição |
|---|---|---|
| 0x01 | OFFER_NOTIFY_ON_READY | Enviado pelo host se a oferta foi rejeitada anteriormente pelo componente. |
| 0x02 - 0xFF | Reservado | Reservado |
5.4.1.2 Reservado B7 - B4
Reservado. Não use.
5.4.1.3 Reservado B11 - B8
Reservado. Não use.
5.4.1.4 Reservado B15 - B12
Reservado. Não use.
Resposta 5.4.2
O comando FIRMWARE_UPDATE_OFFER - Oferta do dispositivo pode não ser recebido imediatamente. A resposta é definida da seguinte maneira.
Tabela 5.4-5 FIRMWARE_UPDATE_OFFER - Layout de resposta do pacote do comando estendido
5.4.2.1 Token
Tabela 5.4-6 FIRMWARE_UPDATE_OFFER- Resposta do pacote do comando da oferta - Layout do token
Os bits do byte de Token são descritos nesta tabela.
Tabela 5.4-7 FIRMWARE_UPDATE_OFFER – Resposta do comando da oferta – Bits de token
| Deslocamento de bit | Campo | Tamanho | Descrição |
|---|---|---|---|
| 0 | Reservado | 8 | Reservado. Não use. |
| 8 | Reservado | 8 | Reservado. Não use. |
| 16 | Reservado | 8 | Reservado. Não use. |
| 24 | Símbolo | 8 | Token para identificar o host. |
5.4.2.2 Reservado B7 - B4
Reservado. Não use.
5.4.2.3 Motivo de Rejeição
Tabela 5.4-8 FIRMWARE_UPDATE_OFFER – Layout RR de Resposta do Pacote de Informações da Oferta
Os bits do byte Motivo de Rejeição são descritos nesta tabela.
Tabela 5.4-9 FIRMWARE_UPDATE_OFFER - Resposta do comando de Oferta – Código RR
| Deslocamento de bit | Campo | Tamanho | Descrição |
|---|---|---|---|
| 0 | Código RR | 8 | Esse valor depende do campo Status. Para obter possíveis valores de código RR, consulte a Tabela 5.4-10. |
| 8 | Reservado | 24 | Reservado. Não use. |
Os valores possíveis para o byte de código RR são descritos nesta tabela.
Tabela 5.4-10 FIRMWARE_UPDATE_OFFER - Pacote do comando de Oferta – Valores de Código RR
| Código RR | Nome | Descrição |
|---|---|---|
| 0x00 | FIRMWARE_OFFER_REJECT_OLD_FW | A oferta foi rejeitada porque a versão do firmware oferecido é mais antiga ou igual ao firmware atual. |
| 0x01 | FIRMWARE_OFFER_REJECT_INV_COMPONENT | A oferta foi rejeitada porque o firmware oferecido não é aplicável à plataforma do produto. Isso pode ser devido a uma ID de componente sem suporte ou a imagem oferecida não é compatível com o hardware do sistema. |
| 0x02 | FIRMWARE_UPDATE_OFFER SWAP_PENDING | O firmware do componente foi atualizado, no entanto, uma troca para o novo firmware está pendente. Nenhum processamento de Atualização de Firmware adicional pode ocorrer até que a troca seja concluída, normalmente por meio de uma redefinição. |
| 0x03 - 0x08 | (Reservado) | Reservado. Não use. |
| 0x09 - 0xDF | (Reservado) | Reservado. Não use. |
| 0xE0 — 0xFF | (Específico do fornecedor) | Esses valores são usados pelos designers do protocolo e o significado é específico do fornecedor. |
5.4.2.4 Status
Tabela 5.4-11 FIRMWARE_UPDATE_OFFER - Layout do status da resposta do pacote do comando de oferta
Os bits do byte de Status são descritos nesta tabela.
Tabela 5.4-12 FIRMWARE_UPDATE_OFFER- Código RR da resposta do pacote do comando de oferta
| Deslocamento de bit | Campo | Tamanho | Descrição |
|---|---|---|---|
| 0 | Estado | 8 | Esse campo deve ser definido como FIRMWARE_UPDATE_OFFER_ACCEPT. Isso indica que o componente decidiu aceitar a oferta. |
| 8 | Reservado. | 24 | Reservado. Não use. |
5.5 FIRMWARE_UPDATE_CONTENT
O host envia esse comando para o firmware do dispositivo para fornecer o conteúdo do firmware (ou seja, a imagem de firmware). O arquivo de imagem inteiro não deve caber em um único comando. O host deve dividir a imagem em blocos menores e cada comando envia um bloco da imagem de cada vez.
Com cada comando, o host indica informações adicionais, seja o primeiro bloco, o último bloco e assim por diante, do firmware. O componente primário do firmware do dispositivo aceita cada bloco da imagem de firmware de entrada, armazena-a em sua memória e deve responder a cada comando individualmente.
Quando o componente primário recebe o último bloco, o componente valida toda a imagem de firmware (verificação crc, validação de assinatura). Com base nos resultados dessas verificações, retorna uma resposta apropriada (falha ou êxito) para o último bloco.
Comando 5.5.1
Tabela 5.5-1 Layout do comando FIRMWARE_UPDATE_CONTENT
Layout de Comando 
5.5.1.1 Cabeçalho (B7 - B0)
Tabela 5.5-2 Layout do cabeçalho do comando FIRMWARE_UPDATE_CONTENT
layout do cabeçalho de comando 
Os bits do cabeçalho FIRMWARE_UPDATE_CONTENT são descritos nesta tabela.
Tabela 5.5-3 Bits de cabeçalho FIRMWARE_UPDATE_CONTENT
| Deslocamento de bit | Campo | Tamanho | Descrição |
|---|---|---|---|
| 0 | Sinalizadores | 8 | Esse campo fornece informações extras sobre o comando. Esse valor é uma máscara de sinalizadores a ser usada para as transferências de dados. Os valores possíveis são descritos na Tabela 5.5-4. |
| 8 | Comprimento dos dados | 8 | O comprimento do campo Dados aplicável que indica o número de bytes a serem gravados. Considerando o tamanho desse comando, o valor máximo permitido para o comprimento é 52 bytes. |
| 16 | Número de Sequência | 16 | Esse valor é criado pelo host e é exclusivo para cada pacote de conteúdo emitido. O componente deve retornar o número de sequência em sua resposta a essa solicitação. |
| 32 | Endereço de firmware | 32 | Endereço para escrever os dados no formato Little Endian (LSB First). O endereço é baseado em 0. O firmware usa isso como referência para determinar o endereço conforme necessário ao colocar a imagem na memória. |
Os valores possíveis para o byte de Flags são descritos nesta tabela.
Tabela 5.5-4 FIRMWARE_UPDATE_OFFER- Pacote do comando de oferta – Valores de sinalizador
| Bandeira | Nome | Descrição |
|---|---|---|
| 0x80 | FIRMWARE_UPDATE_FLAG_FIRST_BLOCK | Esse sinalizador indica que este é o primeiro bloco da imagem de firmware. |
| 0x40 | FIRMWARE_UPDATE_FLAG_LAST_BLOCK | Esse sinalizador indica que este é o último bloco da imagem de firmware e que a imagem está pronta para ser validada. É importante que o firmware atual no componente execute a validação em toda a imagem de firmware baixada depois de gravar esse bloco em memória não volátil. |
5.5.1.2 Dados
Tabela 5.5-5 Layout de dados do cabeçalho do comando FIRMWARE_UPDATE_CONTENT
Os bits dos dados de FIRMWARE_UPDATE_CONTENT são descritos nesta tabela.
Tabela 5.5-6 Bits de dados do comando de FIRMWARE_UPDATE_CONTENT
| Deslocamento de bit | Campo | Tamanho | Descrição |
|---|---|---|---|
| 64 | Dados | Máx 52. | A matriz de bytes para gravação. O host normalmente envia blocos de 4 bytes com base na arquitetura do produto. Todos os bytes não utilizados no final devem ser preenchidos com zero. |
Resposta 5.5.2
Tabela 5.5-7 Layout da resposta do comando FIRMWARE_UPDATE_CONTENT
5.5.2.1 Número de sequência
Tabela 5.5-8 Resposta de FIRMWARE_UPDATE_CONTENT – Número de Sequência
Os bits da resposta FIRMWARE_UPDATE_CONTENT (3-0) são descritos nesta tabela.
Tabela 5.5-9 FIRMWARE_UPDATE_CONTENT - Comando - Bits de resposta
| Deslocamento de bit | Campo | Tamanho | Descrição |
|---|---|---|---|
| 0 | Número de Sequência | 16 | Esse campo é o número de sequência que foi enviado pelo host na solicitação. |
| 16 | Reservado | 16 | Reservado. Não use. |
5.5.2.2 Status
Tabela 5.5-10 Layout do status da resposta FIRMWARE_UPDATE_CONTENT
Os bits da resposta FIRMWARE_UPDATE_CONTENT (7-4) são descritos nesta tabela.
Tabela 5.5-11 FIRMWARE_UPDATE_OFFER - Resposta - Bits de status
| Deslocamento de bit | Campo | Tamanho | Descrição |
|---|---|---|---|
| 0 | Estado | 8 | Esse valor indica o código de status retornado pelo componente do dispositivo. Isto não é uma operação bit a bit e pode ser um dos valores descritos na Tabela 5.5-12. |
| 8 | Reservado | 24 | Reservado. Não use. |
Os valores possíveis para o byte de Status são descritos nesta tabela.
Tabela 5.5-12 FIRMWARE_UPDATE_OFFER - Resposta – Valores de códigos de status
| Bandeira | Nome | Descrição |
|---|---|---|
| 0x00 | ATUALIZAÇÃO_DE_FIRMWARE_CONCLUÍDA_COM_SUCESSO | A solicitação foi concluída com êxito. |
| 0x01 | FIRMWARE_UPDATE_ERROR_PREPARE | O componente não estava preparado para receber o conteúdo do firmware. Se usado, esse código normalmente é usado em uma resposta ao primeiro bloco. Por exemplo, apase o erro no flash. |
| 0x02 | FIRMWARE_UPDATE_ERROR_WRITE | A solicitação não conseguiu gravar os bytes. |
| 0x03 | FIRMWARE_UPDATE_ERROR_COMPLETE | A solicitação não pôde configurar o swap em resposta a FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
| 0x04 | FIRMWARE_UPDATE_ERROR_VERIFY | A verificação do DWORD falhou, em resposta a FIRMWARE_UPDATE_FLAG_VERIFY. |
| 0x05 | FIRMWARE_UPDATE_ERROR_CRC | O CRC da imagem de firmware falhou em resposta ao FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
| 0x06 | FIRMWARE_UPDATE_ERROR_SIGNATURE | Falha na verificação de assinatura do firmware em resposta a FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
| 0x07 | FIRMWARE_UPDATE_ERROR_VERSION | Falha na verificação da versão do firmware em resposta a FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
| 0x08 | FIRMWARE_UPDATE_SWAP_PENDING | O firmware já foi atualizado e uma troca está pendente. Nenhum comando de Atualização de Firmware adicional pode ser aceito até que o acessório tenha sido redefinido. |
| 0x09 | FIRMWARE_UPDATE_ERROR_INVALID_ADDR (Erro de atualização de firmware: endereço inválido) | O firmware detectou um endereço de destino inválido no conteúdo dos dados da mensagem. |
| 0x0A | FIRMWARE_UPDATE_ERROR_NO_OFFER | O Comando FIRMWARE_UPDATE_OFFER foi recebido sem receber primeiro uma oferta de atualização de firmware válida e aceita. |
| 0x0B | FIRMWARE_UPDATE_ERROR_INVALID | Erro geral para o comando FIRMWARE_UPDATE_OFFER, como um comprimento de dados aplicável inválido. |
5.5.2.3 Reservado B8 - B11
Reservado. Não use.
5.5.2.4 Reservado B12 - B15
Reservado. Não use.
6 Apêndice 1: Exemplo de sequência de comandos de programação de atualização de firmware
6.1 Exemplo 1
Considere o seguinte firmware de dispositivo:
Componente Primário – ID do componente 1 – Firmware atual versão 7.0.1
Subcomponente – ID do componente 2 – Firmware atual versão 12.4.54
Subcomponente – ID do componente 3 – Firmware atual versão 4.4.2
Subcomponente – ID do componente 4 – Firmware atual versão 23.32.9
O host tem estas três imagens de firmware:
ID do componente 1 – Firmware versão 7.1.3
ID do componente 2 – Firmware versão 12.4.54
ID do componente 3 – Firmware versão 4.5.0
A sequência será:
Ofertas do host: ID do componente 1 – Firmware versão 7.1.3
O componente primário aceita a oferta
O host envia a imagem de firmware
O componente primário aceita firmware, valida-o
Ofertas do host: ID do componente 2 – Firmware versão 12.4.54
O componente primário rejeita a oferta
Ofertas do host: ID do componente 3 – Firmware versão 4.5.0
O componente primário aceita a oferta
O host envia a imagem de firmware
O componente primário aceita firmware, valida-o
Como nem todas as ofertas foram rejeitadas, o anfitrião repete todas as ofertas:
Ofertas do host: Component ID 1 - Versão do firmware 7.1.3
Rejeições de componente
Ofertas do host: ID do componente 2 – Firmware versão 12.4.54
Rejeições de componente
Ofertas do host: ID do componente 3 – Firmware versão 4.5.0
Rejeições de componente
6.2 Exemplo 2
Considere o seguinte firmware de dispositivo:
Componente Primário – ID do componente 1 – Firmware atual versão 7.0.1
Subcomponente – ID do componente 2 – Firmware atual versão 12.4.54
Subcomponente – ID do componente 3 – Firmware atual versão 7.4.2
Subcomponente – ID do componente 4 – Firmware atual versão 23.32.9
O host tem estas três imagens de firmware:
ID do componente 1 – Firmware versão 8.0.0
ID do componente 2 – Firmware versão 12.4.54
ID do componente 3 – Firmware versão 9.0.0
Além disso, a implementação exige que a versão de firmware dos subcomponentes não seja menor do que a versão do firmware em execução no componente primário. O host não está ciente desse requisito e cabe ao componente principal garantir essa regra.
A sequência será:
Ofertas do host: ID do componente 1 – Firmware versão 8.0.0
O componente primário rejeita (porque a ID do componente 3 ainda não foi atualizada)
Ofertas do host: ID do componente 2 – Firmware versão 12.4.54
Rejeições do componente primário
Ofertas do host: ID do componente 3 – Firmware versão 9.0.0
Componente primário aceita oferta
O host envia a imagem de firmware
O componente primário aceita firmware, valida-o
Como nem todas as ofertas foram rejeitadas, o anfitrião repete todas as ofertas
Ofertas do host: ID do componente 1 – Firmware versão 8.0.0
Componente primário aceita oferta
O host envia a imagem de firmware
O componente primário aceita firmware, valida-o
Ofertas do host: ID do componente 2 – Firmware versão 12.4.54
Rejeições do componente primário
Ofertas do host: Componente ID 3 – Versão de firmware 9.0.0
Rejeições do componente primário