Reset Vector とは何か

Reset vector の意味、reset 後に CPU がどこから実行を始めるか、early boot debug の見方を整理します。

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

Reset Vector は、reset 後に CPU が最初に実行する address です。Firmware では、SEC より前、PEI より前、memory init より前、通常の UEFI service より前にある最初期の入口です。

短く言うと、reset vector は CPU が起きて firmware に入る場所です。

x86 系では、CPU は物理 address 空間の上の方から実行を始め、firmware は小さな reset stub を使って本当の early initialization code へ jump します。

Reset
  -> CPU が reset vector から instruction を fetch
  -> reset stub が動く
  -> 最小限の CPU state を準備
  -> SEC / early firmware entry へ jump

Reset Vector は BIOS main ではない

Firmware を読む時、reset vector を BIOS の main function のように考えると誤解しやすいです。実際には、reset vector は CPU を reset state から firmware の通常 flow に入れるための小さな code であることが多いです。

この時点では普通、次のものはまだありません。

安定した DRAM
UEFI Boot Services
protocol database
通常の heap / pool
十分な log
完全な C runtime

そのため、reset vector 周辺の code は非常に慎重に書く必要があります。Memory、stack、serial log、通常 library が使えると仮定してはいけません。

Reset stub は何をするか

Architecture や platform によりますが、reset stub は次のような処理を行います。

最小限の CPU mode 設定
temporary stack または一時領域の準備
reset address から実際の firmware volume へ jump
SEC entry の準備
reset type や bootstrap processor state の処理
必要なら early microcode や chipset state の設定

重要なのは、reset vector は入口にすぎないという点です。Firmware logic の多くはその後の phase にあります。

なぜ debug が難しいか

この段階では log がほとんどありません。Serial がまだ init されていない、DRAM がない、exception handler が準備されていない、という状態が普通です。ここで失敗すると、外からは log が出ない、PEI に入らない、非常に早い reset loop に見えます。

よくある症状は次の通りです。

最初の serial log がない
PEI memory init log がない
debugger が見慣れた symbol に到達しない
board が非常に早い段階で reset を繰り返す
emulator が reset address 付近で止まる

この時は、CPU が code を fetch できていないのか、fetch はできているが間違った場所へ jump しているのかを分けて考えます。

Firmware image との関係

Reset vector は firmware image 内の有効な code を指している必要があります。FDF layout、flash descriptor、BIOS region mapping、reset vector placement が間違っていると、CPU は不正な data を instruction として読む可能性があります。Early boot debug では source だけでなく binary layout も見る必要があります。

確認する点は次の通りです。

Reset vector は期待した image offset にあるか？
BIOS region は正しく map されているか？
Reset/SEC code を含む FV は正しい場所にあるか？
Flash read は有効な data を返しているか？
Jump target address は正しいか？

Source-reading checklist

Reset vector path を読む時は、次を確認します。

1. Assembly の reset stub はどこにあるか？
2. FDF または image layout は reset code をどこに置いているか？
3. Reset 後、CPU はどの physical address から始まるか？
4. Reset stub はどの symbol へ jump するか？
5. Stack または temporary storage はどう扱うか？
6. DRAM への依存が紛れ込んでいないか？
7. 最初の serial log はどの時点で有効になるか？
8. SEC entry に control が届くか？

まとめ

Reset Vector は firmware execution flow の本当の出発点です。Log がない、PEI に入らない、非常に早い reset loop がある場合は、reset vector と reset stub を先に確認します。この部分を理解すると、まだ最初の数 instruction で止まっているのに DXE や BDS を debug してしまう失敗を避けられます。