DXE Dispatcherとは？

DXE Dispatcher は、Firmware Volume の中にある DXE driver を探し、依存関係を確認してから、その driver の entry point を呼び出す DXE Core の一部です。PEI が DXE Core まで制御を渡したあと、DXE module を順番に動かす役割を持ちます。

短く言うと、DXE Dispatcher は「どの driver を、いつ実行してよいか」を決める仕組みです。

Firmware flow の中での位置

簡単に見ると、流れは次のようになります。

Reset Vector
SEC
PEI
PEI to DXE Handoff
DXE Core
  DXE Dispatcher
  Driver EntryPoint
  Protocol Database
BDS
TSL
Runtime

DXE Dispatcher は BDS ではありません。BDS より前に動き、BDS が boot option を選ぶために必要な driver、protocol、service の土台を作ります。

Dispatcher は何を見ているか

DXE driver は、source に存在するだけでは実行されません。通常は次の条件が必要です。

Module が DSC で build 対象になっている
Module が FDF によって firmware image に入っている
Module を含む Firmware Volume を DXE が見つけている
Module の DEPEX が満たされている
DXE Dispatcher が EntryPoint を呼ぶ
EntryPoint が正しい status を返す

source tree や build output に module があるだけで、実際の BIOS image に入っているとは限りません。また、FV に入っていても、DEPEX が満たされなければ dispatch されないことがあります。

DEPEX の影響

DEPEX は dependency expression のことです。driver を実行する前に、どの protocol や条件が必要かを dispatcher に伝えます。たとえば storage driver は PCI I/O Protocol を必要とし、network driver は bus driver が作った controller handle を必要とする場合があります。

依存関係がまだ足りない場合、dispatcher はその driver を待機状態にします。新しい protocol が install されると、待機中の driver が再評価されることがあります。

EntryPoint と Start() は違う

DXE Dispatcher が呼ぶのは module の entry point です。UEFI Driver Binding driver の場合、entry point は多くの場合 EFI_DRIVER_BINDING_PROTOCOL を install するだけです。driver が controller に実際に bind するのは、ConnectController() が Supported() と Start() を呼んだときです。

そのため、失敗箇所を次のように分けます。

EntryPoint が動かない: DSC, FDF, FV, DEPEX, dispatcher を確認
EntryPoint は動くが device が出ない: Driver Binding, Supported, Start, ConnectController を確認

よくある debug 例

実務では次のような問題があります。

Storage driver は build できている
FV dump でも driver が見える
Shell で fs0: が出ない
BDS が boot disk を見つけない

このとき、すぐ storage の処理ロジックだけを見るのは危険です。まず driver が dispatch されたか、entry point の log があるか、DEPEX で止まっていないか、Driver Binding Protocol が install されたか、Start() が呼ばれたかを確認します。

何を log するか

DXE Dispatcher を debug するときは、層ごとに log を見ます。

Firmware Volume は discover されたか
Driver の File GUID は FV にあるか
DEPEX section は何か
依存する protocol は install されたか
EntryPoint は呼ばれたか
EntryPoint の return status は何か
Driver Binding Protocol は install されたか

dispatcher 近くの log があると、device driver 側を誤って追い続けることを避けられます。

Source-reading checklist

DXE Dispatcher まわりの source を読むときは、私はだいたい次の順で見ます。

1. INF: module type, file GUID, entry point, depex
2. DSC: module が build されるか
3. FDF: module が FV に入るか
4. FV dump: 実際の BIOS image に module があるか
5. DEPEX: dependency が満たされるか
6. EntryPoint: log や side effect があるか
7. Driver Binding: entry point 後に device が ready にならない場合

まとめ

DXE Dispatcher は、firmware image 内の DXE module を実際に実行される code に変える部分です。driver が動かないときは、module が image に入っているか、dispatcher が entry point を呼んだか、driver が controller に bind できたかを分けて確認する必要があります。

この記事が役に立ったら

ファームウェア、BIOS/UEFI、組み込みシステムを学んでいる人に共有したり、作者を応援したりできます。

共有 ご意見 ☕ 応援

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.

Ghi chú/BIOS Terms

DXE Dispatcherとは

DXE Dispatcherは、DEPEXとprotocol依存関係を見ながらDXE driverを実行する仕組みです。driverが起動しない原因分析に直結します。

2026年6月10日読む →

Ghi chú/Firmware Flow

Driver Binding Flowとは？

UEFI DXEのDriver Binding Flowを説明します。Supported、Start、Stop、ConnectController、protocol ownership、bind失敗時のdebugを扱います。

2025年10月28日読む →

Ghi chú/Driver Types

UEFI Driver ModelにおけるStart()とは?

Start()はドライバーがコントローラーにバインドする場所。BY_DRIVERでのopen、プロトコルのinstall、バスドライバーの子ハンドル作成。失敗時のクリーンアップとハンドルデータベースを汚すアンチパターンを解説。

2026年6月11日読む →

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