Версия: 1.0.2
Последнее обновление: 12 марта 2025 г.
ТЛ;ДР
Этот документ представляет собой пошаговое руководство по тому, как поставщики могут реализовать fwupd для будущих проектов. Он также включает в себя информацию, полученную непосредственно от сопровождающих LVFS. Fwupd — это платформа обновления встроенного ПО с открытым исходным кодом, которая может помочь централизовать способ выполнения обновлений встроенного ПО в сотрудничестве с внешними поставщиками.
Первый шаг – сбор информации и предоставление рекомендаций
Для продавцов – сначала спросите:
Вопросы по обновляемым компонентам(ам)
Обновить размер
Время обновления
Существующий тип обновления (A/B или модель загрузчика/время выполнения)
Что происходит с функциональностью компонента во время обновления?
Что должно произойти с системой, чтобы начать использовать успешное обновление?
Необходимо ли устанавливать несколько компонентов в определенном порядке?
Умение работать с LVFS/fwupd или знание о нем
Возможность использовать англоязычный ресурс для помощи в реализации плагина (более подробную информацию см. ниже).
Приверженность плагину с открытым исходным кодом для LGPLv2+ (код, который записывает прошивку в компонент) и позволяет распространять прошивку через LVFS.
Для поставщиков – первоначальное руководство:
Обновление должно свести к минимуму время воздействия на функциональность периферийных или внутренних компонентов, в идеале — до пары секунд. Более длинная часть обновления должна происходить в фоновом режиме, не отвлекая пользователя.
- Если это периферийное устройство оказывает очевидное влияние на работу пользователя (например, перестает работать дисплей), это требование становится еще более строгим.
Чтобы включить этот тип автоматического обновления, настоятельно рекомендуется использовать обновления A/B.
- Обновления A/B, которые могут активироваться при отключении периферийного устройства, идеально подходят для минимизации помех для пользователей.
Обновление должно быть восстанавливаемым — если вы выключите питание, отсоедините периферийное устройство и т. д., обновление не должно привести к блокировке устройства или периферийного устройства. Он должен быть надежным, чтобы его можно было восстановить без действий пользователя.
- Первоначальное предположение должно заключаться в том, что в течение всего обновления пользователь не выполняет никаких действий, а соответствующие сценарии и этапы обновления должны выполняться автономно.
Второй шаг — использование fwupd
Если поставщик никогда не использовал fwupd
Chrome OS предъявляет требования к обновлению прошивки через fwupd OEM-производителю. OEM должен сообщить об этом напрямую поставщикам чипов/компонентов.
В некоторых случаях ODM может помочь OEM напрямую взаимодействовать с поставщиками микросхем. OEM-производитель несет ответственность за соответствующее информирование об этих требованиях.
Обратите внимание, что если предоставить исходный код с лицензией LGPLv2+, создание плагина на основе этого кода обычно невозможно (много сложностей). Таким образом, в этом сценарии поставщику чипа потребуется человек, который сможет работать с сопровождающими fwupd и инженерами Google.
OEM-производитель может проявить инициативу и помочь добиться от поставщиков микросхем тесного сотрудничества с разработчиками. Запрос на техническую поддержку со стороны поставщика предъявляет следующие требования:
Хорошо знаком с особенностями и конструктивными особенностями обновляемого аппаратного компонента, желательно даже находиться в той же команде, которая писала прошивку.
Поймите разницу между распространенными лицензиями с открытым исходным кодом (например, LGPLv2 и MIT).
Знать C, иметь базовое понимание GLib и GObject, в частности понимание GErrors.
Иметь учетную запись GitHub и знать, как открывать и обновлять запрос на включение, выполнять проверки кода GitHub и узнавать, как структурирован fwupd со всеми помощниками, которые предоставляет fwupd (например, фрагментирование, присоединение/отключение, повторные попытки устройства, HID и т. д.).
Дополнительно: возможность отправлять образцы оборудования в Великобританию — очень полезно для сопровождающих fwupd, чтобы помочь поставщику отладить проблемы и добавить плату в тесты fwupd, которые запускаются в каждом выпуске. Последнее важно для прекращения регресса в отрасли развития.
Параллельно OEM-производитель может начать взаимодействие через список рассылки fwupd или напрямую с Ричардом Хьюзом (hughsient@gmail.com) и обсудить план до того, как будет написан код плагина.
Если компания небольшая и практически не имеет инженерных ресурсов или понимания открытого исходного кода, может помочь следующее предложение:
Поставщик компонентов может использовать консалтинговые компании, знакомые с работой с открытым исходным кодом (но это не требует дополнительных затрат).
Хотя это предложение может способствовать масштабированию, ценность того, что поставщик делает это самостоятельно, заключается в том, что инженеры ознакомятся с процессом и смогут легко добавить VID/PID в будущем для нового оборудования. Также быстрее закрывать вопросы/проблемы для отладки оборудования.
Третий шаг – Заключительные шаги
В конечном итоге код преобразуется в небольшие проверяемые коммиты с использованием всех общих функций fwupd.
После завершения плагин объединяется с исходной версией
Код, используемый выше, будет тем же кодом в ChromeOS.
Двоичные файлы обновлений прошивки, используемые вне ChromeOS, будут распространяться в LVFS.
В случае ChromeOS, в частности:
OEM-производитель должен загрузить двоичный файл прошивки на наши серверы через CPFE.
Для работы аппаратных регрессионных тестов на LVFS по-прежнему необходимы распространяемые архивы обновлений.
Четвертый шаг (необязательно) — Добавление новых компонентов
- Если платформа fwupd уже существует, единственным дополнительным шагом является то, что поставщик обновляемых компонентов должен работать над запросами на включение, чтобы добавить особенности и VID/PID для вариантов оборудования.
Другое руководство — работа над LVFS
Создайте новую учетную запись поставщика (настройка ~ 2 минуты)
Поставщики создают пользователей для своего собственного домена или используют что-то вроде Azure AD для синхронизации учетных записей пользователей с LVFS. Они могут заливать прошивки в приват и вендор-эмбарго совершенно бесплатно с очень небольшим количеством проверок (поэтому зачастую инженеры делают это сразу с самого начала)
В конечном итоге для перехода к тестированию или стабильной версии требуется какой-то документ от их юридического отдела, в котором четко указано, что LVFS может распространять и анализировать прошивку. Руководство в формате PDF предоставлено Ричардом. ● Если поставщик является просто поставщиком микросхем или ODM, он может стать «аффилированным лицом» OEM-производителя и загружать прошивку от его имени, при этом OEM-производитель будет иметь полную информацию о том, что происходит с прошивкой, выпущенной под его именем.
Есть много других вещей, которые нужно настроить (например, идентификатор поставщика ограничивает их набором идентификаторов PCI или USB), но у большинства поставщиков уже есть назначенный идентификатор, и настройка занимает 20 секунд.
Прочие рекомендации – особенности Chrome OS
В нашем случае двоичные файлы обновлений прошивки не извлекаются напрямую из LVFS. Вместо этого CAB-файл будет храниться в локальной файловой системе (rootfs).
- Будущий рабочий процесс: включить двоичный файл прошивки в DLC, создав ebuild portage на соответствующем оверлее portage.
fwupd необходимо вызывать (через его CLI fwupdtool) в нужное время. Для каждого обновляемого компонента должно быть создано правило udev (или эквивалентный сценарий), которое генерирует событие upstart fwuptool-update. Это событие будет автоматически обработано для выполнения fwupdtool с правильными аргументами и правильной песочницей (мини-джейл).
Другой компонент решает, требуется ли пользовательский интерфейс — только при определенных обстоятельствах, в зависимости от характера обновляемого компонента. Будет оценен командой PM и Eng. Руководство более высокого уровня, как упоминалось на первом этапе, заключается в минимизации действий со стороны пользователя.
Дополнительные ресурсы для продавцов
Ссылка на внешнюю документацию: https://lvfs.readthedocs.io/
Ссылка на соглашения с внешними поставщиками: fwupd.org/lvfs/docs/agreement.
Учебное пособие по разработке плагина: https://fwupd.github.io/tutorial.html.
Руководство по отладке плагина: https://lvfs.readthedocs.io/en/latest/custom-plugin.html.
Пример файла причуды: https://github.com/fwupd/fwupd/blob/master/plugins/wacom-usb/wacom-usb.quirk
История изменений
| Дата | Версия | Примечания |
|---|---|---|
| 2025-03-12 | 1.0.2 | Конвертировать текст из pdf в уценку |
| 2024-01-31 | 1.0.1 | Републикация на новой платформе |
| 2023-10-12 | 1.0 | Первоначальная публикация |