Especificação do protocolo CFU (Component Firmware Update)

Esta especificação descreve um protocolo HID genérico para atualizar o firmware dos componentes presentes em um PC 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 suporta configurações em que o componente que aceita o firmware pode ter subcomponentes, que requerem 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 do firmware só é enviada para o componente se ele for capaz ou estiver pronto para aceitá-la.

Conteúdos

• 1 Introdução
  • 1.1 Glossário
  • 1.2 Âmbito de aplicação
    • 1.2.1 Objetivos
    • 1.2.2 Não Objetivos
• 2 Arquitetura de hardware suportada
• 3 Pré-requisitos do protocolo
• 4 Visão geral do protocolo CFU
  • 4.1 Sequência de Comandos de Programação de Atualização de Firmware
    • 4.1.1 Estado: Notificação inicializada do host
    • 4.1.2 Estado: OFFER_INFO_START_OFFER_LIST Notificação
    • 4.1.3 Estado: Enviar comando FIRMWARE_UPDATE_OFFER
    • 4.1.4 Estado: Enviar Firmware
    • 4.1.5 Estado da decisão: Existem mais ofertas
    • 4.1.6 Estado: OFFER_INFO_END_OFFER_LIST Notificação
    • 4.1.7 Estado da decisão: Lista de ofertas de repetição
    • 4.1.8 Estado: O dispositivo está ocupado
• Formato de pacote de protocolo CFU 5
  • 5.1 OBTER_VERSÃO_DO_FIRMWARE
    • 5.1.1 Comando
    • 5.1.2 Resposta
      • 5.1.2.1 Cabeçalho
      • 5.1.2.2 Versão e propriedades do componente
    • 5.1.3 Mapeamento para HID
  • 5.2 FIRMWARE_UPDATE_OFFER
    • 5.2.1 Comando
      • 5.2.1.1 Informações sobre componentes
      • 5.2.1.2 Versão do firmware
      • 5.2.1.3 Específico do fornecedor
      • 5.2.1.4 Versão diversa e protocolar
    • 5.2.2 Resposta
      • 5.2.2.1 Token
      • 5.2.2.2 Reservado (B7 - B4)
      • 5.2.2.3 Motivo de rejeição (RR)
      • 5.2.2.4 Situação
    • 5.2.3 Mapeamento para o protocolo HID
  • 5.3 FIRMWARE_UPDATE_OFFER - Informação
    • 5.3.1 Comando
      • 5.3.1.1 Componente
      • 5.3.1.2 Reservado B7 - B4
      • 5.3.1.3 Reservado B11 - B8
      • 5.3.1.4 Reservado B15 - B12
    • 5.3.2 Resposta
      • 5.3.2.1 Token
      • 5.3.2.2 Reservado B7 - B4
      • 5.3.2.3 Motivo de rejeição (RR)
      • 5.3.2.4 Situação
  • 5.4 FIRMWARE_UPDATE_OFFER - Ampliado
    • 5.4.1 Comando
      • 5.4.1.1 Componente
      • 5.4.1.2 Reservado B7 - B4
      • 5.4.1.3 Reservado B11 - B8
      • 5.4.1.4 Reservado B15 - B12
    • 5.4.2 Resposta
      • 5.4.2.1 Token
      • 5.4.2.2 Reservado B7 - B4
      • 5.4.2.3 Motivo de rejeição
      • 5.4.2.4 Situação
  • 5.5 FIRMWARE_UPDATE_CONTENT
    • 5.5.1 Comando
      • 5.5.1.1 Cabeçalho (B7 - B0)
      • 5.5.1.2 Dados
    • 5.5.2 Resposta
      • 5.5.2.1 Número sequencial
      • 5.5.2.2 Situação
      • 5.5.2.3 Reservado B8 - B11
      • 5.5.2.4 Reservado B12 - B15
• 6 Apêndice 1: Exemplo de sequência de comandos de programação de atualização de firmware
  • 6.1 Exemplo 1
  • 6.2 Exemplo 2

Tabelas

Tabela 5.1-1 Layout de resposta GET_FIRMWARE_VERSION

Tabela 5.1-2 Resposta GET_FIRMWARE_VERSION - Layout do cabeçalho

Tabela 5.1-3 Resposta GET_FIRMWARE_VERSION - Bits de cabeçalho

Tabela 5.1-4 Resposta GET_FIRMWARE_VERSION - Versão do componente e layout de propriedades

Tabela 5.1-5 Resposta GET_FIRMWARE_VERSION - Versão do Componente e Bits de Propriedades

Tabela 5.2-1 Layout de 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ção 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

Tabela 5.2-7 Comando FIRMWARE_UPDATE_OFFER - Versão diversa e protocolar

Tabela 5.2-8 Layout do token de resposta FIRMWARE_UPDATE_OFFER

Tabela 5.2-9 Resposta FIRMWARE_UPDATE_OFFER - Layout do token

Tabela 5.2-10 Resposta FIRMWARE_UPDATE_OFFER - Bits de token

Tabela 5.2-11 Resposta FIRMWARE_UPDATE_OFFER - Layout do motivo de rejeição

Tabela 5.2-12 Resposta FIRMWARE_UPDATE_OFFER - Bits de Motivo de Rejeição

Tabela 5.2-13 Valores do código RR de resposta FIRMWARE_UPDATE_OFFER

Tabela 5.2-14 Layout do estado da resposta FIRMWARE_UPDATE_OFFER

Tabela 5.2-15 Resposta FIRMWARE_UPDATE_OFFER - Bits de Status

Tabela 5.2-16 Valores de Estado 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ção - Layout do Componente

Tabela 5.3-3 FIRMWARE_UPDATE_OFFER - Comando de Informação - Bits de Componente

Quadro 5.3-4 FIRMWARE_UPDATE_OFFER - Comando de Informação - Valores do 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 de Informação - Bits de Autenticação

Tabela 5.3-8 FIRMWARE_UPDATE_OFFER - Resposta à Informação - Layout do Código RR

Tabela 5.3-9 FIRMWARE_UPDATE_OFFER- Informações da Resposta da Oferta - Bits de Código RR

Tabela 5.3-10 FIRMWARE_UPDATE_OFFER- Resposta à Informação - Valores do Código RR

Tabela 5.3-11 FIRMWARE_UPDATE_OFFER - Estrutura do Estado da Resposta Informativa da Oferta

Tabela 5.3-12 FIRMWARE_UPDATE_OFFER - Dados 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 do 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 ao Pacote de Comando de Oferta - Layout de Token

Tabela 5.4-7 FIRMWARE_UPDATE_OFFER - Oferta do Comando de Resposta - Bits do Token

Tabela 5.4-8 FIRMWARE_UPDATE_OFFER - Layout de Resposta RR do Pacote de Informações da Oferta

Tabela 5.4-9 FIRMWARE_UPDATE_OFFER - Proposta de Resposta ao Comando - 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 do pacote de comando Offer

Tabela 5.4-12 FIRMWARE_UPDATE_OFFER- Oferecer código RR de resposta de pacote de comando

Tabela 5.5-1 Layout de 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 de comando de oferta - Valores do sinalizador

Tabela 5.5-5 Layout de dados de comando FIRMWARE_UPDATE_CONTENT

Tabela 5.5-6 Bits de Dados do Comando FIRMWARE_UPDATE_CONTENT

Tabela 5.5-7 Layout de resposta de comando FIRMWARE_UPDATE_CONTENT

Quadro 5.5-8 Resposta 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 de Resposta de FIRMWARE_UPDATE_CONTENT

Tabela 5.5-11 FIRMWARE_UPDATE_OFFER - Resposta - Status Bits

Tabela 5.5-12 FIRMWARE_UPDATE_OFFER- Resposta - Valores do código de status

1 Introdução

Os PCs e acessórios atuais têm componentes internos que executam operações complexas. Para garantir um produto de qualidade, há a necessidade de atualizar frequentemente o comportamento desses dispositivos em estágios posteriores de desenvolvimento ou depois de serem 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.

Esta especificação descreve um protocolo HID genérico para atualizar o firmware dos componentes presentes em um PC ou seus acessórios. A implementação do HID está além do escopo da especificação.

Algumas das características do protocolo são:

• O protocolo é baseado em HID — ubíquo e tem suporte nativo no Windows em vários barramentos de interconexão, como USB e I²C. Portanto, a mesma solução de software (driver) pode ser aproveitada para atualizar o firmware de 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 melhor experiência para os usuários, porque eles não precisam esperar que o processo de atualização de firmware seja concluído antes de poderem retomar outras tarefas. O novo firmware pode ser invocado em uma única operação atômica de cada vez que tem um impacto mínimo sobre o usuário.

• A especificação suporta configurações em que o componente que aceita o firmware pode ter subcomponentes, que requerem imagens de firmware separadas.

  Observação

  O processo de entrega do firmware de um componente ao subcomponente está fora do âmbito desta especificação.

• A especificação suporta o conceito de uma oferta e depende do componente responsável para decidir se aceita o firmware. A decisão de aceitar um novo firmware não é trivial. Pode haver dependências entre o tipo e/ou versão de firmware e o tipo/versão subjacente de hardware ao qual o novo firmware se aplica. Uma oferta também atua como um mecanismo de otimização porque a imagem do firmware é enviada para o componente apenas se ele for capaz / pronto para aceitá-la.

1.1 Glossário

1.2 Âmbito de aplicação

1.2.1 Objetivos

• Uma solução agnóstica ao barramento é necessária para evitar um novo protocolo para cada tipo de barramento. O HID é onipresente e atende a esse requisito.

• A capacidade de suportar a atualização de firmware para um dispositivo multicomponente, onde um componente atua como o componente primário e outros são subcomponentes conectados ao componente primário. Cada componente requer o seu próprio firmware com dependências não triviais entre si.

• Um modelo de driver comum para baixar a imagem do firmware para o componente. Em seguida, o componente possui algoritmos específicos para cada subcomponente, destinados ao encaminhamento para esses subcomponentes. Os subcomponentes também podem executar verificações de validade em seu firmware e passar os resultados de volta para o componente principal.

• A capacidade de suportar a 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 através de ferramentas autorizadas e atualizar dispositivos no mercado através do Windows Update.

• A flexibilidade para suportar firmware em desenvolvimento/firmware no mercado.

• A capacidade de segmentar uma imagem de firmware grande em segmentos menores para tornar mais fácil para o componente aceitar a imagem de firmware.

1.2.2 Não Metas

• Defina o formato interno da imagem do firmware: Para o host, a imagem do firmware é um conjunto de entradas de endereço e carga útil.

• Assinar/encriptar/validar o firmware aceite: Esta especificação não descreve como assinar e encriptar 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 a comunicação relacionada ao firmware do subcomponente.

2 Arquitetura de hardware suportada

Para suportar um design de hardware flexível, o protocolo suporta um dispositivo multi-componente onde cada componente requer a sua própria imagem de firmware. No projeto, um componente é o componente primário e os subcomponentes dependentes são conectados a esse componente primário. Cada componente é descrito exclusivamente por um ID de componente.

O dispositivo multicomponente é visível para o sistema operacional como uma única unidade. O host interage apenas com o dispositivo, normalmente o componente principal usando este protocolo CFU. A comunicação entre o componente e seus subcomponentes está além do escopo desta especificação.

Em um PC, pode haver muitos dispositivos diferentes (onde um dispositivo pode ter um ou mais componentes lá). No contexto deste protocolo, a comunicação com cada dispositivo é independente. Cada dispositivo tem uma instância correspondente do host.

3 Pré-requisitos do protocolo

Esta seção lista as vantagens e as práticas recomendadas que devem ser implementadas para aproveitar esse protocolo:

• Utilização de imagens atómicas

  Uma imagem de firmware para um componente não é usada até que toda a imagem de firmware tenha sido baixada com êxito. No caso de o firmware ser dividido em vários segmentos, a imagem não deve ser usada até que o segmento final seja recebido do remetente. As verificações de integridade devem ser realizadas na imagem final. Recomenda-se que o transporte, que está sendo usado para entregar a imagem do firmware, tenha mecanismos de correção de erros e novas tentativas 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 quais os fatores que constituem uma imagem de firmware autêntica. É recomendado que o firmware atual do componente pelo menos valide o CRC da imagem de firmware recebida. O firmware atual também deve empregar assinatura digital, ou, outros algoritmos de deteção de erros. Se a validação falhar, o firmware rejeitará a atualização. Recuperação de falhas

  Se a imagem do firmware for transferida e não tiver êxito, o dispositivo não deve invocar o novo firmware e continuar a funcionar com o firmware existente. O anfitrião pode repetir a atualização. A frequência de repetição é específica da implementação.

• Confidencialidade

  Opcional. Um segmento de firmware pode ser encriptado. As técnicas de encriptação e desencriptação estão fora do âmbito desta especificação. Esta especificação trata a carga útil do firmware como um fluxo de dados, independentemente de estar encriptada.

• Proteção contra reversão

  As políticas de reversão são aplicadas pelo componente principal e são específicas da implementação. O firmware atual no componente valida as imagens de firmware recebidas contra políticas internas, tal como a necessidade de o número de versão ser mais recente, ou não ser permitido alterar o tipo de versão de 'release' para 'debug', entre outros. O protocolo permite que as mensagens indiquem que uma atualização é aceita, mesmo que esteja violando as políticas de reversão.

4 Visão geral do protocolo CFU

O protocolo CFU é um conjunto de comandos e respostas que são necessários para enviar a(s) nova(s) imagem(ns) de firmware do host para o dispositivo ao qual o firmware se destina.

Num nível elevado, o protocolo itera por todas as imagens de firmware a serem enviadas para o dispositivo. Para cada imagem de firmware, o host propõe enviar o arquivo para o dispositivo. Somente se o dispositivo aceitar a oferta, o host enviará o arquivo.

Para suportar casos em que uma ordem de atualização de dispositivo tem dependências, o dispositivo pode não aceitar certas ofertas na primeira passagem, portanto, o protocolo permite que o host reenvie 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 do firmware.

4.1.1 Estado: Notificação iniciada pelo host

Depois que o host inicia o processo de inicialização 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. O objetivo deste comando é notificar o firmware atual do dispositivo 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 completar este comando com sucesso.

4.1.2 Estado: OFFER_INFO_START_OFFER_LIST Notificação

Nesse estado, o host emite o comando OFFER_INFO_START_OFFER_LIST para indicar que está pronto para enviar a(s) oferta(s) para o firmware do dispositivo atual. O componente principal do dispositivo deve completar este comando com sucesso.

Este comando é útil porque o host pode enviar todas as ofertas para o dispositivo mais de uma vez.

4.1.3 Estado: Enviar comando FIRMWARE_UPDATE_OFFER

O host envia uma oferta para o componente primário (ou seu subcomponente) para verificar se o componente gostaria de 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, adia, ignora ou rejeita a oferta.

A oferta pode ser para o componente primário ou o subcomponente. Se o componente puder aceitar a oferta, ele se prepara 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. Para obter 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 aceite, o componente principal ainda pode rejeitar a imagem do firmware após o download, devido a falhas nas verificações de integridade ou de reversão em relação à imagem real recebida. O componente deve verificar as propriedades de cada imagem de 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á FIRMWARE_UPDATE_OFFER_ACCEPT status, aceitando assim a oferta.

Se o firmware do dispositivo estiver ocupado e o componente principal não puder aceitar esta ou a próxima oferta atualmente, ele enviará uma resposta de ocupado 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 ausente para o subcomponente), ele responderá com um FIRMWARE_UPDATE_OFFER_SKIP indicando que está interessado neste firmware, mas não pode aceitá-lo. De seguida, o servidor avança para a próxima oferta e deve reapresentar este firmware mais tarde.

Se o firmware atual não estiver interessado na oferta (por exemplo, é uma versão mais antiga), ele responde com um status de FIRMWARE_UPDATE_OFFER_REJECT fornecendo o motivo de rejeição apropriado. Este estado não indica que o anfitrião não possa reenviar esta oferta no futuro. O servidor envia cada oferta sempre que inicializa ou reenvia a lista de ofertas para o dispositivo (consulte Notificação: OFFER_INFO_START_OFFER_LIST).

4.1.4 Estado: Enviar Firmware

Nesse estado, o host começa a enviar a imagem do firmware para o componente principal, para o qual o componente aceitou previamente a oferta.

Como é provável que o conteúdo da imagem do firmware ultrapasse os limites de carga útil de um único comando, o host divide as imagens do 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 de CONTEÚDO DE ATUALIZAÇÃO_DE_FIRMWARE descreve um endereço de offset que inclui um payload parcial do firmware. O componente usa o deslocamento para determinar o endereço onde a carga 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 já não se preparou para receber o firmware, pode fazê-lo neste 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 a carga parcial do firmware incluída neste comando, ele deve executar verificações de validação e autenticação na imagem de firmware de entrada antes de enviar uma resposta. Isto inclui, minimamente:

• Uma verificação CRC para verificar a integridade de toda a imagem de firmware.

• Se a verificação CRC for bem-sucedida, é realizada uma verificação opcional da assinatura da imagem de entrada.

• Após a verificação de assinatura opcional, uma verificação de versão para garantir que a nova versão do firmware é igual ou mais recente do que o firmware existente.

Caso a imagem de firmware recebida 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 passarem, o firmware atual pode configurar o dispositivo para mudar para a nova imagem na próxima redefinição e reporta o sucesso ao anfitrião. Normalmente, o componente não inicia uma reinicializaçã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 deve configurar um swap na próxima redefinição e deve indicar uma mensagem de falha ao host.

4.1.5 Estado da decisão: Existem mais ofertas

Nesse estado, o host determina se há mais ofertas para enviar para o dispositivo.

4.1.6 Estado: OFFER_INFO_END_OFFER_LIST Notificação

Este estado é atingido quando o host tenha enviado todas as ofertas ao componente principal 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 completar este comando com sucesso.

4.1.7 Estado da decisão: Lista de ofertas de repetição

O anfitrião determina se precisa de reenviar todas as ofertas. Esse caso poderia ocorrer se anteriormente o componente principal tivesse ignorado algumas ofertas e aceitado algumas ofertas. O anfitrião 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 repetir 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, ao qual o dispositivo não responde com aceitação até que o dispositivo esteja livre.

Formato de pacote de protocolo CFU 5

O protocolo CFU é implementado como um conjunto de comandos e respostas. O protocolo é de natureza sequencial. Para cada comando que o host envia para um componente, espera-se que o componente responda (a menos que explicitamente indicado 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 pode reiniciar o processo desde o início. Este protocolo não define um valor de tempo limite específico.

Existem comandos para obter as informações de versão do firmware atual no componente; para enviar a oferta e para enviar a imagem do firmware.

No entanto, o host não precisa reter uma proposta com base na resposta recebida do componente principal sobre as informações da versão consultada. As informações são tornadas detetáveis para registro em log ou outros fins.

5.1 OBTER_VERSÃO_DO_FIRMWARE

Obtém a(s) versão(ões) de firmware atual(is) do componente primário (e seus subcomponentes). O comando não tem argumentos.

5.1.1 Comando

Este comando é enviado pelo host para consultar a(s) versão(ões) do(s) firmware(s) atual(is) no componente primário (e seus subcomponentes). O host pode usá-lo para confirmar se o firmware foi atualizado com êxito. Ao receber este 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 de firmware do componente primário e dos 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 Layout de resposta GET_FIRMWARE_VERSION

5.1.2.1 Cabeçalho

Tabela 5.1-2 Resposta GET_FIRMWARE_VERSION - Layout do cabeçalho

O cabeçalho da resposta fornece as seguintes informações.

Tabela 5.1-3 Resposta GET_FIRMWARE_VERSION - Bits de cabeçalho

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 inferior a 7, as DWORDS não utilizadas no final da resposta devem ser definidas como 0.

Tabela 5.1-4 Resposta GET_FIRMWARE_VERSION - Versão do componente e layout de propriedades

Cada informação específica do componente é descrita em dois DWORDs da seguinte forma:

Tabela 5.1-5 Resposta GET_FIRMWARE_VERSION - Versão do componente e bits de propriedades

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 funcionalidade acomoda toda a resposta GET_FIRMWARE_VERSION. Não há dados associados à solicitação Get Feature do host.

5.2 OFERTA_ATUALIZAÇÃO_DE_FIRMWARE

Determina se o componente primário aceita ou rejeita um firmware.

5.2.1 Comando

O host envia esse comando para o componente para determinar se ele aceita ou rejeita um firmware. O anfitrião tem de enviar uma oferta e o componente tem de aceitar a oferta antes de poder enviar o firmware.

O pacote FIRMWARE_UPDATE_OFFER Command é definido da seguinte forma.

Tabela 5.2-1 Layout de comando FIRMWARE_UPDATE_OFFER

5.2.1.1 Informações sobre componentes

Tabela 5.2-2 Comando FIRMWARE_UPDATE_OFFER - Layout de informações do componente

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ção do Componente

5.2.1.2 Versão do firmware

Estes quatro bytes representam a versão de 32 bits do firmware. O formato da versão de firmware não é exigido por esta especificação. Recomenda-se o seguinte.

Tabela 5.2-4 Comando FIRMWARE_UPDATE_OFFER - Layout da versão do firmware

O formato para a versão de firmware não é obrigatório por esta especificação, no entanto, seguir é uma diretriz recomendada.

Tabela 5.2-5 Comando FIRMWARE_UPDATE_OFFER - Bits da versão do firmware

5.2.1.3 Específico do fornecedor

Esses quatro bytes podem ser usados para codificar qualquer informação personalizada na oferta que seja específica para a implementação do fornecedor.

5.2.1.4 Versão diversa e protocolar

Esses quatro bytes podem ser usados para codificar qualquer informação personalizada na oferta que seja específica para a implementação do fornecedor.

Tabela 5.2-6 Comando FIRMWARE_UPDATE_OFFER - Layout específico do fornecedor

Os bits do byte específico do fornecedor são descritos nesta tabela.

Tabela 5.2-7 Comando FIRMWARE_UPDATE_OFFER - Versão diversa e protocolar

5.2.2 Resposta

O pacote FIRMWARE_UPDATE_OFFER Response é definido da seguinte forma.

Tabela 5.2-8 Layout do Token de Resposta FIRMWARE_UPDATE_OFFER

5.2.2.1 Token

Tabela 5.2-9 Resposta FIRMWARE_UPDATE_OFFER - Layout do token

Os bits do byte Token são descritos nesta tabela.

Tabela 5.2-10 Resposta FIRMWARE_UPDATE_OFFER - Bits de token

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 - Esquema dos motivos de rejeição

Tabela 5.2-12 Resposta FIRMWARE_UPDATE_OFFER - Bits de motivo de rejeição

Os bits do byte Razão de rejeição são descritos nesta tabela.

Tabela 5.2-13 Valores do Código RR de Resposta FIRMWARE_UPDATE_OFFER

Os valores possíveis para o byte do código RR são descritos nesta tabela.

5.2.2.4 Situação

Tabela 5.2-14 Layout do status da resposta FIRMWARE_UPDATE_OFFER

Os bits do byte Status são descritos nesta tabela.

Tabela 5.2-15 Resposta FIRMWARE_UPDATE_OFFER - Bits de status

Os valores possíveis para o byte Status são descritos nesta tabela.

Tabela 5.2-16 Valores de Estado de Resposta FIRMWARE_UPDATE_OFFER

5.2.3 Mapeamento para o protocolo HID

A mensagem é enviada para o componente através do mecanismo HID Output Report, utilizando o ID de Relatório do Utilitário HID dedicado para atualização de firmware. O utilitário HID TLC a utilizar está descrito no apêndice.

5.3 FIRMWARE_UPDATE_OFFER - Informação

Se o ID do Componente nos bytes de Informações do Componente (consulte Informações do Componente) estiver definido como 0xFF, os bits (15 bytes) serão redefinidos para indicar Somente Informações da Oferta, do Host para o componente. Esse mecanismo permite a capacidade de extensão e uma forma de o Host fornecer informações específicas para o dispositivo, como Lista de Ofertas Iniciais, Lista de Ofertas Finais, Início de Transação Completa. Os pacotes de informações da oferta são sempre imediatamente aceitos pelo componente.

5.3.1 Comando

O pacote FIRMWARE_UPDATE_OFFER -Information Command é definido da seguinte forma:

Tabela 5.3-1 FIRMWARE_UPDATE_OFFER - Layout do comando de informações

5.3.1.1 Componente

Tabela 5.3-2 FIRMWARE_UPDATE_OFFER - Comando de Informação - Layout do Componente

Os bits do byte do componente são descritos nesta tabela.

Tabela 5.3-3 FIRMWARE_UPDATE_OFFER - Comando de Informação - Bits de Componente

Tabela 5.3-4 FIRMWARE_UPDATE_OFFER - Comando de Informação - Valores do Código de Informação

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 - Offer Information Response é definida da seguinte forma.

Tabela 5.3-5 FIRMWARE_UPDATE_OFFER - Layout de 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 Token são descritos nesta tabela.

Tabela 5.3-7 FIRMWARE_UPDATE_OFFER - Resposta de Informação - Bits de Token

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 à Informação - Layout do Código RR

Os bits do byte Razão de rejeição são descritos nesta tabela.

Tabela 5.3-9 FIRMWARE_UPDATE_OFFER- Resposta de Informação da Oferta - Bits de Código RR

Os valores possíveis para o byte do código RR são descritos nesta tabela.

Tabela 5.3-10 FIRMWARE_UPDATE_OFFER- Resposta à Informação - Valores do Código RR

5.3.2.4 Situação

Tabela 5.3-11 FIRMWARE_UPDATE_OFFER - Layout de Informação de Resposta do Status da Oferta

Os bits do byte Status são descritos nesta tabela.

Tabela 5.3-12 FIRMWARE_UPDATE_OFFER - Informação da oferta - Bits de status de resposta

5.4 FIRMWARE_UPDATE_OFFER - Prorrogado

Se o ID do componente nos bytes de informações do componente estiver definido como 0xFE, os bits (15 bytes) serão redefinidos para indicar o comando Offer do host para o firmware do dispositivo. Este mecanismo permite a extensibilidade e uma maneira para o host fornecer informações específicas para o dispositivo. Os pacotes de comando Offer são retornados quando o componente está pronto para responder Aceito.

5.4.1 Comando

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

5.4.1.1 Componente

Tabela 5.4-2 FIRMWARE_UPDATE_OFFER - Pacote de Comando Ampliado - 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

Tabela 5.4-4 FIRMWARE_UPDATE_OFFER - Comando estendido - Valores do código de comando

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.

5.4.2 Resposta

A resposta do comando de oferta FIRMWARE_UPDATE_OFFER do dispositivo pode não ser recebida imediatamente. A resposta é definida da seguinte forma.

Tabela 5.4-5 FIRMWARE_UPDATE_OFFER - Layout de resposta de pacote de comando estendido

5.4.2.1 Token

Tabela 5.4-6 FIRMWARE_UPDATE_OFFER- Resposta ao Pacote de Comando da Oferta - Layout de Token

Os bits do byte Token são descritos nesta tabela.

Tabela 5.4-7 FIRMWARE_UPDATE_OFFER - Offer Command Response - Token Bits

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 de Pacote de Informações da Oferta

Os bits do byte Razão de rejeição são descritos nesta tabela.

Tabela 5.4-9 FIRMWARE_UPDATE_OFFER - Resposta ao Comando de Oferta - Código RR

Os valores possíveis para o byte do 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

5.4.2.4 Situação

Tabela 5.4-11 FIRMWARE_UPDATE_OFFER - Layout de status de resposta do pacote de comando Offer

Os bits do byte Status são descritos nesta tabela.

Tabela 5.4-12 FIRMWARE_UPDATE_OFFER - Código RR de Resposta ao Pacote de Comando de Oferta

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 do firmware). Não se espera que o arquivo de imagem inteiro caiba 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 principal do firmware do dispositivo aceita cada bloco da imagem de firmware recebida, armazena-o 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 do firmware (verificação CRC, validação de assinatura). Com base nos resultados dessas verificações, retorna uma resposta apropriada (falha ou sucesso) para o último bloco.

5.5.1 Comando

Tabela 5.5-1 Layout de comando FIRMWARE_UPDATE_CONTENT

5.5.1.1 Cabeçalho (B7 - B0)

Tabela 5.5-2 Layout do cabeçalho do comando FIRMWARE_UPDATE_CONTENT

Os bits do cabeçalho FIRMWARE_UPDATE_CONTENT são descritos nesta tabela.

Tabela 5.5-3 FIRMWARE_UPDATE_CONTENT Bits de cabeçalho

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 do sinalizador

5.5.1.2 Dados

Tabela 5.5-5 Layout de dados de comando FIRMWARE_UPDATE_CONTENT

Os bits dos dados FIRMWARE_UPDATE_CONTENT são descritos nesta tabela.

Tabela 5.5-6 FIRMWARE_UPDATE_CONTENT bits de dados de comando

5.5.2 Resposta

Tabela 5.5-7 Layout de Resposta do Comando FIRMWARE_UPDATE_CONTENT

5.5.2.1 Número sequencial

Quadro 5.5-8 Resposta do 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

5.5.2.2 Situação

Tabela 5.5-10 FIRMWARE_UPDATE_CONTENT Layout do Status da Resposta

Os bits do FIRMWARE_UPDATE_CONTENT Response (7-4) são descritos nesta tabela.

Tabela 5.5-11 FIRMWARE_UPDATE_OFFER - Resposta - Bits de Estado

Os valores possíveis para o byte Status são descritos nesta tabela.

Tabela 5.5-12 FIRMWARE_UPDATE_OFFER- Resposta - Valores do código de status

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 - Versão de firmware atual 7.0.1

• Subcomponente - ID do componente 2 - Versão de firmware atual 12.4.54

• Subcomponente - ID do componente 3 - Versão de firmware atual 4.4.2

• Subcomponente - ID do componente 4 - Versão de firmware atual 23.32.9

O host tem estas três imagens de firmware:

• ID do componente 1 - Versão de firmware 7.1.3

• ID do componente 2 - Versão de firmware 12.4.54

• ID do componente 3 - Versão de firmware 4.5.0

A sequência será:

1. Ofertas do anfitrião: ID do componente 1 - Versão de firmware 7.1.3

2. O componente principal aceita a oferta

3. O anfitrião envia a imagem do firmware

4. O componente principal aceita firmware, valida-o

5. Ofertas do anfitrião: ID do componente 2 - Versão de firmware 12.4.54

6. O componente principal rejeita a oferta

7. Ofertas do Host: ID do componente 3 - Versão de firmware 4.5.0

8. O componente principal aceita a oferta

9. O anfitrião envia a imagem do firmware

10. O componente principal aceita firmware, valida-o

Como nem todas as ofertas foram rejeitadas, o anfitrião repete todas as ofertas:

1. Ofertas do anfitrião: ID do componente 1 - Versão de firmware 7.1.3

2. Rejeições de componentes

3. Ofertas do anfitrião: ID do componente 2 - Versão de firmware 12.4.54

4. Rejeições de componentes

5. Ofertas do anfitrião: ID do componente 3 - Versão de firmware 4.5.0

6. Rejeições de componentes

6.2 Exemplo 2

Considere o seguinte firmware de dispositivo:

• Componente primário - ID do componente 1 - Versão de firmware atual 7.0.1

• Subcomponente - ID do componente 2 - Versão de firmware atual 12.4.54

• Subcomponente - ID do componente 3 - Versão de firmware atual 7.4.2

• Subcomponente - ID do componente 4 - Versão de firmware atual 23.32.9

O host tem estas três imagens de firmware:

• ID do componente 1 - Versão de firmware 8.0.0

• ID do componente 2 - Versão de firmware 12.4.54

• ID do componente 3 - Versão de firmware 9.0.0

Além disso, a implementação requer que a versão de firmware dos subcomponentes não deve ser inferior à versão de firmware em execução no componente principal. O host não está ciente deste requisito e o up-to é o componente principal para assegurar esta regra.

A sequência será:

1. Ofertas do anfitrião: ID do componente 1 - Versão de firmware 8.0.0

2. Rejeitações de componentes primários (porque o ID de componente 3 ainda não foi atualizado)

3. Ofertas do anfitrião: ID do componente 2 - Versão de firmware 12.4.54

4. Componentes primários rejeitados

5. Ofertas do anfitrião: ID do componente 3 - Versão de firmware 9.0.0

6. Componente principal aceita oferta

7. O anfitrião envia a imagem do firmware

8. O componente principal aceita firmware, valida-o

Como nem todas as ofertas foram rejeitadas, o anfitrião repete todas as ofertas

1. Ofertas do anfitrião: ID do componente 1 - Versão de firmware 8.0.0

2. Componente principal aceita oferta

3. O anfitrião envia a imagem do firmware

4. O componente principal aceita firmware, valida-o

5. Ofertas do anfitrião: ID do componente 2 - Versão de firmware 12.4.54

6. Rejeitos de componentes primários

7. Ofertas do host: ID do componente 3 - Versão de firmware 9.0.0

8. Rejeições de componentes primários