BIOS Terms Stable

DXE Dispatcher là gì?

DXE Dispatcher load và chạy DXE driver theo DEPEX, dựa trên protocol dependency trong handle database. Hiểu dispatch loop giúp debug driver không chạy dù build pass.

10 tháng 6, 2026 Cập nhật 11 tháng 6, 2026 6 phút đọc

DXE driver không tự nhiên chạy chỉ vì file .c được build. Trong firmware image, driver nằm trong firmware volume. DXE Dispatcher scan các DXE driver, kiểm tra dependency expression (DEPEX), rồi mới gọi entry point - và nó không chạy theo thứ tự file, mà chạy theo dependency.

Dispatch loop hoạt động thế nào?

Đây là mental model quan trọng nhất của bài:

01 Scan FV

Tìm driver trong firmware volume

Đọc FFS file, tìm PE32 section và DEPEX section của từng driver.

02 Eval DEPEX

Kiểm tra dependency

Protocol trong DEPEX đã được install chưa? Nếu chưa - giữ lại để thử ở vòng dispatch sau.

03 Dispatch

Gọi entry point

Driver chạy, locate/install protocol, publish abstraction.

04 Loop

Lặp lại

Protocol mới vừa install có thể unlock driver khác đang chờ. Dispatcher tiếp tục vòng mới.

Dispatcher chạy nhiều vòng. Mỗi vòng nó thử dispatch tất cả driver còn chưa chạy. Nếu một driver install protocol mới, vòng kế tiếp có thể unlock driver khác đang chờ dependency đó. Vòng lặp kết thúc khi không còn driver nào có thể dispatch nữa.

Ví dụ dispatch loop:

Vòng 1:
  Driver A: DEPEX thỏa → dispatch → install Protocol X
  Driver B: DEPEX cần Protocol X → chưa thỏa → skip
  Driver C: DEPEX thỏa → dispatch → install Protocol Y

Vòng 2:
  Driver B: Protocol X đã có → DEPEX thỏa → dispatch
  Driver D: DEPEX cần Protocol Z → chưa thỏa → tiếp tục bị giữ lại
            Nếu không ai install Protocol Z trong dispatch loop,
            Driver D sẽ không được dispatch trong boot flow hiện tại.

DEPEX là gì và viết thế nào?

DEPEX (Dependency Expression) là điều kiện để dispatcher cho phép driver chạy. Khai báo trong section [Depex] của file .inf:

# Driver chỉ chạy khi cả hai protocol này đã được install
[Depex]
  gEfiPciIoProtocolGuid AND gEfiDevicePathProtocolGuid

# Driver chạy khi một trong hai protocol tồn tại
[Depex]
  gEfiBlockIoProtocolGuid OR gEfiBlockIo2ProtocolGuid

# Driver luôn được dispatch ngay - không có dependency
[Depex]
  TRUE

Khi build, EDK II compile [Depex] thành DEPEX section nhị phân trong firmware file. DXE Dispatcher đọc section đó lúc runtime, không phải đọc file INF.

Ba nguyên nhân phổ biến khi driver không chạy

Mục	Giá trị	Ghi chú
Có trong DSC nhưng thiếu FDF	Build được nhưng không nằm trong FV	ROM image không chứa driver - dispatcher không bao giờ thấy nó.
DEPEX chưa thỏa	Dispatcher đang chờ protocol	Entry point chưa được gọi. Protocol dependency có thể chưa được install bởi driver nào.
DEBUG level sai	Driver có chạy nhưng không thấy log	Đừng kết luận quá sớm nếu chỉ nhìn log. Kiểm tra map file hoặc thêm debug print rõ ràng.
MODULE_TYPE hoặc file type không phù hợp	Driver không được xử lý như DXE driver mong đợi	DXE_DRIVER, DXE_RUNTIME_DRIVER, UEFI_DRIVER có entry point và lifecycle khác nhau. Nếu module type, INF hoặc packaging sai, dispatcher có thể không dispatch như bạn nghĩ.

Truy ngược dependency chain

Khi driver B không chạy vì DEPEX chưa thỏa, câu hỏi đúng không phải “driver B sai ở đâu?” mà là “ai phải install protocol mà B đang chờ?”.

Driver B không chạy
  → B cần Protocol X
  → Ai install Protocol X?
  → Driver A
  → Driver A có chạy không?
  → A cần Protocol Y
  → Ai install Protocol Y?
  → ...

Nếu trace đến cuối chuỗi mà không tìm thấy ai install protocol gốc, lỗi nằm ở đó - thường là driver bị bỏ ra khỏi FDF, hoặc DEPEX của driver gốc có lỗi.

Checklist khi debug DXE Dispatcher

INF có MODULE_TYPE và file type phù hợp không (DXE_DRIVER, DXE_RUNTIME_DRIVER, UEFI_DRIVER, ...)?
INF có trong DSC để build không?
INF có trong FDF/FV để package vào image không?
DEPEX require protocol nào - protocol đó đã được install chưa?
Driver install protocol đó có chạy không - trace ngược dependency chain.
Bật debug level liên quan dispatch, ví dụ DEBUG_DISPATCH nếu platform hỗ trợ, hoặc dùng map file/FV dump để xác nhận driver có trong image.
Entry point có bị log level che mất không - thử thêm DEBUG_ERROR log rõ ràng hoặc kiểm tra bằng breakpoint/map file.

Lỗi hiểu nhầm hay gặp

Build pass không có nghĩa là driver sẽ chạy. Driver phải có trong FDF, DEPEX phải thỏa, và MODULE_TYPE phải đúng. Ba điều kiện này độc lập với việc build có lỗi hay không.

Driver không chạy không có nghĩa là driver sai. Rất thường gặp trường hợp driver đúng nhưng dependency của nó chưa được install vì driver khác bị thiếu trong FDF.

Dispatcher không chạy lại sau khi kết thúc. Nếu một protocol không bao giờ được install trong suốt dispatch loop, driver đang chờ protocol đó sẽ không bao giờ chạy - không có cơ chế retry sau khi BDS bắt đầu.

DEPEX trong DXE phụ thuộc vào Protocol đã được install trong handle database - khác với PEI, nơi DEPEX phụ thuộc vào PPI. Dispatcher của hai phase cũng hoàn toàn riêng biệt.

Câu hỏi tự kiểm tra

DXE Dispatcher dùng DEPEX để quyết định điều gì?
Vì sao driver build pass nhưng vẫn có thể không chạy?
Driver nằm trong DSC nhưng thiếu FDF thì chuyện gì xảy ra?
DEPEX trong DXE phụ thuộc vào PPI hay Protocol?
Vì sao một driver install Protocol mới có thể làm driver khác được dispatch ở vòng sau?
Nếu driver B không chạy vì thiếu Protocol X, bạn sẽ trace dependency chain như thế nào?
Khi nghi ngờ driver không được dispatch, cần kiểm tra những điểm nào?
Vì sao không nên dựa vào thứ tự file trong FDF để điều khiển thứ tự driver chạy?

Bài liên quan

Nguồn tham khảo public

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