-
Notifications
You must be signed in to change notification settings - Fork 1
PEI
Frequently asked questions about PEI
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.