Especificação do protocolo CFU (Component Firmware Update)
Esta 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.
Observação
O CFU está disponível em Windows 10, versão 2004 (atualização de maio de 2020 Windows 10) e versões posteriores.
Sumário
- 1 Introdução
- 2 Arquitetura de hardware com suporte
- 3 Pré-requisitos de protocolo
- Visão geral do protocolo CFU 4
- 4.1 Sequência de comandos de programação de atualização de firmware
- Estado 4.1.1: Notificação inicializada do host
- Estado 4.1.2: notificação de OFFER_INFO_START_OFFER_LIST
- Estado 4.1.3: Comando Enviar FIRMWARE_UPDATE_OFFER
- 4.1.4 Estado: Enviar firmware
- 4.1.5 Estado de decisão: há mais ofertas
- 4.1.6 Estado: notificação de OFFER_INFO_END_OFFER_LIST
- 4.1.7 Estado de decisão: Lista de ofertas de reprodução
- 4.1.8 Estado: o dispositivo está ocupado
- 4.1 Sequência de comandos de programação de atualização de firmware
- 5 Formato de pacote de protocolo CFU
- 6 Apêndice 1: Exemplo de sequência de comandos de programação de atualização de firmware
Tabelas
Tabela 5.1-1 GET_FIRMWARE_VERSION Layout de Resposta
Resposta de GET_FIRMWARE_VERSION da Tabela 5.1-2 – Layout do Cabeçalho
Resposta de GET_FIRMWARE_VERSION da Tabela 5.1-3 – Bits de cabeçalho
Resposta de GET_FIRMWARE_VERSION da Tabela 5.1-4 – Versão do Componente e Layout de Propriedades
Resposta de GET_FIRMWARE_VERSION da Tabela 5.1-5 – Bits de versão e propriedades do componente
Layout de comando da tabela 5.2-1 FIRMWARE_UPDATE_OFFER
Comando de FIRMWARE_UPDATE_OFFER da Tabela 5.2-2 – Layout de Informações do Componente
Comando de FIRMWARE_UPDATE_OFFER da Tabela 5.2-3 – Bits de Informações do Componente
Comando de FIRMWARE_UPDATE_OFFER da Tabela 5.2-4 – Layout da Versão do Firmware
Comando de FIRMWARE_UPDATE_OFFER da Tabela 5.2-5 – Bits de versão do firmware
Comando de FIRMWARE_UPDATE_OFFER da Tabela 5.2-6 – Layout específico do fornecedor
Tabela 5.2-7 FIRMWARE_UPDATE_OFFER Command – Versão misc. e Protocol
Tabela 5.2-8 FIRMWARE_UPDATE_OFFER Layout do Token de Resposta
Resposta de FIRMWARE_UPDATE_OFFER da Tabela 5.2-9 – Layout do Token
Resposta de FIRMWARE_UPDATE_OFFER da Tabela 5.2-10 – Bits de token
Resposta de FIRMWARE_UPDATE_OFFER da Tabela 5.2-11 – Rejeitar Layout do Motivo
Resposta de FIRMWARE_UPDATE_OFFER da Tabela 5.2-12 – Rejeitar bits de motivo
Tabela 5.2-13 FIRMWARE_UPDATE_OFFER valores de código RR de resposta
Tabela 5.2-14 FIRMWARE_UPDATE_OFFER Layout de Status de Resposta
Tabela 5.2-15 FIRMWARE_UPDATE_OFFER Resposta – Bits de status
Valores de status de resposta da tabela 5.2-16 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 componente
Tabela 5.3-4 FIRMWARE_UPDATE_OFFER – Comando de Informações – Valores de código de informação
Tabela 5.3-5 FIRMWARE_UPDATE_OFFER – Layout de 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 às informações – Bits de token
Tabela 5.3-8 FIRMWARE_UPDATE_OFFER – Resposta às informações – Layout de código RR
Tabela 5.3-9 FIRMWARE_UPDATE_OFFER- Resposta de informações da oferta – Bits de código RR
Tabela 5.3-10 FIRMWARE_UPDATE_OFFER- Resposta de informações – Valores de código RR
Tabela 5.3-11 FIRMWARE_UPDATE_OFFER – Layout de status de resposta de informações da oferta
Tabela 5.3-12 FIRMWARE_UPDATE_OFFER - Informações da oferta - Bits de status de resposta
Tabela 5.4-1 FIRMWARE_UPDATE_OFFER – Layout de Comando Estendido
Tabela 5.4-2 FIRMWARE_UPDATE_OFFER – Pacote de 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 de código de comando
Tabela 5.4-5 FIRMWARE_UPDATE_OFFER – Layout de resposta de pacote de comando estendido
Tabela 5.4-6 FIRMWARE_UPDATE_OFFER- Resposta de pacote de comando de oferta – Layout do token
Tabela 5.4-7 FIRMWARE_UPDATE_OFFER – Resposta de comando de oferta – Bits de token
Tabela 5.4-8 FIRMWARE_UPDATE_OFFER – Layout RR de resposta de pacote de informações da oferta
Tabela 5.4-9 FIRMWARE_UPDATE_OFFER- Resposta de comando de oferta – Código RR
Tabela 5.4-10 FIRMWARE_UPDATE_OFFER- Pacote de Comando de Oferta – Valores de código RR
Tabela 5.4-11 FIRMWARE_UPDATE_OFFER – Layout de status de resposta de pacote de comando de oferta
Tabela 5.4-12 FIRMWARE_UPDATE_OFFER- Código RR de resposta de pacote de comando de oferta
Tabela 5.5-1 FIRMWARE_UPDATE_CONTENT Layout de Comando
Tabela 5.5-2 FIRMWARE_UPDATE_CONTENT layout de cabeçalho de comando
Tabela 5.5-3 FIRMWARE_UPDATE_CONTENT bits de cabeçalho
Tabela 5.5-4 FIRMWARE_UPDATE_OFFER- Pacote de Comando de Oferta – Valores de sinalizador
Tabela 5.5-5 FIRMWARE_UPDATE_CONTENT Layout de Dados de Comando
Tabela 5.5-6 FIRMWARE_UPDATE_CONTENT bits de dados de comando
Tabela 5.5-7 FIRMWARE_UPDATE_CONTENT layout de resposta de comando
Tabela 5.5-8 FIRMWARE_UPDATE_CONTENT Resposta – Número da Sequência
Tabela 5.5-9 FIRMWARE_UPDATE_CONTENT – Comando – Bits de resposta
Tabela 5.5-10 FIRMWARE_UPDATE_CONTENT Layout de Status de Resposta
Tabela 5.5-11 FIRMWARE_UPDATE_OFFER – Resposta – Bits de status
Tabela 5.5-12 FIRMWARE_UPDATE_OFFER- Resposta – Valores de 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 com frequência 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 uma 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 em 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.
Observação
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 aguardar a conclusão do processo de atualização de firmware 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 um 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.
Observação
O processo de um componente que entrega o firmware para o subcomponente está fora do escopo dessa especificação.
A especificação dá suporte ao conceito de uma oferta e depende do componente no comando para decidir se deseja 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 for capaz /ready de aceitá-la.
1.1 Glossário
| Termo | 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 um marcar 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. |
| Driver | 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 de silício físico no computador. |
| Componente primário | Uma parte do 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 criptográfico significa determinar se a imagem de firmware foi alterada por meios não autorizados. As assinaturas são opcionais, mas recomendadas e além do escopo dessa especificação. |
| Subcomponente | Dependendo da arquitetura de hardware, nem todos os componentes podem estar visíveis para o sistema operacional, pois eles podem estar conectados downstream de um componente visível para o sistema. Esses componentes são chamados de subcomponentes nessa especificação. |
| TLC | Coleção de nível superior hid. |
| Token | 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 que uma sessão foi perdida e outra iniciada. |
Escopo 1.2
1.2.1 Goals
Uma solução independente de ônibus é necessária para evitar um novo protocolo para cada tipo de ônibus. HID é onipresente e atende a esse requisito.
A capacidade de dar suporte à atualização de firmware para um dispositivo multicomponente, 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 para os 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/reverter o firmware em dispositivos de produção por meio de ferramentas autorizadas e atualizar dispositivos no mercado por meio de Windows Update.
A flexibilidade para dar suporte ao firmware/firmware no mercado em desenvolvimento.
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 Não Goals
Definir 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.
Definir 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 do subcomponente.
2 Arquitetura de hardware com suporte
Para dar suporte a um design de hardware flexível, o protocolo dá suporte a um dispositivo multicomponente em que cada componente requer sua própria imagem de firmware. No design, um componente é o componente primário e os subcomponentes dependentes estão conectados a esse componente primário. Cada componente é descrito exclusivamente por uma ID de componente.
O dispositivo multicomponentes é 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 melhores práticas que devem ser implementados para aproveitar esse 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 em vigor para evitar um download repetido em caso de erros de transporte.
A atualização de 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 que os fatores que constituem uma imagem de firmware autêntica. É recomendável que o firmware atual do componente precise 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. Recuperação de falha
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 da 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 ele ser criptografado.
Proteção contra reversão
As políticas de reversão são impostas pelo componente primário e são específicas da implementação. O firmware atual no componente valida imagens de firmware de entrada em relação a políticas internas, como o número de 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 o sistema de mensagens indique que uma atualização é aceita mesmo que esteja violando políticas de reversão.
Visão geral do protocolo CFU 4
O protocolo CFU é um conjunto de comandos e respostas 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 por todas as imagens de firmware a serem enviadas para o dispositivo. Para cada imagem de firmware, o host oferece o envio do 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 reenviar 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 do CFU para atualizar a imagem de firmware.
Estado 4.1.1: Notificação inicializada 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 agora está 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 este comando com êxito.
Estado 4.1.2: notificação de 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 principal do dispositivo deve concluir este comando com êxito.
Esse comando é útil porque o host pode enviar todas as ofertas para o dispositivo mais de uma vez.
4.1.3 Estado: comando Enviar FIRMWARE_UPDATE_OFFER
O host envia uma oferta para o componente primário (ou seu subcomponente) para marcar se o componente quiser aceitar/rejeitar o firmware. A oferta contém todos os metadados necessários sobre a imagem de firmware, para que o firmware atual no componente possa decidir se aceita, aguarda, 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 em 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 primário ainda poderá rejeitar a imagem de firmware após o download por falha de integridade e/ou verificações de reversão em relação à imagem real recebida. O componente deve marcar cada propriedade de imagem de firmware independente 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, com FIRMWARE_UPDATE_OFFER_ACCEPT status aceitando a oferta.
Se o firmware do dispositivo estiver ocupado e o componente primário não puder 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, no entanto, não poderá aceitar a oferta (por exemplo, devido a uma dependência de uma atualização ausente para o subcomponente), ele responderá com um FIRMWARE_UPDATE_OFFER_SKIP indicando que ele está interessado nesse firmware, no entanto, não pode aceitá-la. Em seguida, o host prossegue para a próxima oferta e deverá oferecer esse firmware novamente mais tarde.
Se o firmware atual não estiver interessado na oferta (por exemplo, é uma versão mais antiga), ele responderá com um FIRMWARE_UPDATE_OFFER_REJECT status 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 sempre que inicializa ou reenvia a lista de ofertas para o dispositivo (consulte Estado: OFFER_INFO_START_OFFER_LIST Notificação).
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 CONTENT FIRMWARE_UPDATE separado. O componente primário deve gerar um pacote de resposta para cada comando.
Cada comando content FIRMWARE_UPDATE descreve um endereço de deslocamento que inclui um conteúdo de firmware parcial. O componente usa o deslocamento para determinar o endereço em que o conteúdo do firmware parcial deve ser armazenado. 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, o host envia, ele define o sinalizador FIRMWARE_UPDATE_FLAG_LAST_BLOCK.
Depois que o firmware atual no dispositivo tiver gravado o conteúdo do firmware parcial incluído neste comando, ele deverá executar verificações de validação e autenticação na imagem de firmware de entrada antes de enviar uma resposta. Isso inclui minimamente:
Um CRC marcar para verificar a integridade de toda a imagem de firmware.
Se o CRC marcar for bem-sucedido, a verificação opcional de uma assinatura da imagem de entrada.
Após a assinatura opcional marcar, uma versão marcar 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 redefinição e relatará êxito ao host. Normalmente, o componente não inicia uma auto-redefinição. 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 deverá 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.
Estado 4.1.6: notificação de 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: Lista de ofertas de reprodução
O host 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 repetir a lista de ofertas novamente.
Pode haver outra lógica específica de implementação que pode resultar em uma decisão de reproduzir a lista de ofertas.
4.1.8 Estado: 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 conjunto de comandos e respostas. O protocolo é sequencial por natureza. Para cada comando que o host envia para 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 reter uma oferta com base na resposta recebida do componente primário sobre as informações de versão consultadas. As informações se tornaram detectáveis para registro em log 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.
5.1.2 Resposta
O componente responde com a versão do 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).
Tabela 5.1-1 GET_FIRMWARE_VERSION Layout de Resposta
Cabeçalho 5.1.2.1
Resposta de GET_FIRMWARE_VERSION da Tabela 5.1-2 – Layout do cabeçalho
O cabeçalho da resposta fornece as informações a seguir.
Tabela 5.1-3 GET_FIRMWARE_VERSION Resposta – Bits de cabeçalho
| Deslocamento de bits | Campo | Tamanho | Descrição |
|---|---|---|---|
| 0 | Contagem de componentes | 8 | O número de componentes baixáveis 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 caber dentro dos 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 de atualização de firmware representam que a revisão do Protocolo de Atualização FW está sendo usada no transporte. Para a interface definida aqui, a Revisão de Atualização FW 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 gancho de protocolo futuro para permitir que componentes adicionais sejam relatados. |
5.1.2.2 Versão e propriedades do componente
Para cada componente, dois DWORDs são usados para descrever as propriedades do componente 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.
Resposta de GET_FIRMWARE_VERSION da Tabela 5.1-4 – Versão do componente e layout de propriedades
Cada informação específica do componente é descrita em dois DWORDs da seguinte maneira:
Resposta de GET_FIRMWARE_VERSION da Tabela 5.1-5 – Mordidas de versão e propriedades do componente
| Deslocamento de bits | 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 | Bank | 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ífico do fornecedor | 4 | Campo específico do fornecedor que pode ser usado de maneira específica da implementação. Um fornecedor pode usar esses bits para codificar informações como: - Tipo de firmware: pré-lançamento/auto-host/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ífico do fornecedor | 16 | Campo específico do fornecedor que pode ser usado de maneira específica da implementação. |
5.1.3 Mapeamento para HID
Isso é implementado como uma solicitação obter recurso hid 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 FIRMWARE_UPDATE_OFFER
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 comando FIRMWARE_UPDATE_OFFER é definido da seguinte maneira.
Tabela 5.2-1 FIRMWARE_UPDATE_OFFER Layout de Comando
5.2.1.1 Informações do componente
Comando de FIRMWARE_UPDATE_OFFER da Tabela 5.2-2 – Layout de Informações do Componente
Os bits do byte informações do componente são descritos nesta tabela.
Comando de FIRMWARE_UPDATE_OFFER da Tabela 5.2-3 – Bits de informações do componente
| Deslocamento de bits | 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 segmento i-th 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 Redefinição Imediata (I) - Esse valor de bit é usado para indicar ao componente para redefinir-se imediatamente depois que o download do firmware for concluído e verificado para invocá-lo imediatamente. - Esse sinalizador destina-se à fase de desenvolvimento. |
| 15 | V | 1 | Forçar Ignorar Versão (V) - Esse sinalizador destina-se à imagem de firmware de pré-lançamento ou depuração. Ele indica ao componente para não rejeitar o firmware com base na versão do firmware. - Esse 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 FIRMWARE_UPDATE_OFFER Informações para obter detalhes. 0xFE : a oferta é um pacote de comando de oferta especial. Consulte FIRMWARE_UPDATE_OFFER seção Estendida para obter detalhes. |
| 24 | Token | 8 | O host insere um token exclusivo no pacote de oferta ao componente. Esse token deve ser retornado pelo componente 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 da implementação. Por exemplo, um valor pode ser usado para um driver e outro para o aplicativo. Isso permite que o firmware do 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. |
5.2.1.2 Versão do firmware
Esses quatro bytes representam a versão de 32 bits do firmware. O formato para a versão do firmware não é exigido por essa especificação. A seguir, é recomendável.
Comando de FIRMWARE_UPDATE_OFFER da Tabela 5.2-4 – Layout da Versão do Firmware
O formato para a versão do firmware não é exigido por essa especificação, no entanto, a seguir está uma diretriz recomendada.
Comando de FIRMWARE_UPDATE_OFFER da Tabela 5.2-5 – Bits de versão do firmware
| Deslocamento de bits | Campo | Tamanho | Descrição |
|---|---|---|---|
| 0 | Variante | 8 | Esse campo pode ser descrito para distinguir entre um firmware de pré-lançamento e 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 Misc. e Versão do protocolo
Esses quatro bytes podem ser usados para codificar qualquer informação personalizada na oferta específica à implementação do fornecedor.
Comando de FIRMWARE_UPDATE_OFFER da Tabela 5.2-6 – Layout específico do fornecedor
Os bits do byte Específico do Fornecedor são descritos nesta tabela.
Tabela 5.2-7 FIRMWARE_UPDATE_OFFER Command – Versão misc. e Protocol
| Deslocamento de bits | 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ífico do fornecedor | 16 | Esse campo pode ser usado para codificar qualquer informação personalizada na oferta específica à implementação do fornecedor. |
5.2.2 Resposta
O pacote de resposta FIRMWARE_UPDATE_OFFER é definido da seguinte maneira.
Tabela 5.2-8 FIRMWARE_UPDATE_OFFER Layout do Token de Resposta
Token 5.2.2.1
Resposta de FIRMWARE_UPDATE_OFFER da Tabela 5.2-9 – Layout do Token
Os bits do byte de Token são descritos nesta tabela.
Resposta de FIRMWARE_UPDATE_OFFER da Tabela 5.2-10 – Bits de token
| Deslocamento de bits | 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 | Token | 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)
Resposta de FIRMWARE_UPDATE_OFFER da Tabela 5.2-11 – Rejeitar Layout do Motivo
Resposta de FIRMWARE_UPDATE_OFFER da Tabela 5.2-12 – Rejeitar bits de motivo
Os bits do byte Rejeitar Motivo são descritos nesta tabela.
| Deslocamento de bits | 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 Tabela 5.2-13. |
| 8 | Reservado | 24 | Reservado. Não use. |
Tabela 5.2-13 FIRMWARE_UPDATE_OFFER valores de código RR de resposta
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 adicional de Atualização de Firmware 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 FIRMWARE_UPDATE_OFFER Layout de Status de Resposta
Os bits do byte status são descritos nesta tabela.
Resposta de FIRMWARE_UPDATE_OFFER da Tabela 5.2-15 – Bits de Status
| Deslocamento de bits | Campo | Tamanho | Descrição |
|---|---|---|---|
| 0 | Status | 8 | Esse valor indica a decisão do componente de aceitar, pendente, ignorar ou rejeitar a oferta. O componente fornece o motivo pelo qual o no valor do campo Código RR. Para obter um mapeamento de status para código RR, consulte Tabela 5.2-16. |
| 8 | Reservado | 24 | Reservado. Não use. |
Os valores possíveis para o byte status são descritos nesta tabela.
Tabela 5.2-16 FIRMWARE_UPDATE_OFFER valores de status de resposta
| Status | Nome | Descrição |
|---|---|---|
| 0x00 | FIRMWARE_UPDATE_OFFER_SKIP | O componente decidiu ignorar a oferta. O host 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 Código de Comando definido como OFFER_NOTIFY_ON_READY solicitação, 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 por meio do mecanismo de Relatório de Saída HID , usando a ID de Relatório do Utilitário HID dedicada para Atualização de Firmware. O TLC do Utilitário HID a ser usado descrito no Apêndice.
5.3 FIRMWARE_UPDATE_OFFER - Informações
Se a ID do componente nos bytes de Informações do Componente (consulte Informações do Componente) estiver definida como 0xFF, os bits (15 bytes) serão redefinidos para indicar Somente Informações da Oferta, do Host ao componente. Esse mecanismo permite extensibilidade e uma maneira de o Host fornecer informações específicas para o 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 FIRMWARE_UPDATE_OFFER -Information Command é 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 do componente são descritos nesta tabela.
Tabela 5.3-3 FIRMWARE_UPDATE_OFFER – Comando de Informações – Bits de componente
| Deslocamento de bits | 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 só pode ser um dos valores possíveis descritos na Tabela 5.3-4. |
| 8 | Reservado. | 8 | Reservado. Não use. |
| 16 | ID do componente | 8 | Defina como 0xFF. |
| 24 | Token | O host insere um token exclusivo no pacote de oferta ao 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ção
| Status | Nome | Descrição |
|---|---|---|
| 0x00 | OFFER_INFO_START_ENTIRE_TRANSACTION | Indica que o host é novo ou foi recarregado e todo o processamento da oferta está (re)iniciando. |
| 0x01 | OFFER_INFO_START_OFFER_LIST | Indica o início da lista Oferta 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 Oferta 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.
5.3.2 Resposta
A resposta do pacote FIRMWARE_UPDATE_OFFER – Resposta às Informações da Oferta é definida da seguinte maneira.
Tabela 5.3-5 FIRMWARE_UPDATE_OFFER – Layout de resposta de informações
Token 5.3.2.1
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 às informações – Bits de token
| Deslocamento de bits | 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 | Token | 8 | Token para identificar o host |
5.3.2.2 Reservado B7 – B4
Reservado. Não use.
5.3.2.3 Rejeitar Motivo (RR)
Tabela 5.3-8 FIRMWARE_UPDATE_OFFER – Resposta às informações – Layout de código RR
Os bits do byte Rejeitar Motivo são descritos nesta tabela.
Tabela 5.3-9 FIRMWARE_UPDATE_OFFER- Resposta de informações da oferta – Bits de código RR
| Deslocamento de bits | Campo | Tamanho | Descrição |
|---|---|---|---|
| 0 | Código RR | 8 | O código rejeitar motivo 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 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 adicional de Atualização de Firmware 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 de status de resposta de informações da oferta
Os bits do byte status são descritos nesta tabela.
Tabela 5.3-12 FIRMWARE_UPDATE_OFFER - Informações da oferta - Bits de status de resposta
| Deslocamento de bits | Campo | Tamanho | Descrição |
|---|---|---|---|
| 0 | Status | 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 comando de oferta são retornados quando o componente está pronto para responder 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 de Comando Estendido – Comando – Layout do Componente
Os bits do byte do componente são descritos nesta tabela.
Tabela 5.4-3 FIRMWARE_UPDATE_OFFER – Comando Estendido – Bits de componente
| Deslocamento de bits | 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 | Defina como 0xFE. |
| 24 | Token | O host insere um token exclusivo no pacote de oferta 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
| Status | 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
A resposta FIRMWARE_UPDATE_OFFER - Comando de Oferta do dispositivo pode não ser recebida imediatamente. A resposta é definida da seguinte maneira.
Tabela 5.4-5 FIRMWARE_UPDATE_OFFER – Layout de resposta de pacote de comando estendido
Token 5.4.2.1
Tabela 5.4-6 FIRMWARE_UPDATE_OFFER- Resposta de pacote de comando de oferta – Layout do token
Os bits do byte de token são descritos nesta tabela.
Tabela 5.4-7 FIRMWARE_UPDATE_OFFER – Resposta de comando de oferta – Bits de token
| Deslocamento de bits | 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 | Token | 8 | Token para identificar o host. |
5.4.2.2 Reservado B7 – B4
Reservado. Não use.
5.4.2.3 Rejeitar motivo
Tabela 5.4-8 FIRMWARE_UPDATE_OFFER – Layout RR de resposta de pacote de informações da oferta
Os bits do byte Rejeitar Motivo são descritos nesta tabela.
Tabela 5.4-9 FIRMWARE_UPDATE_OFFER- Resposta de comando de oferta – Código RR
| Deslocamento de bits | 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 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 de 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 adicional de Atualização de Firmware 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 de status de resposta de pacote de comando de oferta
Os bits do byte status são descritos nesta tabela.
Tabela 5.4-12 FIRMWARE_UPDATE_OFFER- Código RR de resposta de pacote de comando de oferta
| Deslocamento de bits | Campo | Tamanho | Descrição |
|---|---|---|---|
| 0 | Status | 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). Não se espera que todo o arquivo de imagem se encaixe em um único comando. O host deve dividir a imagem em blocos menores e cada comando envia um bloco da imagem por 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 principal 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 (CRC marcar, 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 FIRMWARE_UPDATE_CONTENT Layout de Comando
Cabeçalho 5.5.1.1 (B7 – B0)
Tabela 5.5-2 FIRMWARE_UPDATE_CONTENT layout de cabeçalho de comando
Os bits do cabeçalho FIRMWARE_UPDATE_CONTENT são descritos nesta tabela.
Tabela 5.5-3 FIRMWARE_UPDATE_CONTENT bits de cabeçalho
| Deslocamento de bits | Campo | Tamanho | Descrição |
|---|---|---|---|
| 0 | Flags | 8 | Esse campo fornece informações extras sobre o comando . Esse valor é uma máscara de sinalizadores a serem usados 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. Dado o tamanho desse comando, o valor máximo permitido para o comprimento é de 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 do firmware | 32 | Endereço Little Endian (LSB First) para gravar os dados. O endereço é baseado em 0. O firmware usa isso como um deslocamento para determinar o endereço conforme necessário ao colocar a imagem na memória. |
Os valores possíveis para o byte flags são descritos nesta tabela.
Tabela 5.5-4 FIRMWARE_UPDATE_OFFER- Pacote de Comando de Oferta – Valores de sinalizador
| Sinalizador | Nome | Descrição |
|---|---|---|
| 0x80 | FIRMWARE_UPDATE_FLAG_FIRST_BLOCK | Esse sinalizador indica que esse é o primeiro bloco da imagem de firmware. |
| 0x40 | FIRMWARE_UPDATE_FLAG_LAST_BLOCK | Esse sinalizador indica que esse é 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 na memória não volátil. |
5.5.1.2 Dados
Tabela 5.5-5 FIRMWARE_UPDATE_CONTENT Layout de Dados de Comando
Os bits dos dados de FIRMWARE_UPDATE_CONTENT são descritos nesta tabela.
Tabela 5.5-6 FIRMWARE_UPDATE_CONTENT bits de dados de comando
| Deslocamento de bits | Campo | Tamanho | Descrição |
|---|---|---|---|
| 64 | Dados | Máximo de 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 0 acolchoados. |
5.5.2 Resposta
Tabela 5.5-7 FIRMWARE_UPDATE_CONTENT layout de resposta de comando
5.5.2.1 Número de sequência
Tabela 5.5-8 FIRMWARE_UPDATE_CONTENT Resposta – Número da Sequência
Os bits da resposta de FIRMWARE_UPDATE_CONTENT (3-0) são descritos nesta tabela.
Tabela 5.5-9 FIRMWARE_UPDATE_CONTENT – Comando – Bits de resposta
| Deslocamento de bits | 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 FIRMWARE_UPDATE_CONTENT Layout de Status de Resposta
Os bits da resposta de FIRMWARE_UPDATE_CONTENT (7-4) são descritos nesta tabela.
Tabela 5.5-11 FIRMWARE_UPDATE_OFFER - Resposta - Bits de Status
| Deslocamento de bits | Campo | Tamanho | Descrição |
|---|---|---|---|
| 0 | Status | 8 | Esse valor indica o código status retornado pelo componente do dispositivo. Isso nã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 status são descritos nesta tabela.
Tabela 5.5-12 FIRMWARE_UPDATE_OFFER- Resposta - Valores de código de status
| Sinalizador | Nome | Descrição |
|---|---|---|
| 0x00 | FIRMWARE_UPDATE_SUCCESS | 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 pôde gravar os bytes. |
| 0x03 | FIRMWARE_UPDATE_ERROR_COMPLETE | A solicitação não pôde configurar a troca em resposta a FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
| 0x04 | FIRMWARE_UPDATE_ERROR_VERIFY | Falha na verificação do DWORD em resposta a FIRMWARE_UPDATE_FLAG_VERIFY. |
| 0x05 | FIRMWARE_UPDATE_ERROR_CRC | Falha no CRC da imagem de firmware em resposta a FIRMWARE_UPDATE_FLAG_LAST_BLOCK. |
| 0x06 | FIRMWARE_UPDATE_ERROR_SIGNATURE | Falha na verificação da assinatura de 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 outro comando de Atualização de Firmware pode ser aceito até que o acessório seja redefinido. |
| 0x09 | FIRMWARE_UPDATE_ERROR_INVALID_ADDR | 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 de 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 de host: ID do componente 2 – Firmware versão 12.4.54
O componente primário rejeita a oferta
Ofertas de 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 todas as ofertas não foram rejeitadas, o host repete todas as ofertas:
Ofertas de host: ID do componente 1 – Firmware versão 7.1.3
Rejeições de componente
Ofertas de host: ID do componente 2 – Firmware versão 12.4.54
Rejeições de componente
Ofertas de 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 deve ser 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 primário garantir essa regra.
A sequência será:
Ofertas de host: ID do componente 1 – Firmware versão 8.0.0
Rejeições de componente primário (porque a ID do componente 3 ainda não foi atualizada)
Ofertas de host: ID do componente 2 – Firmware versão 12.4.54
Rejeições de componente primário
Ofertas de 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 e o valida
Como todas as ofertas não foram rejeitadas, o host reproduz todas as ofertas
Ofertas de 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 e o valida
Ofertas de host: ID do componente 2 – Firmware versão 12.4.54
Rejeições de componente primário
Ofertas de host: ID do componente 3 – Firmware versão 9.0.0
Rejeições de componente primário