PEI là gì trong UEFI?

PEI (Pre-EFI Initialization) là phase firmware chạy sau SEC và trước DXE. Nhiệm vụ chính là chuẩn bị những điều kiện tối thiểu để hệ thống có thể chuyển sang DXE: khởi tạo memory, chạy các PEIM cần thiết, publish PPI và tạo HOB list để bàn giao thông tin cho DXE.

PEI làm những việc gì?

PEI chạy trong giai đoạn rất sớm, khi hệ thống chưa có đầy đủ service như DXE. Code trong PEI thường ngắn gọn, tập trung chuẩn bị nền tảng thay vì xử lý logic phức tạp.

Môi trường PEI khác DXE ở điểm nào?

Ở PEI, hầu hết service đều đến từ một nơi duy nhất: PEI Services Table (EFI_PEI_SERVICES). Không có handle database và gBS như trong DXE; PEI không dùng UEFI Protocol trên handle database mà dùng PPI. Các PEI service cốt lõi được truy cập qua pointer **PeiServices được truyền vào entry point, hoặc qua wrapper từ PeiServicesLib.

EFI_STATUS EFIAPI
MyPeimEntryPoint (
  IN EFI_PEI_FILE_HANDLE     FileHandle,
  IN CONST EFI_PEI_SERVICES  **PeiServices   // ← PEI Services Table
  )
{
  // ...
}

Đây là điểm người mới hay bị lạ: không có gBS->... hay gRT->... như ở DXE. Thay vào đó là (*PeiServices)->... hoặc dùng wrapper từ PeiServicesLib.

PEI Core và PEIM là gì?

Đây là điểm hay bị bỏ qua khi đọc tài liệu - “PEI” thực ra gồm hai thành phần khác nhau.

PEI Core là firmware do UEFI PI spec định nghĩa, chịu trách nhiệm:

• Nhận quyền điều khiển từ SEC
• Quản lý PPI database
• Dispatch các PEIM theo đúng thứ tự dependency
• Gọi DXE IPL khi PEI hoàn tất

PEIM (PEI Module) là các module riêng biệt do platform cung cấp, ví dụ memory init PEIM, chipset init PEIM, platform config PEIM. Mỗi PEIM khai báo dependency trong file .inf:

[Depex]
  gEfiPeiMemoryDiscoveredPpiGuid AND
  gEfiPeiMasterBootModePpiGuid

PEI Core đọc [Depex] của từng PEIM và chỉ dispatch PEIM đó khi tất cả PPI dependency đã được install. Đây là cơ chế đảm bảo thứ tự init đúng - memory PEIM phải chạy trước PEIM nào cần memory, chipset PEIM phải chạy trước PEIM cần access hardware.

Nếu một PEIM không được dispatch dù build pass, hãy kiểm tra [Depex] trong .inf - có thể PPI mà nó chờ chưa được install bởi PEIM nào đó.

PEI kết thúc như thế nào?

PEI không tự “nhảy” sang DXE. Khi tất cả PEIM cần thiết đã chạy xong và HOB list đã được tạo, PEI Core gọi DXE IPL PPI (EFI_DXE_IPL_PPI). DXE IPL là PEIM đặc biệt chịu trách nhiệm:

1. Locate DXE Core trong firmware volume
2. Load DXE Core vào memory
3. Chuyển quyền điều khiển sang DXE Core entry point kèm HOB list pointer

Từ đây PEI kết thúc - không có return. DXE Core tiếp nhận HOB list và bắt đầu dựng môi trường DXE.

PEI Services thường dùng

PeiServicesLib cung cấp wrapper cho nhiều PEI Services thường dùng, giúp code gọn hơn mà không cần truyền **PeiServices qua từng hàm.

Cài đặt và locate PPI:

#include <Library/PeiServicesLib.h>

// Publish một PPI để PEIM khác dùng
EFI_PEI_PPI_DESCRIPTOR mMyPpiDescriptor = {
  (EFI_PEI_PPI_DESCRIPTOR_PPI | EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST),
  &gMyPpiGuid,
  &mMyPpi
};

PeiServicesInstallPpi(&mMyPpiDescriptor);

// Locate PPI do PEIM khác đã publish
MY_PPI_PROTOCOL *MyPpi;
Status = PeiServicesLocatePpi(
           &gMyPpiGuid,
           0,           // instance index
           NULL,        // descriptor output, thường không cần
           (VOID **)&MyPpi
         );
if (EFI_ERROR(Status)) {
  // PPI chưa có - producer chưa chạy, hoặc GUID sai
  return Status;
}

Allocate memory:

Trong PEI, allocation phụ thuộc trạng thái memory hiện tại. Trước khi permanent memory usable, môi trường còn rất hạn chế; sau khi permanent memory usable và quá trình migration phù hợp đã hoàn tất, PEIM có thể dùng các service cấp phát bộ nhớ an toàn hơn.

VOID *Buffer;

// Chỉ dùng sau khi permanent memory đã usable
Status = PeiServicesAllocatePool(sizeof(MY_STRUCT), &Buffer);

Chi tiết về giai đoạn trước/sau memory migration và AllocatePages nên được tách thành một note riêng về PEI memory allocation.

Tạo HOB để bàn giao dữ liệu cho DXE:

#include <Library/HobLib.h>

// Resource HOB - thông báo vùng system memory sau DRAM init
BuildResourceDescriptorHob(
  EFI_RESOURCE_SYSTEM_MEMORY,
  EFI_RESOURCE_ATTRIBUTE_PRESENT   |
  EFI_RESOURCE_ATTRIBUTE_INITIALIZED |
  EFI_RESOURCE_ATTRIBUTE_TESTED,
  DramBase,
  DramSize
);

// GUID HOB - truyền dữ liệu platform-specific sang DXE
MY_PLATFORM_INFO *Info = BuildGuidHob(
                           &gMyPlatformInfoGuid,
                           sizeof(MY_PLATFORM_INFO)
                         );
if (Info != NULL) {
  Info->BoardId      = DetectedBoardId;
  Info->FeatureFlags = DetectedFeatures;
}

Set boot mode:

// PEI đọc hardware state rồi set boot mode vào HOB
// DXE và BDS đọc lại qua GetBootModeHob()
Status = PeiServicesSetBootMode(BOOT_WITH_FULL_CONFIGURATION);
// hoặc: BOOT_ON_S4_RESUME, BOOT_IN_RECOVERY_MODE, v.v.

Truy cập PCI config hoặc I/O sớm:

Trong PEI, nếu cần đọc/ghi PCI config space trước DXE, PEIM thường locate EFI_PEI_PCI_CFG2_PPI thay vì dùng PciIo Protocol như ở DXE. Chi tiết cách dùng nên được tách thành một note riêng về EFI_PEI_PCI_CFG2_PPI.

HOB trong PEI là gì?

PEI tạo HOB list để bàn giao toàn bộ trạng thái platform cho DXE - memory, resource, firmware volume và boot mode. DXE Core đọc HOB list này ngay khi bắt đầu chạy.

Chi tiết các loại HOB, API đọc và debug: HOB là gì?

Vì sao lỗi DXE đôi khi bắt nguồn từ PEI?

Nếu dữ liệu DXE cần được PEI bàn giao qua HOB, thì PEI sai sẽ chỉ lộ ra khi DXE bắt đầu chạy.

Ví dụ thường gặp:

• DXE không thấy vùng memory đúng → Resource Descriptor HOB từ PEI sai.
• DXE driver trong FV phụ không được dispatch → PEI chưa tạo FV HOB cho FV đó.
• BDS xử lý sai boot mode → Boot mode PEI set không đúng tình huống thực tế.

Nói cách khác: PEI không chỉ là “phase trước DXE”. Nó là phase chuẩn bị trạng thái ban đầu của platform - nếu trạng thái đó sai, lỗi sẽ theo vào DXE.

Khi nào cần quan tâm đến PEI?

Nếu bạn chỉ viết DXE driver độc lập, consume protocol bình thường và không đụng tới dữ liệu từ PEI, có thể chưa cần đào sâu PEI ngay. Nhưng khi lỗi xảy ra rất sớm trong boot flow - đặc biệt trước hoặc ngay lúc chuyển sang DXE - PEI là nơi đầu tiên cần nhìn vào.

Các dấu hiệu cần kiểm tra PEI:

• Máy reset loop trước khi DXE log xuất hiện.
• POST code dừng ở vùng PEI.
• Memory training fail hoặc DRAM không usable.
• DXE Core không khởi động được.
• DXE thiếu thông tin memory, resource hoặc FV phụ.
• Boot mode sai khi vào BDS.

Checklist khi debug PEI

• POST code hoặc log cho thấy hệ thống còn ở PEI hay đã sang DXE?
• Memory init đã hoàn tất chưa, hay reset/treo trước khi DRAM usable?
• PEIM cần thiết có được dispatch không?
• PeiServicesLocatePpi() có fail không - producer chưa chạy hay GUID sai?
• HOB list có được tạo đúng không?
• Resource Descriptor HOB có mô tả đúng memory không?
• Firmware Volume HOB có đủ để DXE scan driver không?
• Boot mode được PEI set có đúng với tình huống thực tế không?

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

SEC có CAR, PEI mới khởi tạo DRAM thật sự. SEC dùng Cache-As-RAM (CAR) - cache của CPU được dùng như RAM tạm khi DRAM chưa sẵn sàng. Đây không phải DRAM thật. PEI mới là phase thật sự khởi tạo DRAM. Vì vậy không thể allocate memory thoải mái ở đầu PEI - phải chờ memory init PEIM chạy xong trước.

PEI có C runtime đầy đủ hơn SEC, nhưng vẫn hạn chế hơn DXE nhiều. SEC thường viết bằng assembly hoặc C rất hạn chế (không có stack đủ lớn, không có global data). PEI có môi trường C dễ dùng hơn SEC, đặc biệt sau khi permanent memory usable. Nhưng so với DXE thì PEI vẫn thiếu nhiều service: không có handle database, không có gBS, không dùng UEFI Protocol trên handle database.

PEI không phải chỉ là “khúc trước DXE”. PEI là phase có kiến trúc riêng - PEI Core, PEIM, PPI, HOB, DXE IPL. Không phải vài dòng init tạm thời.

Không thể bê tư duy DXE driver sang PEIM. gBS chưa tồn tại, memory có thể chưa đầy đủ ở đầu PEI. PEIM viết theo tư duy DXE driver rất dễ fail hoặc làm sai trạng thái hệ thống.

Lỗi DXE không phải lúc nào cũng do DXE. Nếu dữ liệu cần được PEI bàn giao qua HOB, sai từ PEI sẽ chỉ lộ ra khi DXE bắt đầu đọc.

PPI không phải Protocol. PPI thuộc PEI, Protocol thuộc DXE. Nhầm hai khái niệm này sẽ khiến việc đọc EDK II source khó hơn nhiều.

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

1. PEI nằm giữa hai phase nào trong boot flow UEFI?
2. SEC dùng CAR để làm gì? PEI khởi tạo gì mà SEC chưa làm?
3. PEI Core và PEIM khác nhau ở điểm nào?
4. PEIM được dispatch theo cơ chế gì - khai báo ở đâu trong source?
5. PPI dùng để làm gì trong PEI?
6. HOB giúp PEI bàn giao dữ liệu gì cho DXE?
7. PEI kết thúc bằng cách nào - DXE IPL làm gì?
8. Nếu DXE thiếu FV phụ hoặc memory map sai, vì sao cần kiểm tra lại PEI?

Bài liên quan

• SEC là gì?
• HOB là gì?
• PPI là gì?
• DXE là gì?
• Firmware Volume là gì?
• DXE Dispatcher là gì?

Nguồn tham khảo public

• UEFI PI Specification 1.9 - Volume 1: PEI Core Interface
• EDK II MdePkg - PeiServicesLib
• EDK II - PeiServicesTablePointerLib.h
• EDK II MdePkg - HobLib

Thấy nội dung này hữu ích?

Lưu lại hoặc chia sẻ cho người cũng đang học firmware, BIOS/UEFI và embedded systems.

Chia sẻ Copy link

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

HOB là gì trong UEFI?

HOB là dữ liệu PEI bàn giao cho DXE trong boot flow UEFI, giúp DXE biết memory, resource và firmware volume ban đầu.

13 tháng 4, 2026Đọc tiếp →

Ghi chú/BIOS Terms

PPI là gì trong UEFI?

PPI là cơ chế interface giữa các PEIM trong PEI phase, thay thế cho Protocol khi DXE chưa sẵn sàng. Hiểu PPI giúp debug dispatch order và lỗi PEIM không chạy.

11 tháng 10, 2025Đọc tiếp →

Ghi chú/BIOS Debug Terms

PEI Fail Checklist

Quicknote checklist debug lỗi trong PEI phase.

2 tháng 1, 2026Đọc tiếp →

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