Fwupd ファームウェア アップデート統合ハンドブック

バージョン: 1.0.2
最終更新日: 2025-03-12

要約

このドキュメントは、ベンダーが今後のプロジェクトで fwupd を実装する方法のチュートリアルを目的としています。LVFS のメンテナーから直接引用された分析情報も含まれています。Fwupd はオープンソースのファームウェア更新フレームワークで、外部ベンダーと連携してファームウェアの更新方法を統一するのに役立ちます。

ステップ 1 - 情報を収集してガイダンスを提供する

ベンダー向け - 最初の質問:

  • 更新可能なコンポーネントに関する質問

    • 更新サイズ

    • 更新日時

    • 既存の更新タイプ（A/B またはブートローダー/ランタイム モデル）

    • 更新中にコンポーネントの機能はどうなりますか？

    • アップデートが正常に完了して使用を開始するには、システムに何が必要ですか？

    • 複数のコンポーネントを特定の順序でインストールする必要がありますか？

  • LVFS/fwupd の操作に慣れている、または知識がある

  • プラグインの実装を支援するためにエンジニア リソースをコミットする能力（詳細については下記を参照）

  • LGPLv2+ へのプラグインのオープンソース化（コンポーネントにファームウェアを書き込成するコード）と、LVFS によるファームウェアの再配布を許可するコミットメント

ベンダー向け - 最初のガイダンス:

  • 更新により、周辺機器または内部コンポーネントの機能に影響する時間を最小限に抑える必要があります（理想的には数秒）。アップデートの長い部分は、ユーザーの邪魔にならないようにバックグラウンドでサイレント実行する必要があります。

    • この周辺機器がユーザー エクスペリエンスに明らかな影響を与える場合（ディスプレイが機能しなくなるなど）は、この要件がさらに厳しくなります。

  • このタイプのサイレント アップデートを有効にするには、A/B アップデートを強くおすすめします。

    • 周辺機器のプラグを抜いたときに有効にできる A/B アップデートは、ユーザーの操作を最小限に抑えるのに最適です。

  • 更新は復元可能である必要があります。電源を切ったり、周辺機器のプラグを抜いたりしても、デバイスや周辺機器が動作しなくなるようなことはあってはなりません。ユーザーの操作なしで復元できる堅牢性が必要です。

    • 更新全体でユーザー操作が行われないことを前提とし、適切なスクリプトと更新ステージを自動的に実行する必要があります。

ステップ 2 - fwupd を使用する

ベンダーが fwupd を使用したことがない

  • ChromeOS は、fwupd を介したファームウェア アップデートの要件を OEM に提供します。OEM は、このことをチップ / コンポーネント サプライヤーに直接伝える必要があります。

  • 場合によっては、ODM が OEM がチップ ベンダーと直接やり取りするのをサポートします。これらの要件を適切に伝えるのは OEM の責任です。

  • LGPLv2 以上のライセンスでソースコードを提供する場合、通常、このコードからプラグインを派生させることは現実的ではありません（複雑な問題が多いため）。したがって、このシナリオでは、チップ ベンダーが fwupd のメンテナンス担当者と Google エンジニアと連携できる担当者を用意する必要があります。

  • OEM は、メンテナンス担当者と緊密に連携することをチップ ベンダーに約束させるために、積極的に働きかけることができます。ベンダー側のエンジニアリング サポートには、次の要件があります。

    • 更新可能なハードウェア コンポーネントの癖や設計機能に精通している（ファームウェアを作成したチームに所属しているほうが望ましい）

    • 一般的なオープンソース ライセンス（LGPLv2 や MIT など）の違いを理解する

    • C に精通しており、GLib と GObject の基本的な知識を持ち、特に GErrors も理解している

    • GitHub アカウントを持ち、pull リクエストを開いて更新する方法、GitHub コードレビューを行う方法、fwupd が提供するすべてのヘルパー（チャンキング、接続/切断、デバイスの再試行、HID など）を使用して fwupd がどのように構成されているかを理解している

    • 省略可: ハードウェア サンプルを英国に送信する機能 - fwupd メンテナンス担当者がベンダーの問題のデバッグに役立つほか、各リリースで実行される fwupd テストにボードを追加するのに非常に便利です。後者は、開発ブランチの回帰を停止するために重要です。

  • 並行して、OEM は fwupd メーリング リストまたは Richard Hughes（hughsient@gmail.com）に直接連絡し、プラグイン コードを記述する前に計画を確認できます。

  • エンジニアリング リソースやオープンソースの理解がほとんどない小規模な企業の場合は、次の提案が役立つ場合があります。

    • コンポーネント ベンダーは、オープンソースの作業に精通したコンサルティング会社を利用できます（追加費用は発生しません）。

    • この方法はスケーリングに役立ちますが、ベンダーが社内で行うメリットは、エンジニアがプロセスに精通し、将来、新しいハードウェアに VID/PID を簡単に追加できることです。また、ハードウェアでデバッグする質問や問題をクローズする時間も短縮されます。

ステップ 3 - 最終ステップ

  • 最終的に、コードは fwupd の共有機能すべてを使用して、レビュー可能な小さなコミットにリファクタリングされます。

  • 完了すると、プラグインはアップストリームに統合されます。

    • アップストリームで使用されるコードは ChromeOS のコードと同じ

    • ChromeOS の外部で使用されるファームウェア更新バイナリは LVFS に配布されます。

ChromeOS の場合:

  • OEM は、CPFE 経由でファームウェア バイナリを Google のサーバーにアップロードする必要があります。

  • ハードウェア リグレッション テストを実行するには、LVFS に再配布可能なアップデート キャビネット アーカイブが必要です。

ステップ 4（省略可）- 新しいコンポーネントを追加する

  • fwupd フレームワークがすでに導入されている場合、追加の手順は、更新可能なコンポーネント サプライヤーがプル リクエストでハードウェア バリアントの Quirk と VID/PID を追加することのみです。

その他のガイダンス - LVFS での作業

  • 新しいベンダー アカウントを作成する（設定に 2 分ほどかかります）

  • ベンダーは、独自のドメインのユーザーを作成するか、Azure AD などのツールを使用してユーザー アカウントを LVFS と同期します。限定公開とベンダー制限付きのファーウェアを、ほとんどチェックなしで完全に無料でアップロードできます（そのため、多くの場合、エンジニアが最初からこの作業を行います）。

  • 最終的にテスト版または安定版にプッシュするには、LVFS がファームウェアを再配布して分析できることを明記した、法務部門からの何らかのドキュメントが必要です。PDF ガイドラインはリチャードから提供されます。● ベンダーがシリコン サプライヤーまたは ODM のみの場合は、OEM の「アフィリエイト」になり、OEM に代わってファームウェアをアップロードできます。OEM は、自分の名前がブランド付けされたファームウェアの状況を完全に把握できます。

  • 設定する項目は他にもたくさんありますが（ベンダー ID は PCI ID または USB ID のセットのみに制限されます）、ほとんどのベンダーにはすでに ID が割り当てられているため、設定に 20 秒しかかかりません。

その他のガイダンス - ChromeOS 固有の部分

  • Google の場合、ファームウェア アップデートのバイナリは LVFS から直接 pull されません。代わりに、CAB ファイルはローカル ファイル システム（rootfs）に保存されます。

    • 今後のワークストリーム: 適切な portage のオーバーレイに portage ebuild を作成して、DLC にファームウェア バイナリを組み込む

  • fwupd は、適切なタイミングで（CLI fwupdtool を介して）呼び出す必要があります。更新可能なコンポーネントごとに、fwuptool-update upstart イベントを出力する udev ルール（または同等のスクリプト）を作成する必要があります。このイベントは自動的に処理され、正しい引数と適切なサンドボックス（minijail）を使用して fwupdtool が実行されます。

  • 別のコンポーネントは、更新されるコンポーネントの性質に応じて特定の状況でのみ、UI が必要かどうかを判断します。PM チームとエンジニアリング チームが評価します。最初のステップで説明したように、より一般的なガイダンスは、ユーザー側のアクションを最小限に抑えることです。

ベンダー向けのその他のリソース

  • 外部ドキュメントのリファレンス: 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 から Markdown に変換する
2024-01-31 1.0.1 新しいプラットフォームでの再公開
2023-10-12 1.0 初公開