Reset Vector là gì?

Khi bạn bấm nút nguồn, CPU không tự nhiên biết DRAM ở đâu, disk ở đâu, OS nằm ở đâu hay BootOrder là gì. CPU chỉ biết một điều rất nhỏ: sau reset, nó phải bắt đầu fetch instruction từ một địa chỉ cố định hoặc một reset entry do kiến trúc quy định.

Địa chỉ hoặc entry point đầu tiên đó thường được gọi là reset vector.

Nói ngắn gọn: reset vector là điểm bắt đầu thực thi firmware sau khi CPU reset.

Ở thời điểm reset vector:

• Chưa có DXE
• Chưa có Boot Services
• Chưa có protocol
• Chưa có Handle Database
• Chưa có BDS
• Chưa có BootOrder
• Chưa có filesystem
• DRAM có thể chưa dùng được
• Log có thể chưa có
• Stack bình thường có thể chưa sẵn sàng

Vì vậy reset vector là vùng rất nhỏ nhưng cực kỳ quan trọng. Nếu code không đi qua được đoạn này, toàn bộ UEFI flow phía sau sẽ không bao giờ xuất hiện.

Reset vector nằm ở đâu trong firmware flow?

Power On / Reset
├─ Reset Vector
│  └─ CPU fetch instruction đầu tiên
├─ SEC
│  └─ Thiết lập môi trường tối thiểu
├─ PEI
│  └─ Khởi tạo memory, HOB, silicon cơ bản
├─ DXE
│  └─ Driver dispatch, protocol, services
├─ BDS
│  └─ Boot option, device connect, LoadImage
├─ OS Loader
│  └─ GetMemoryMap, ExitBootServices
└─ Runtime
└─ OS dùng runtime services nếu cần

Nếu ví firmware flow như một cuốn sách, reset vector là chữ đầu tiên mà CPU đọc.

Reset vector giải quyết câu hỏi gì?

Reset vector trả lời các câu hỏi nền tảng:

CPU reset xong làm gì?

Mỗi kiến trúc CPU có quy tắc reset riêng. Nhưng mental model chung là:

Reset asserted
  -> CPU registers về trạng thái reset-defined
  -> CPU bắt đầu fetch instruction từ reset vector/reset entry
  -> Firmware early code chạy
  -> SEC tạo môi trường tối thiểu
  -> PEI/DXE/BDS tiếp tục flow

Vì sao CPU có thể chạy code khi DRAM chưa sẵn sàng?

Đây là điểm người mới học BIOS rất dễ thắc mắc.

Sau reset, DRAM thường chưa được training/init đầy đủ. Nhưng CPU vẫn có thể fetch instruction từ firmware flash/ROM mapping. Code đầu tiên phải chạy trong điều kiện rất hạn chế, sau đó dùng các kỹ thuật như temporary stack, cache-as-RAM hoặc SRAM nội bộ, tùy platform, để tạo môi trường chạy tạm trước khi DRAM sẵn sàng.

Reset vector và firmware flash mapping

Để CPU fetch được instruction đầu tiên, firmware image phải được đặt và map đúng trong không gian địa chỉ mà CPU thấy sau reset.

Trong nhiều platform PC, firmware được lưu trong SPI flash. Chipset/SoC mapping logic làm cho vùng flash xuất hiện tại địa chỉ mà CPU reset fetch. Sau đó early code có thể nhảy vào firmware volume thật.

Reset vector không phải UEFI phase

Reset vector không phải một phase UEFI như PEI/DXE/BDS. Nó là điểm bắt đầu thực thi, sau đó platform mới chuyển dần vào SEC và PEI.

Code ở reset vector thường làm gì?

Code ngay tại reset vector thường là assembly hoặc rất gần assembly. Nó không làm nhiều việc phức tạp. Nhiệm vụ chính là chuyển từ “CPU vừa reset” sang “có thể chạy SEC/PEI”.

Reset Vector / Early Code
├─ Basic CPU setup
│  ├─ mode/state setup
│  └─ disable/enable feature tối thiểu
├─ Temporary execution setup
│  ├─ temporary stack
│  └─ cache-as-RAM hoặc temporary memory
├─ Firmware discovery
│  ├─ locate SEC/PEI entry
│  └─ verify firmware volume nếu có
├─ Early debug
│  ├─ POST code checkpoint
│  └─ very early serial/GPIO nếu support
└─ Handoff
├─ jump to SEC/PEI Core
└─ pass minimal context

Reset vector và SEC handoff

Mục tiêu thực tế của reset vector là đưa control tới SEC. SEC tiếp tục thiết lập môi trường tối thiểu rồi chuyển PEI.

Nếu reset vector jump sai, SEC không bao giờ chạy. Nếu SEC setup temporary memory sai, PEI có thể không chạy hoặc crash rất sớm.

Reset vector và Boot Guard / verified boot early

Trên một số platform, quá trình early boot có thể liên quan tới cơ chế verify/measure firmware trước hoặc trong khi early code chạy. Tùy platform, nếu firmware image không hợp lệ, boot có thể dừng rất sớm.

Debug signal ở reset vector

Ở giai đoạn này, debug signal rất hạn chế.

POST code trong early boot

POST code là cách firmware ghi checkpoint ra port, GPIO, I/O hoặc debug register để người debug biết code đã đi tới đâu.

Ví dụ mental model:

0x10: reset vector reached
0x11: early CPU setup done
0x12: temporary stack ready
0x13: SEC entry reached
0x20: PEI Core entered
0x30: memory init start
0x31: memory init done

Early serial: tốt nhưng đừng quá tin

Early serial rất hữu ích, nhưng serial output ở reset/SEC/early PEI có nhiều giới hạn:

• UART base address có thể chưa config
• Clock chưa setup đúng
• GPIO mux chưa đúng
• MMIO access chưa stable
• Serial init có thể phụ thuộc silicon init
• Log quá dài có thể làm timing thay đổi
• Print function có thể cần stack/buffer

Reset vector bug thường gặp

Reset loop: debug thế nào?

Reset loop sớm là một triệu chứng khó chịu. Hệ thống cứ reset trước khi vào log đầy đủ.

Reset vector và firmware image layout

Firmware image cần có layout đúng để CPU entry và các firmware volume được tìm thấy.

Firmware Image
├─ Boot Block / Reset Vector area
│  ├─ Reset stub
│  └─ SEC entry / jump target
├─ PEI Firmware Volume
│  ├─ PEI Core
│  ├─ Memory PEIM
│  └─ Silicon PEIMs
├─ DXE Firmware Volume
│  ├─ DXE Core
│  ├─ DXE drivers
│  └─ BDS modules
├─ Variable Store region
│  └─ NVRAM variables
├─ Microcode / ACM / platform blobs
│  └─ Tùy platform
└─ Recovery / capsule / other regions
└─ Tùy thiết kế firmware

Reset vector trong source tree nên tìm gì?

Trong EDK II hoặc firmware project thực tế, reset vector/SEC code có thể nằm trong package kiến trúc/platform. Tên file phụ thuộc project, nhưng khi đọc source, hãy tìm các nhóm:

Debug Diary: Không có bất kỳ log nào

Triệu chứng:

Power on
Fan quay
Không serial log
Không vào BIOS Setup
Không POST screen

Đừng nhảy ngay tới DXE/BDS. Hãy đi từ reset vector.

Debug Diary: Có POST đầu nhưng không vào PEI

Triệu chứng:

POST 0x10 visible
POST 0x11 visible
Không thấy POST 0x20 PEI entry

Điều này nói CPU đã fetch reset vector và early code chạy được một phần. Root cause có thể nằm ở handoff SEC/PEI.

Debug Diary: Build image mới làm brick board

Bạn chỉ thay đổi firmware image layout hoặc build config, flash vào board, board không boot.

Khả năng:

• FDF layout thay đổi reset vector/boot block
• PEI FV offset thay đổi nhưng SEC vẫn tìm offset cũ
• Firmware volume alignment sai
• Board dùng image sai SKU
• Security manifest/signature không update
• Variable store/region overlap
• Recovery region bị ghi đè

Debug Diary: Serial log không có nhưng POST code chạy

Điều này thường nghĩa là code chạy, nhưng serial init hoặc output path sai.

Anti-pattern khi debug reset vector

Instrumentation nên có ở reset vector

Reset vector debug playbook

Security checklist cho reset vector

Khi đọc source nên tìm gì?

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

Blog seeds

• Reset Vector là gì? CPU bắt đầu chạy BIOS từ đâu?
• Vì sao firmware chết trước DXE không có log?
• POST code trong early boot cứu debug như thế nào?
• Flash layout sai có thể brick board ra sao?
• Reset vector, SEC và PEI khác nhau thế nào?

Bài liên quan

• Firmware Flow Overview là gì?
• EFI_STATUS là gì?
• EFI_INVALID_PARAMETER là gì?
• EFI_SECURITY_VIOLATION là gì?
• memmap là gì?
• drivers command là gì?
• Device Path Node là gì?
• UEFI Variable Store là gì?
• SMM Architecture Overview là gì?

Nguồn tham khảo public

• UEFI Specification
• PI Specification
• EDK II MdePkg
• EDK II UefiCpuPkg
• EDK II OvmfPkg reset vector source

☕ Ủng hộ tác giả

Nếu bài viết hữu ích, một ly cà phê nhỏ sẽ giúp mình tiếp tục viết thêm nội dung chất lượng.

MoMo

QR image
/images/support/momo-qr.png

PayPal

QR image
/images/support/paypal-qr.png

PayPay

QR image
/images/support/paypay-qr.png

Mở app MoMo → Mở PayPal → PayPayで送る →

Trên điện thoại, hãy nhấn nút bên dưới mỗi QR để mở app thanh toán.