各ファームウェア更新パッケージには、ファームウェア ペイロード全体 (firmware.bin など) と、Windows がfirmware.binの検証に使用するセキュリティ カタログを含む 1 つのバイナリ ファイルが含まれています。 セキュリティ カタログとドライバーの詳細については、「 カタログ ファイルとデジタル署名 」および 「PnP ドライバー パッケージのカタログ ファイルの作成」を参照してください。
ファームウェア更新パッケージは、次の種類のファームウェアを 1 つ以上更新できる必要があります。
UEFI システム ファームウェア。
システム内の 1 つのデバイスのファームウェア。
各ファームウェア更新プログラム パッケージは、1 つのファームウェア リソース (UEFI システム ファームウェアまたは 1 つのデバイス) を対象とすることをお勧めしますが、システム ファームウェアと 1 つ以上のデバイスの両方を更新する 1 つのファームウェア更新プログラム パッケージを用意する方が有利な場合があります。
デバイスを複数のファームウェア更新プログラム パッケージの対象にすることはできません。 デバイスが、システム ファームウェアも含むファームウェア更新プログラム パッケージの対象になっている場合、デバイスのみを対象とする 2 つ目のファームウェア更新パッケージの対象にすることはできません。
ファームウェア更新プログラム パッケージが適切なシステム ハードウェアへのファームウェア更新プログラムを対象とすることを許可するために、Windows は ESRT 内の各エントリのデバイス インスタンスを表示します。この場合、このようなデバイス インスタンスは、ESRT エントリに属していることを識別するハードウェア ID を公開します。
ファームウェア更新プログラム パッケージがインストールされると、ドライバー パッケージとして Windows によって処理されます。 Windows は、各更新プログラム パッケージのファームウェア ペイロードをシステム ディレクトリの下の安全な場所にコピーし、ファームウェアの更新を実行するようにシステムを準備し、システムの再起動をトリガーします。
Windows では、ドライバー パッケージ間の依存関係はサポートされていません。 そのため、新しいファームウェア更新プログラム パッケージを作成するときは、次の要件を満たす必要があります。
ファームウェア更新プログラム パッケージは、他のデバイス ファームウェア、システム ファームウェア、またはその他のファームウェア更新プログラム パッケージに依存することなく、単独で正常にインストールできる必要があります。
各更新プログラム パッケージは、システム上の単一のデバイスまたは UEFI システム ファームウェア (ESRT で定義) を対象とすることをお勧めします。
各更新プログラム パッケージには、1 つのファームウェア更新プログラム バイナリ (firmware.bin など) が含まれている必要があります。
各更新パッケージのファームウェア更新ペイロードは、1 つのバイナリ ファイルに含まれている必要があります。 システムの再起動時に、OS ローダーは各ファームウェア更新プログラム パッケージの各ファームウェア更新バイナリ ファイルを物理メモリに読み込み、インストール用にプロビジョニングされた各ペイロード ファイルへのポインターの配列を構築します (UEFI 2.3.1 仕様では、この配列は CapsuleHeaderArray と見なされます)。
この配列は EFI UpdateCapsule() 関数の呼び出しで渡されます。 UpdateCapsule() はメールボックスとして使用され、各ドライバー パッケージのファームウェア更新ペイロードがプラットフォーム ファームウェアに渡されます。
各カプセル (ファームウェア更新ペイロード) は、ファームウェア リソースの ESRT エントリで指定されたファームウェア ID によって識別されます。
各ファームウェア更新ペイロードを受信すると、ファームウェア更新要求が処理され、該当する場合に適用されます。
CapsuleHeaderArray の各エントリは、システム内の 1 つのデバイスのファームウェア ドライバー パッケージからのファームウェア更新ペイロードを含むデータの 1 つの連続したブロックです。 対象となるファームウェア リソースごとに、ファームウェアの更新ペイロードには、ファームウェア イメージと、検証のためにプラットフォームに必要なすべての情報が含まれている必要があります。
すべてのファームウェア更新ドライバー パッケージのファームウェア ペイロードは、UEFI UpdateCapsule サービスを介してプラットフォーム ファームウェアに渡されます。 統合デバイスはさまざまな IHV から供給されるため、システム OEM (および場合によっては SoC 製造元) は、これらの IHV と直接連携して、特定のシステムに対してデバイス ファームウェアの更新プログラムが適切に作成されるようにする必要があります。 さらに、システム OEM は、ESRT エントリで UpdateCapsule パッケージが適切なシステムを対象とすることを確認する必要があります。
たとえば、複数の OEM が、システムに同じモデルのモバイル ブロードバンド (MBB) デバイスを選択する場合があります。 MBB デバイスは各システムで同じですが、各 OEM は MBB IHV と共同作業して、システム用にカスタマイズされたファームウェア更新プログラム パッケージを作成する必要があります。 このレベルのデバイス ファームウェア更新プログラムのカスタマイズは、OEM システム全体の変数に対処するために必要です。
デバイスのアドレス指定は、OEM によって選択された SoC と、デバイスが SoC に接続される方法によって異なる場合があります。
システム OEM は、コンシューマーに再販するために、複数のモバイル ネットワーク オペレーター (MNO) にシステムを販売する場合があります。 MBB デバイスは MNO 対応である必要があります。ファームウェアは、特定の MNO の要件に合わせてカスタマイズおよび認定されている必要があります。
このシステムは世界中の複数の市場で販売される可能性があり、それぞれに異なる RF 規制と無線周波数の割り当てがあります。 MBB デバイス ファームウェアでは、これらの市場要件を満たすためにカスタマイズが必要になる場合があります。
各 OEM は、このようなデバイス固有の要件を慎重に検討し、デバイス ファームウェアをターゲットにして適切に更新できるようにするために必要な手順を実行する必要があります。 これには、デバイス ファームウェアを適切に展開できるようにするために、ESRT エントリを慎重に管理する必要があります。
更新プログラム パッケージを作成したら、認定と署名のために Microsoft に提出する必要があります。