DXE Dispatcherとは?

DXE DispatcherはDEPEXに基づいてDXEドライバーをロード・実行する。dispatch loopを理解するとビルド成功にもかかわらずドライバーが実行されない問題をデバッグできる。

2026年6月10日更新 2026年6月11日 2 分で読めます

DXEドライバーは.cファイルがコンパイルされただけでは実行されません。firmware image内でドライバーはfirmware volumeに存在します。DXE DispatcherはDXEドライバーをスキャンし、dependency expression（DEPEX）を評価してからエントリーポイントを呼び出します。ファイルの順序ではなく、依存関係の順序で実行します。

dispatch loopの仕組み

01 FVスキャン

firmware volumeからドライバーを探す

FFSファイルを読み取り、各ドライバーのPE32セクションとDEPEXセクションを探す。

02 DEPEX評価

依存関係を確認

DEPEXのプロトコルはinstall済みか? なければ次のdispatchラウンドまで保留。

03 Dispatch

エントリーポイントを呼ぶ

ドライバーが実行されてプロトコルをlocate/installし、抽象化を公開する。

04 ループ

繰り返す

新たにinstallされたプロトコルが待機中の他のドライバーをunlockする可能性がある。Dispatcherは新しいラウンドを開始する。

Dispatcherは複数ラウンド実行します。各ラウンドでまだ実行されていないすべてのドライバーを試みます。あるドライバーが新しいプロトコルをinstallすると、次のラウンドでその依存関係を待っていた他のドライバーがunlockされる可能性があります。

dispatch loop の例:

ラウンド1:
  Driver A: DEPEX満足 → dispatch → Protocol X をinstall
  Driver B: Protocol X が必要 → 未満足 → スキップ
  Driver C: DEPEX満足 → dispatch → Protocol Y をinstall

ラウンド2:
  Driver B: Protocol X が存在 → DEPEX満足 → dispatch
  Driver D: Protocol Z が必要 → 未満足 → 保留継続

DEPEXとは何か、どう書くか

DEPEX（Dependency Expression）はDispatcherがドライバーの実行を許可するための条件です。.infファイルの[Depex]セクションで宣言します。

# 両方のプロトコルがinstall済みの場合のみ実行
[Depex]
  gEfiPciIoProtocolGuid AND gEfiDevicePathProtocolGuid

# どちらかのプロトコルが存在する場合に実行
[Depex]
  gEfiBlockIoProtocolGuid OR gEfiBlockIo2ProtocolGuid

# 依存関係なし、常に即時dispatch
[Depex]
  TRUE

ドライバーが実行されない3つの主な原因

項目	値	メモ
DSCにあるがFDFにない	ビルドは成功するがFVに含まれない	ROMイメージにドライバーが含まれていない — Dispatcherが認識しない。
DEPEXが未満足	Dispatcherがプロトコルを待機中	エントリーポイントが呼ばれていない。依存プロトコルがどのドライバーにもinstallされていない可能性がある。
DEBUGレベルが不正	ドライバーは実行されたがログが見えない	ログだけで早期に判断しないこと。mapファイルを確認するか明確なdebug printを追加する。
MODULE_TYPEまたはファイルタイプが不正	ドライバーが期待通りに処理されない	DXE_DRIVER、DXE_RUNTIME_DRIVER、UEFI_DRIVERは異なるエントリーポイントとライフサイクルを持つ。

依存関係チェーンを逆にたどる

Driver BのDEPEXが未満足で実行されない場合、正しい問いは「Driver Bの何が間違っているか?」ではなく「Bが待っているプロトコルを誰がinstallすべきか?」です。

Driver B が実行されない
  → B は Protocol X が必要
  → 誰が Protocol X をinstallするか?
  → Driver A
  → Driver A は実行されたか?
  → A は Protocol Y が必要
  → ...

DXE Dispatcherデバッグのチェックリスト

INFのMODULE_TYPEとファイルタイプは正しいか (DXE_DRIVER、DXE_RUNTIME_DRIVER、UEFI_DRIVERなど)?
INFはビルドされるためDSCにあるか?
INFはイメージにパッケージするためFDF/FVにあるか?
DEPEXが要求するプロトコルはinstall済みか?
それらのプロトコルをinstallするドライバーは実行されたか — 依存関係チェーンを逆にたどる。
mapファイルまたはFV dumpでドライバーがイメージに含まれていることを確認したか?

よくある誤解

ビルド成功はドライバーが実行されることを意味しない。 ドライバーはFDFになければならず、DEPEXが満足されなければならず、MODULE_TYPEが正しくなければならない。これら3つの条件はビルドの成否とは独立しています。

ドライバーが実行されないことはドライバーが間違っていることを意味しない。 正しいドライバーでも依存関係が別のドライバーの欠如によりinstallされていないために実行されないことはよくあります。

DispatcherはDEPEXでProtocol依存に基づく — PEIとは異なりPPIではない。 2つのphaseのDispatcherも完全に別個です。

自己確認の質問

DXE DispatcherはDEPEXを使って何を決定するか?
ビルドが成功してもドライバーが実行されない理由は?
DSCにあるがFDFにないドライバーはどうなるか?
DXE DEPEXはPPIとProtocolのどちらに依存するか?
あるドライバーが新しいProtocolをinstallすることで、次のラウンドで別のドライバーがdispatchされる理由は?

公開参照資料

Nội dung liên quan

Một số bài viết, ghi chú hoặc project có liên quan đến nội dung bạn vừa đọc.

Biến note thành bài viết hoàn chỉnh

Notes là nơi ghi nhanh khái niệm.

Đọc blog Xem notes khác