PEI - jljusten/tianocore GitHub Wiki

Frequently asked questions about PEI

Table of Contents Can SEC & PEI be built independently into separate binaries? In which phase would the TXT features get included? Are the PEI phases performed on Boot Strap Processor (BSP), what about APs? What is done in SEC phase? Example PEI modules (detailed) driver list—can details be known before execution? Can PEI and Sec be Split into separate pieces? What is shadow PEICore? Are Architectural PPIs marked differently than additional PPIs? Or a GUID? What does the memory map look like at the end of PEI phase? What is the minimal set of PEI drivers in a sequence of execution? What is the PEI dispatch order if there are no DEPEX? Does PEI support callbacks? Since PEI is 32 bit and DXE is 64 bit how do you determine which Library to use and / or call?

Yes, using EDK II, EDK has a special build process for Sec. EDK II platforms each have their own SEC library code that could be built separately and then included in the EDK II build process.

While a few things in SEC phase are affected, most of the feature support I added to the PEI phase.

The HW puts APs into Wait-For-SIPI at reset. Code running on the BSP must wake an AP to get the AP to run any code. This could be done in any/all of the PI Phases, but it is typically done in the DXE Phase when the DXE Driver that perform CPU initialization is executed.

The best way to summarize SEC is to get the platform into a state where it can run C code. This typically involves initialing a stack in temporary RAM. For Intel processors, Set up the processor for NEM; basically establish temporary memory. Set up Processor registers. Go into protected Flat 32 bit mode. Set up the APs. Jump to PeiMain

There is not a tool to determine the ordering before building or execution time (i.e. Priority list for ordering ) Example from Lakeport is PCD, ReportStatusCodeRouterPei, and StatusCodeHandlerPei.

It would be possible to include the Sec as a separate Binary. Normally Sec is a separate module that is part of the PEI stored in the recovery firmware volume.

A PEIM binary image can be executed in place from its location in the firmware volume (FV) (Not Shadowed) or from a compressed component that will be shadowed after permanent memory has been installed. Shadowing does not require compression. It is possible to shadow a component that is not compressed, and we do this for the PEI Core itself.

The term “Shadow” originated in the Legacy BIOS (80386 timeframe), when the code stored in an eight bit wide ROM part was copied into the physical RAM (32 bit wide) to improve performance of the BIOS code.

Architectural PPIs are defined in the PI specification Vol. 1 with a defined set of GUIDs. Example of Architectural PPI, EFI_PEI_MASTER_BOOT_MODE_PPI, EFI_DXE_IPL_PPI, and EFI_PEI_PERMANENT_MEMORY_INSTALLED_PPI are all required PPIs

There is a pointer, PEI Handoff Information Table (PHIT). PEI Memory Bottom and PEI Memory top are both stored in the PHIT. Memory is allocated from both the top and the bottom. Free memory is represented by pointers in the PHIT for both Free memory top and Free memory bottom. The Hand off blocks will also be pointed by the PHIT which will contain all the resource information discovered during the PEI phase. See § 4 PI Vol. 3 Spec

Is it known before execution? Basically, PEI needs to initialize PEI Core services, Discover Boot mode, and Initialize Memory. On a specific platform with DEBUG enabled you can see the individual PEIMs through the serial redirection on a host machine running a terminal emulation application. It is not know before execution the order or which PEIM will be invoked and it is non-determinant.

A Priori list can be used otherwise it will be the order in the FV per DSC/FDF definitions (these files order the creation and inclusion of the modules in an FV).

PEI does not have events like DXE, but uses PPI notification which is similar

In general for all the Libraries and APIs it does not matter. It is a “C” call able interface and if you compile for 32 bit or 64 bit, you will get the library in either 32 or 64 bit. Itanium and the EFI Byte code compiler are also supported. Plus ARM on open source. There are a few “Base” libraries that CPU specific.

category:UEFI/PI