Version: 1.0.2
Dernière mise à jour: 12/03/2025
Résumé
Ce document est destiné à expliquer comment les fournisseurs peuvent implémenter fwupd pour de futurs projets. Il inclut également des insights directement cités par les responsables de LVFS. Fwupd est un framework de mise à jour du micrologiciel Open Source qui peut aider à centraliser la façon dont nous effectuons les mises à jour du micrologiciel en partenariat avec des fournisseurs externes.
Première étape : Rassemblez des informations et fournissez des conseils
Pour les fournisseurs : posez d'abord les questions suivantes :
Questions sur les composants pouvant être mis à jour
Taille de la mise à jour
Heure de mise à jour
Type de mise à jour existant (modèle A/B ou bootloader/runtime)
Qu'advient-il de la fonctionnalité du composant lors d'une mise à jour ?
Que doit-il se passer pour que le système commence à utiliser une mise à jour réussie ?
Plusieurs composants doivent-ils être installés dans un ordre particulier ?
Connaissances ou expérience de LVFS/fwupd
Possibilité d'affecter des ressources techniques pour aider à implémenter le plug-in (pour en savoir plus, consultez les informations ci-dessous)
Engagement à publier le plug-in en Open Source sous LGPLv2+ (code qui écrit le micrologiciel dans le composant) et à permettre la redistribution du micrologiciel par LVFS
Pour les fournisseurs : conseils initiaux :
La mise à jour doit réduire au maximum le temps pendant lequel la fonctionnalité du composant périphérique ou interne est affectée, idéalement à quelques secondes. La partie la plus longue de la mise à jour doit se produire de manière silencieuse en arrière-plan sans perturber l'utilisateur.
- Si ce périphérique a un impact évident sur l'expérience utilisateur (par exemple, l'écran ne fonctionne plus), cette exigence devient encore plus stricte.
Pour activer ce type de mise à jour silencieuse, nous vous recommandons vivement d'utiliser les mises à jour A/B.
- Les mises à jour A/B pouvant s'activer lors du débranchement d'un périphérique sont idéales pour minimiser les perturbations pour l'utilisateur.
La mise à jour doit être récupérable. Si vous éteignez l'appareil, débranchez le périphérique, etc., la mise à jour ne doit pas bloquer l'appareil ou le périphérique. Il doit être robuste pour se rétablir sans action de l'utilisateur.
- L'hypothèse initiale doit être qu'aucune action de l'utilisateur n'est requise pendant toute la mise à jour. Les scripts et les étapes de mise à jour appropriés doivent être gérés de manière autonome.
Deuxième étape : Utiliser fwupd
Si un fournisseur n'a jamais utilisé fwupd
Chrome OS transmet les exigences de mise à jour du micrologiciel via fwupd aux OEM. L'OEM doit communiquer ces informations directement aux fournisseurs de puces / composants.
Dans certains cas, l'ODM peut aider l'OEM à interagir directement avec les fournisseurs de puces. Il incombe à l'OEM de communiquer ces exigences en conséquence.
Veuillez noter que si vous fournissez du code source avec une licence LGPLv2 ou version ultérieure, il n'est généralement pas possible de dériver le plug-in à partir de ce code (trop de complexités). Dans ce scénario, le fournisseur de puces devra disposer d'une personne capable de travailler avec les responsables de fwupd et les ingénieurs Google.
L'OEM peut être proactif et aider les fournisseurs de puces à s'engager à travailler en étroite collaboration avec les mainteneurs. La demande d'assistance technique du côté du fournisseur doit respecter les exigences suivantes:
Très familiarisé avec les particularités et les caractéristiques de conception du composant matériel pouvant être mis à jour, et de préférence membre de l'équipe qui a écrit le micrologiciel
Comprendre la différence entre les licences Open Source courantes (par exemple, LGPLv2 et MIT)
Maîtrisez le langage C, et possédez des connaissances de base sur GLib et GObject, en particulier sur les erreurs GErrors.
Vous disposez d'un compte GitHub et savez comment ouvrir et mettre à jour une demande d'extraction, effectuer des révisions de code GitHub et découvrir comment fwupd est structuré avec tous les outils d'assistance qu'il fournit (par exemple, le fractionnement, l'association/la dissociation, les tentatives de réassociation de l'appareil, HID, etc.).
Facultatif: possibilité d'envoyer des échantillons matériels au Royaume-Uni. Très utile pour les responsables de fwupd pour aider le fournisseur à déboguer les problèmes et à ajouter la carte aux tests fwupd exécutés à chaque version. Ce dernier est important pour arrêter les régressions dans la branche de développement.
En parallèle, l'OEM peut commencer à interagir via la liste de diffusion fwupd ou directement avec Richard Hughes (hughsient@gmail.com) et examiner le plan avant que le code du plug-in ne soit écrit.
Si une entreprise est petite, avec peu ou pas de ressources d'ingénierie ou de connaissances en Open Source, la suggestion suivante peut vous aider:
Le fournisseur de composants peut faire appel à des sociétés de conseil, qui connaissent le travail Open Source (sans que cela entraîne des coûts supplémentaires).
Bien que cette suggestion puisse aider à faire évoluer le système, l'intérêt de laisser le fournisseur le faire en interne est que les ingénieurs se familiarisent avec le processus et peuvent facilement ajouter des VID/PID à l'avenir pour du nouveau matériel. Il est également plus rapide de résoudre les questions / problèmes à déboguer sur le matériel.
Troisième étape : dernières étapes
Le code est finalement refactorisé en petits commits éligibles à l'examen à l'aide de toutes les fonctionnalités partagées de fwupd.
Une fois la fusion terminée, le plug-in est fusionné en amont.
Le code utilisé en amont est le même que celui de ChromeOS.
Les binaires de mise à jour du micrologiciel utilisés en dehors de ChromeOS seraient distribués à LVFS.
Dans le cas de ChromeOS, plus précisément:
L'OEM doit importer le binaire du micrologiciel sur nos serveurs via CPFE.
Des archives de cabinet de mise à jour redistribuables doivent toujours être présentes sur le LVFS pour que les tests de régression matérielle fonctionnent.
Quatrième étape (facultatif) : Ajouter des composants
- Si le framework fwupd est déjà en place, la seule étape supplémentaire consiste à demander au fournisseur de composants à jour de travailler sur les requêtes pull pour ajouter des particularités et des VID/PID pour les variantes matérielles.
Autres conseils : travailler sur les LVFS
Créer un compte fournisseur (configuration en deux minutes environ)
Les fournisseurs créent des utilisateurs pour leur propre domaine ou utilisent un outil tel qu'Azure AD pour synchroniser les comptes utilisateur avec le LVFS. Ils peuvent importer le micrologiciel dans des versions privées et soumises à embargo par le fournisseur, entièrement sans frais et avec très peu de vérifications (c'est donc souvent les ingénieurs qui le font dès le départ).
À terme, le transfert vers les versions de test ou stables nécessite un document de la part de leur service juridique indiquant clairement que le LVFS peut redistribuer et analyser le micrologiciel. Richard fournit des consignes concernant les fichiers PDF. ● Si le fournisseur n'est qu'un fournisseur de silicium ou un ODM, il peut devenir un "affilié" de l'OEM et mettre en ligne du micrologiciel en son nom, l'OEM ayant une visibilité complète sur ce qui se passe avec le micrologiciel portant son nom.
De nombreux autres éléments doivent être configurés (par exemple, l'ID du fournisseur les limite à un ensemble d'ID PCI ou USB), mais la plupart des fournisseurs disposent déjà d'un ID attribué et la configuration prend 20 secondes.
Autres conseils : éléments spécifiques à ChromeOS
Dans notre cas, les binaires de mise à jour du micrologiciel ne sont pas extraits directement de LVFS. Le fichier CAB sera stocké dans le système de fichiers local (rootfs).
- Flux de travail futur: intégrer le binaire du micrologiciel dans le DLC en créant un ebuild de portage sur le calque de portage approprié
fwupd doit être appelé (via sa CLI fwupdtool) au bon moment. Pour chaque composant pouvant être mis à jour, une règle udev (ou un script équivalent) doit être créée, qui émet un événement upstart fwuptool-update. Cet événement sera géré automatiquement pour exécuter fwupdtool avec les bons arguments et un bac à sable approprié (minijail).
Un autre composant consiste à déterminer si l'UI est requise, mais uniquement dans certaines circonstances, en fonction de la nature du composant mis à jour. À évaluer par le PM et l'équipe d'ingénieurs. Les conseils de niveau supérieur, comme indiqué à l'étape 1, consistent à réduire au maximum les actions côté utilisateur.
Ressources supplémentaires pour les fournisseurs
Référence de la documentation externe: https://lvfs.readthedocs.io/
Référence des contrats avec des fournisseurs externes: fwupd.org/lvfs/docs/agreement
Tutoriel de développement de plug-in: https://fwupd.github.io/tutorial.html
Tutoriel de débogage du plug-in : https://lvfs.readthedocs.io/en/latest/custom-plugin.html
Exemple de fichier de bizarrerie : https://github.com/fwupd/fwupd/blob/master/plugins/wacom-usb/wacom-usb.quirk
Historique des révisions
| Date | Version | Remarques |
|---|---|---|
| 2025-03-12 | 1.0.2 | Convertir du texte au format PDF en Markdown |
| 2024-01-31 | 1.0.1 | Républication sur la nouvelle plate-forme |
| 2023-10-12 | 1.0 | Publication initiale |