Firmware Execution Flow とは何か

UEFI firmware の実行フローを reset vector, SEC, PEI, DXE, BDS, TSL, runtime まで実務目線で整理します。

2025年10月28日更新 2026年6月19日約 4 分

Firmware execution flow は、CPU が reset 後に動き始めてから、OS に制御を渡すまでの流れです。UEFI では、主に Reset Vector、SEC、PEI、DXE、BDS、TSL、そして ExitBootServices() 後の runtime という単位で見ると理解しやすいです。

短く言うと、firmware flow は BIOS 全体を黒箱として見るのではなく、どの段階で失敗しているかを切り分けるための地図です。

マシンが boot しない時、最初から「BIOS のどこが悪いか」と考えるより、次のように分けて考えます。

CPU は reset vector から先に進んだか？
SEC は temporary RAM を作れたか？
PEI は memory init と HOB 作成を完了したか？
DXE dispatcher は driver を dispatch したか？
BDS は正しい Boot#### を選んだか？
OS loader は ExitBootServices() に成功したか？

全体の流れ

Power On / Reset
  -> Reset Vector
  -> SEC
  -> PEI
  -> PEI to DXE Handoff
  -> DXE
  -> BDS
  -> TSL
  -> ExitBootServices
  -> Runtime Services

それぞれの段階には役割があります。Reset Vector は CPU が最初に実行する場所です。SEC は最小限の実行環境を作ります。PEI は memory と HOB を準備します。DXE は driver を load し、protocol を publish します。BDS は boot option を選びます。TSL では OS loader が Boot Services の下で動きます。ExitBootServices() 後は OS が memory を管理し、firmware 側は Runtime Services だけが残ります。

なぜ flow が重要か

実際の BIOS log は十分でないことが多いです。Flow を知らないと、違う層を debug してしまいます。たとえば「boot option が見えない」場合、BDS の問題かもしれませんが、DXE driver が BlockIo や SimpleFileSystem を publish していない可能性もあります。Runtime Services の crash は BDS ではなく、memory map、runtime descriptor、SetVirtualAddressMap()、ConvertPointer() が関係することが多いです。

Flow で見ると、失敗を次のように分類できます。

No serial log        -> reset vector / SEC / serial init
Memory init fail     -> PEI
Driver not loaded    -> DXE dispatcher / DEPEX / FDF placement
Device not visible   -> Driver Binding / protocol install
Boot option ignored  -> BDS / NVRAM / Device Path
EBS fail             -> memory map key / allocation timing
Runtime crash        -> runtime memory / virtual address change

混同しやすいポイント

EndOfDxe は ExitBootServices() ではありません。EndOfDxe は DXE が終わりに近づき、boot policy に進む前後で使われる firmware event です。ExitBootServices() は OS loader が Boot Services を終了するために呼ぶ API です。

BDS は OS loader ではありません。BDS は boot option を選び、LoadImage() と StartImage() を呼びます。TSL は OS loader または boot application が Boot Services の下で動いている段階です。

DXE driver の EntryPoint が動いたことは、device が使えることを意味しません。Driver Binding driver では、Supported() と Start() が controller に bind できたかどうかを決めます。

Flow に沿った debug

Firmware debug では、「どの checkpoint の後で失敗しているか」を書き出すと切り分けが速くなります。

SEC log はあるが PEI memory log がないか？
PEI HOB はあるが DXE Core が見えないか？
DXE Core はあるが driver dispatch がないか？
Block I/O はあるが Simple File System がないか？
Boot#### はあるが LoadImage が EFI_NOT_FOUND を返すか？
ExitBootServices が EFI_INVALID_PARAMETER を返すか？
SetVirtualAddressMap 後に Runtime Service が crash するか？

構造なしに大量の log を読むより、この見方の方が早く原因に近づけます。

Source-reading checklist

Firmware flow の source を読む時は、次の順番で確認します。

1. Reset code と SEC entry は動いているか？
2. Temporary RAM または CAR は設定されたか？
3. PEI は有効な HOB list を作ったか？
4. DXE IPL は DXE Core を見つけて jump したか？
5. Module は本当に FV に入っているか？
6. DEPEX で module が止まっていないか？
7. Driver Binding の Supported()/Start() は成功したか？
8. BDS は BootOrder/Boot#### を正しく読んだか？
9. LoadImage/StartImage の status は何か？
10. OS loader は GetMemoryMap/ExitBootServices をどう呼んだか？

まとめ

Firmware execution flow は、UEFI の log と source を読むための地図です。Reset vector、SEC、PEI、DXE、BDS、TSL、runtime を理解すると、「BIOS が boot しない」という曖昧な問題を、memory init 前の問題なのか、driver dispatch なのか、boot option selection なのか、OS に制御を渡した後なのかに分けて考えられます。