Versão: 1.0.2
Última atualização: 12 de março de 2025
Texto longo, leia o resumo
Este documento é um tutorial sobre como os fornecedores podem implementar o fwupd para projetos futuros. Ele também inclui insights citados diretamente dos mantenedores do LVFS. O fwupd é um framework de atualização de firmware de código aberto que pode ajudar a centralizar a maneira como realizamos atualizações de firmware em parceria com fornecedores externos.
Primeira etapa: coletar informações e dar orientações
Para fornecedores: primeira pergunta:
Perguntas sobre componentes atualizáveis
Atualizar tamanho
Horário de atualização
Tipo de atualização atual (A/B ou carregador de inicialização/modelo de execução)
O que acontece com a funcionalidade do componente durante uma atualização?
O que precisa acontecer para o sistema começar a usar uma atualização bem-sucedida?
Vários componentes precisam ser instalados em uma ordem específica?
Familiaridade ou conhecimento em trabalhar com LVFS/fwupd
Capacidade de confirmar o recurso de eng para ajudar a implementar o plug-in (consulte abaixo para mais detalhes)
Compromisso de disponibilizar o plug-in de código aberto para LGPLv2+ (código que grava o firmware no componente) e permitir que o firmware seja redistribuído pelo LVFS
Para fornecedores: orientação inicial:
A atualização precisa minimizar o tempo em que a funcionalidade do componente periférico ou interno é afetada, de preferência para alguns segundos. A maior parte da atualização precisa ocorrer silenciosamente em segundo plano sem interromper o usuário.
- Se esse periférico afetar a experiência do usuário de maneira óbvia (por exemplo, a tela parar de funcionar), esse requisito se tornará ainda mais rigoroso.
Para ativar esse tipo de atualização silenciosa, recomendamos as atualizações A/B.
- As atualizações A/B que podem ser ativadas na desconexão do periférico são ideais para minimizar a interrupção do usuário
A atualização precisa ser recuperável. Se você desligar, desconectar o periférico etc., a atualização não pode inutilizar o dispositivo ou o periférico. Ele precisa ser robusto para ser recuperado sem a ação do usuário.
- A suposição inicial é que não há ação do usuário durante toda a atualização, os scripts e estágios adequados de atualização precisam ser executados de forma autônoma.
Segunda etapa: usar o fwupd
Se um fornecedor nunca usou o fwupd
O Chrome OS fornece requisitos para a atualização de firmware por fwupd para OEM. O OEM precisa comunicar isso diretamente aos fornecedores de chips / componentes.
Em alguns casos, o ODM pode ajudar o OEM a se conectar diretamente aos fornecedores de chips. É responsabilidade do OEM comunicar e transmitir esses requisitos.
Se você fornecer o código-fonte com a licença LGPLv2+, a extração do plug-in desse código normalmente não será viável (muitas complexidades). Nesse cenário, o fornecedor do chip precisa ter alguém que possa trabalhar com os mantenedores do fwupd e os engenheiros do Google.
O OEM pode ser proativo e ajudar a conseguir o compromisso dos fornecedores de chips para trabalhar em estreita colaboração com os mantenedores. A solicitação de suporte técnico do fornecedor tem os seguintes requisitos:
Conhecer bem as peculiaridades e os recursos de design do componente de hardware atuável, de preferência até mesmo estar na mesma equipe que escreveu o firmware
Entender a diferença entre licenças de código aberto comuns (por exemplo, LGPLv2 e MIT)
Ter conhecimento avançado em C, com um entendimento básico de GLib e GObject, especificamente de GErrors
Ter uma conta do GitHub e saber como abrir e atualizar uma solicitação de envio, fazer análises de código do GitHub e aprender como o fwupd está estruturado com todos os auxiliares fornecidos pelo fwupd (por exemplo, fragmentação, anexar/desanexar, repetição de dispositivos, HID etc.)
Opcional: capacidade de enviar amostras de hardware para o Reino Unido, muito útil para que os mantenedores do fwupd ajudem o fornecedor a depurar problemas e adicionar a placa aos testes do fwupd que são executados em cada versão. O último é importante para interromper regressões na ramificação de desenvolvimento.
Paralelamente, o OEM pode começar a interagir com a lista de e-mails do fwupd ou com Richard Hughes (hughsient@gmail.com) diretamente e analisar o plano antes de escrever o código do plug-in.
Se uma empresa é pequena, com poucos ou nenhum recurso de engenharia ou compreensão de código aberto, a sugestão a seguir pode ajudar:
O fornecedor do componente pode usar empresas de consultoria, familiarizadas com o trabalho de código aberto (sem custo extra).
Embora essa sugestão possa ajudar a dimensionar, o valor do fornecedor que faz isso internamente é que os engenheiros se familiarizam com o processo e podem adicionar facilmente o VID/PID no futuro para novos hardwares. Também é mais rápido fechar perguntas / problemas para depurar no hardware.
Terceira etapa: etapas finais
Eventualmente, o código é reestruturado em pequenos commits passíveis de revisão usando toda a funcionalidade compartilhada no fwupd.
Quando concluído, o plug-in é mesclado no upstream
O código usado upstream seria o mesmo no ChromeOS
Os binários de atualização de firmware usados fora do ChromeOS seriam distribuídos para o LVFS.
No caso do ChromeOS especificamente:
O OEM precisa fazer upload do binário do firmware para nossos servidores usando o CPFE
Ainda é necessário ter arquivos de gabinete de atualização redistribuíveis no LVFS para que os testes de regressão de hardware funcionem.
Quarta etapa (opcional): adicionar novos componentes
- Se o framework fwupd já estiver em uso, a única etapa adicional é que o fornecedor de componentes atualizáveis precisa trabalhar em solicitações de pull para adicionar peculiaridades e VID/PIDs para variantes de hardware.
Outras orientações: como trabalhar com LVFS
Criar uma conta de fornecedor (cerca de dois minutos para configurar)
Os fornecedores criam usuários para o próprio domínio ou usam algo como o Azure AD para sincronizar contas de usuário com o LVFS. Eles podem fazer upload de firmware para o embargo privado e do fornecedor completamente sem custo financeiro com poucas verificações. Por isso, geralmente são os engenheiros que fazem isso desde o início.
Eventualmente, o push para testes ou estável exige algum tipo de documento do departamento jurídico que indique claramente que o LVFS pode redistribuir e analisar o firmware. A diretriz em PDF é fornecida por Richard. ● Se o fornecedor for apenas um fornecedor de silício ou um ODM, ele poderá se tornar "afiliado" do OEM e fazer o upload do firmware em nome dele, com o OEM tendo visibilidade total do que está acontecendo com o firmware com a marca dele.
Há muitas outras coisas a serem configuradas, como o ID do fornecedor, que restringe a um conjunto de IDs PCI ou USB. No entanto, a maioria dos fornecedores já tem um ID atribuído e a configuração leva 20 segundos.
Outras orientações: detalhes específicos do Chrome OS
No nosso caso, os binários de atualização de firmware não são extraídos diretamente do LVFS. Em vez disso, o arquivo CAB será armazenado no sistema de arquivos local (rootfs).
- Fluxo de trabalho futuro: incorpore o binário do firmware no DLC criando um ebuild de portage na sobreposição de portage apropriada
O fwupd precisa ser invocado (pelo fwupdtool da CLI) no momento certo. Para cada componente atualizável, é necessário criar uma regra udev (ou um script equivalente) que emita um evento de inicialização fwuptool-update. Esse evento será processado automaticamente para executar o fwupdtool com os argumentos corretos e o sandbox adequado (minijail).
Outro componente é decidir se a interface é necessária, apenas em determinadas circunstâncias, dependendo da natureza do componente atualizado. Ser avaliado pelo gerente de produto e pela equipe de engenharia. A orientação de nível mais alto, conforme mencionado na primeira etapa, é minimizar a ação do usuário
Outros recursos para fornecedores
Referência da documentação externa: https://lvfs.readthedocs.io/
Referência de contratos com fornecedores externos: fwupd.org/lvfs/docs/agreement
Tutorial de desenvolvimento de plug-ins: https://fwupd.github.io/tutorial.html
Tutorial de depuração de plug-ins: https://lvfs.readthedocs.io/en/latest/custom-plugin.html
Exemplo de arquivo de peculiaridade: https://github.com/fwupd/fwupd/blob/master/plugins/wacom-usb/wacom-usb.quirk
Histórico de revisões
| Data | Versão | Observações |
|---|---|---|
| 2025-03-12 | 1.0.2 | Converter texto de PDF em Markdown |
| 2024-01-31 | 1.0.1 | Republicação em uma nova plataforma |
| 2023-10-12 | 1,0 | Publicação inicial |