Versión: 1.0.2
Última actualización: 12/3/2025
Resumen
El objetivo de este documento es explicar cómo los proveedores pueden implementar fwupd para proyectos futuros. También incluye estadísticas citadas directamente de los mantenedores de LVFS. Fwupd es un framework de actualización de firmware de código abierto que puede ayudar a centralizar la forma en que realizamos las actualizaciones de firmware en asociación con proveedores externos.
Primer paso: Recopila información y brinda orientación
Para proveedores: Primera pregunta:
Preguntas sobre los componentes actualizables
Tamaño de actualización
Fecha de actualización
Tipo de actualización existente (modelo A/B o de bootloader/entorno de ejecución)
¿Qué sucede con la funcionalidad del componente durante una actualización?
¿Qué debe suceder con el sistema para comenzar a usar una actualización correcta?
¿Se deben instalar varios componentes en un orden en particular?
Familiaridad con el uso de LVFS/fwupd o conocimiento de ellos
Posibilidad de confirmar un recurso de eng para ayudar a implementar el complemento (consulta a continuación para obtener más detalles)
Compromiso con el complemento de código abierto a LGPLv2+ (código que escribe el firmware en el componente) y permite que LVFS redistribuya el firmware
Para proveedores: Orientación inicial:
La actualización debe minimizar el tiempo en que se ve afectada la funcionalidad del componente periférico o interno, idealmente a un par de segundos. La parte más larga de la actualización debe ocurrir de forma silenciosa en segundo plano sin interrumpir al usuario.
- Si este periférico afecta la experiencia del usuario de manera evidente (p. ej., la pantalla deja de funcionar), este requisito se vuelve aún más estricto.
Para habilitar este tipo de actualización silenciosa, se recomienda que se implementen actualizaciones A/B.
- Las actualizaciones A/B que se pueden activar cuando se desconecta un periférico son ideales para minimizar las interrupciones del usuario.
La actualización debe poder recuperarse. Si apagas el dispositivo, desconectas el periférico, etc., la actualización no debe inutilizar el dispositivo o el periférico. Debe ser sólida para recuperarse sin la acción del usuario.
- La suposición inicial debe ser que no hay ninguna acción del usuario durante toda la actualización, y que las secuencias de comandos y las etapas de actualización adecuadas deben controlarse de forma autónoma.
Segundo paso: Usa fwupd
Si un proveedor nunca usó fwupd
ChromeOS proporciona los requisitos para la actualización de firmware a través de fwupd al OEM. El OEM debe comunicar esto directamente a los proveedores de chips o componentes.
En algunos casos, el ODM puede ayudar al OEM a interactuar directamente con los proveedores de chips. Es responsabilidad del OEM comunicar estos requisitos según corresponda.
Ten en cuenta que, si proporcionas código fuente con la licencia LGPLv2+, por lo general, no es factible derivar el complemento de este código (hay muchos detalles). Por lo tanto, en esta situación, el proveedor del chip deberá tener a alguien que pueda trabajar con los mantenedores de fwupd y los ingenieros de Google.
El OEM puede ser proactivo y ayudar a obtener el compromiso de los proveedores de chips para que trabajen en estrecha colaboración con los mantenedores. La solicitud de asistencia de ingeniería del proveedor tiene los siguientes requisitos:
Debes tener mucho conocimiento de las peculiaridades y las características de diseño del componente de hardware actualizable, y preferiblemente, pertenecer al mismo equipo que escribió el firmware.
Comprende la diferencia entre las licencias de código abierto comunes (p.ej., LGPLv2 y MIT)
Dominar C, con conocimientos básicos de GLib y GObject, y también de GErrors
Tener una cuenta de GitHub y saber cómo abrir y actualizar una solicitud de extracción, realizar revisiones de código de GitHub y aprender cómo se estructura fwupd con todos los ayudantes que proporciona fwupd (p. ej., fragmentación, conexión/desconexión, reintentos del dispositivo, HID, etc.)
Opcional: Posibilidad de enviar muestras de hardware al Reino Unido. Es muy útil para que los encargados del mantenimiento de fwupd ayuden al proveedor a depurar problemas y agregar la placa a las pruebas de fwupd que se ejecutan en cada versión. Lo último es importante para detener las regresiones en la rama de desarrollo.
Al mismo tiempo, el OEM puede comenzar a interactuar a través de la lista de distribución de fwupd o directamente con Richard Hughes (hughsient@gmail.com) y revisar el plan antes de escribir el código del complemento.
Si una empresa es pequeña, con pocos recursos de ingeniería o sin conocimiento del código abierto, la siguiente sugerencia podría ser útil:
El proveedor de componentes podría usar empresas de consultoría que estén familiarizadas con el trabajo de código abierto (no es que esto genere costos adicionales).
Si bien esta sugerencia puede ayudar a escalar, el valor de que el proveedor lo haga de forma interna es que los ingenieros se familiarizan con el proceso y pueden agregar fácilmente VID/PID en el futuro para hardware nuevo. También es más rápido cerrar preguntas o problemas para depurar en el hardware.
Tercer paso: pasos finales
Con el tiempo, el código se refactoriza en pequeñas confirmaciones revisables con toda la funcionalidad compartida en fwupd.
Una vez completado, el complemento se fusiona con la versión upstream.
El código que se usa en la parte superior sería el mismo que se usa en ChromeOS.
Los objetos binarios de actualización de firmware que se usan fuera de ChromeOS se distribuirían a LVFS.
En el caso de ChromeOS, específicamente:
El OEM debe subir el firmware binario a nuestros servidores a través de CPFE.
Aún deben haber archivos de gabinete de actualización redistribuibles en el LVFS para que funcionen las pruebas de regresión de hardware.
Cuarto paso (opcional): Agrega componentes nuevos
- Si el framework de fwupd ya está implementado, el único paso adicional es que el proveedor de componentes actualizables debe trabajar en las solicitudes de extracción para agregar peculiaridades y VID/PID para las variantes de hardware.
Otra orientación: Cómo trabajar en LVFS
Crea una cuenta de proveedor nueva (la configuración tarda alrededor de 2 minutos).
Los proveedores crean usuarios para su propio dominio o usan algo como Azure AD para sincronizar las cuentas de usuario con el LVFS. Pueden subir firmware a privado y con embargo del proveedor completamente gratis con muy pocas verificaciones (por lo que, a menudo, los ingenieros lo hacen desde el principio).
En última instancia, el envío a la versión de prueba o estable requiere algún tipo de documento de su departamento legal que indique claramente que el LVFS puede redistribuir y analizar el firmware. Richard proporciona el documento de lineamientos en PDF. ● Si el proveedor es solo un proveedor de silicio o un ODM, puede convertirse en “afiliado” del OEM y subir firmware en su nombre, de modo que el OEM tenga visibilidad total de lo que sucede con el firmware con su marca.
Hay muchos otros elementos que configurar (p.ej., el ID del proveedor los limita a un conjunto de IDs de PCI o USB), pero la mayoría de los proveedores ya tienen un ID asignado, y la configuración tarda 20 segundos.
Otras instrucciones: Información específica de ChromeOS
En nuestro caso, los objetos binarios de actualización de firmware no se extraen directamente de LVFS. En su lugar, el archivo CAB se almacenará en el sistema de archivos local (rootfs).
- Flujo de trabajo futuro: Incorpora el firmware binario en DLC creando un ebuild de portage en la superposición de portage adecuada.
Se debe invocar fwupd (a través de su herramienta de CLI fwupdtool) en el momento adecuado. Para cada componente actualizable, se debe crear una regla udev (o una secuencia de comandos equivalente) que emita un evento upstart fwuptool-update. Este evento se controlará automáticamente para ejecutar fwupdtool con los argumentos correctos y la zona de pruebas adecuada (minijail).
Otro componente es decidir si se requiere la IU, solo en ciertas circunstancias, según la naturaleza del componente actualizado. Para que el equipo de PM y Eng la evalúe. La guía de nivel superior, como se mencionó en el primer paso, es minimizar la acción del usuario.
Recursos adicionales para proveedores
Referencia de documentación externa: https://lvfs.readthedocs.io/
Referencia de los acuerdos con proveedores externos: fwupd.org/lvfs/docs/agreement
Instructivo para desarrollar complementos: https://fwupd.github.io/tutorial.html
Instructivo del complemento de depuración: https://lvfs.readthedocs.io/en/latest/custom-plugin.html
Archivo de error de muestra: https://github.com/fwupd/fwupd/blob/master/plugins/wacom-usb/wacom-usb.quirk
Historial de revisión
| Fecha | Versión | Notas |
|---|---|---|
| 2025-03-12 | 1.0.2 | Convierte texto de PDF a Markdown |
| 2024-01-31 | 1.0.1 | Nueva publicación en una plataforma nueva |
| 2023-10-12 | 1.0 | Publicación inicial |