6. Architectural PPIs

6.1. Introduction

The PEI Foundation and PEI Dispatcher rely on the following PEIM-to-PEIM Interfaces (PPIs) to perform its work. The abstraction provided by these interfaces allows dispatcher algorithms to be improved over time or have some platform variability without affecting the rest of PEI.

The key to these PPIs is that they are architecturally defined interfaces consumed by the PEI Foundation, but they may not be published by the PEI Foundation.

6.2. Required Architectural PPIs

6.2.1. Master Boot Mode PPI (Required)

6.2.1.1. EFI_PEI_MASTER_BOOT_MODE_PPI (Required)

Summary

The Master Boot Mode PPI is installed by a PEIM to signal that a final boot has been determined and set. This signal is useful in that PEIMs with boot-mode-specific behavior (for example, S3 versus normal) can put this PPI in their dependency expression.

GUID

#define EFI_PEI_MASTER_BOOT_MODE_PEIM_PPI \
  {0x7408d748, 0xfc8c, 0x4ee6, 0x92, 0x88, 0xc4, 0xbe, \
  0xc0, 0x92, 0xa4, 0x10}

PPI Interface Structure

None.

Description

The Master Boot Mode PPI is a PPI GUID and must be in the dependency expression of every PEIM that modifies the basic hardware. The dispatch, or entry point, of the module that installs the Master Boot Mode PPI modifies the boot path value in the following ways:

Directly, through the PEI Service SetBootMode()
Indirectly through its optional subordinate boot path modules

The PEIM that publishes the Master Boot Mode PPI has a non-null dependency expression if there are subsidiary modules that publish alternate boot path PPIs. The primary reason for this PPI is to be the root of dependencies for any child boot mode provider PPIs.

Status Codes Returned

None.

6.2.2. DXE IPL PPI (Required)

6.2.2.1. EFI_DXE_IPL_PPI (Required)

Summary

Final service to be invoked by the PEI Foundation.

GUID

#define EFI_DXE_IPL_PPI_GUID \
  { 0xae8ce5d, 0xe448, 0x4437, 0xa8, 0xd7, 0xeb, 0xf5, \
  0xf1, 0x94, 0xf7, 0x31 }

PPI Interface Structure

typedef struct _EFI_DXE_IPL_PPI {
  EFI_DXE_IPL_ENTRY Entry;
} EFI_DXE_IPL_PPI;

Parameters

Entry: The entry point to the DXE IPL PPI. See the Entry() function description.

Description

After completing the dispatch of all available PEIMs, the PEI Foundation will invoke this PPI through its entry point using the same handoff state used to invoke other PEIMs. This special treatment by the PEI Foundation effectively makes the DXE IPL PPI the last PPI to execute during PEI. When this PPI is invoked, the system state should be as follows:

Single thread of execution
Interrupts disabled
Processor mode as defined for PEI

The DXE IPL PPI is responsible for locating and loading the DXE Foundation. The DXE IPL PPI may use PEI services to locate and load the DXE Foundation. As long as the DXE IPL PPI is using PEI Services, it must obey all PEI interoperability rules of memory allocation, HOB list usage, and PEIM-to-PEIM communication mechanisms.

For S3 resume boot modes DXE IPL must be prepared to execute without permanent memory installed and invoke the S3 resume modules.

6.2.2.2. EFI_DXE_IPL_PPI.Entry()

Summary

The architectural PPI that the PEI Foundation invokes when there are no additional PEIMs to invoke.

Prototype

typedef
EFI_STATUS
(EFIAPI *EFI_DXE_IPL_ENTRY) (
 IN CONST EFI_DXE_IPL_PPI   *This,
 IN EFI_PEI_SERVICES        **PeiServices,
 IN EFI_PEI_HOB_POINTERS    HobList
 );

Parameters

This: Pointer to the DXE IPL PPI instance.

PeiServices: Pointer to the PEI Services Table.

HobList: Pointer to the list of Hand-Off Block (HOB) entries.

//
// Union of all the possible HOB Types
//
typedef union {
  EFI_HOB_GENERIC_HEADER              *Header;
  EFI_HOB_HANDOFF_INFO_TABLE          *HandoffInformationTable;
  EFI_HOB_MEMORY_ALLOCATION           *MemoryAllocation;
  EFI_HOB_MEMORY_ALLOCATION_BSP_STORE *MemoryAllocationBspStore;
  EFI_HOB_MEMORY_ALLOCATION_STACK     *MemoryAllocationStack;
  EFI_HOB_MEMORY_ALLOCATION_MODULE    *MemoryAllocationModule;
  EFI_HOB_RESOURCE_DESCRIPTOR         *ResourceDescriptor;
  EFI_HOB_GUID_TYPE                   *Guid;
  EFI_HOB_FIRMWARE_VOLUME             *FirmwareVolume;
  EFI_HOB_CPU                         *Cpu;
  EFI_HOB_MEMORY_POOL                 *Pool;
  UINT8                               *Raw;
} EFI_PEI_HOB_POINTERS;

Description

This function is invoked by the PEI Foundation. The PEI Foundation will invoke this service when there are no additional PEIMs to invoke in the system. If this PPI does not exist, it is an error condition and an ill-formed firmware set. The DXE IPL PPI should never return after having been invoked by the PEI Foundation. The DXE IPL PPI can do many things internally, including the following:

Invoke the DXE entry point from a firmware volume.
Invoke the recovery processing modules.
Invoke the S3 resume modules.

Status Codes Returned

EFI_SUCCESS

Upon this return code the PEI Foundation should enter some exception handling Under normal circumstances the DXE IPL PPI should not return

6.2.3. Memory Discovered PPI (Required)

6.2.3.1. EFI_PEI_PERMANENT_MEMORY_INSTALLED_PPI (Required)

Summary

This PPI is published by the PEI Foundation when the main memory is installed. It is essentially a PPI with no associated interface. Its purpose is to be used as a signal for other PEIMs who can register for a notification on its installation.

GUID

#define EFI_PEI_PERMANENT_MEMORY_INSTALLED_PPI_GUID \
  {0xf894643d, 0xc449, 0x42d1, 0x8e, 0xa8, 0x85, 0xbd, \s
  0xd8, 0xc6, 0x5b, 0xde}

PPI Interface Structure

None.

Description

This PPI is installed by the PEI Foundation at the point of system evolution when the permanent memory size has been registered and waiting PEIMs can use the main memory store. Using this GUID allows PEIMs to do the following:

Be notified when this PPI is installed.
Include this PPI’s GUID in the EFI_DEPEX .

The expectation is that a compressed PEIM would depend on this PPI, for example. The PEI Foundation will relocate the temporary cache to permanent memory prior to this installation.

Status Codes Returned

None.

6.3. Optional Architectural PPIs

6.3.1. Boot in Recovery Mode PPI (Optional)

6.3.1.1. EFI_PEI_BOOT_IN_RECOVERY_MODE_PPI (Optional)

Summary

This PPI is installed by the platform PEIM to designate that a recovery boot is in progress.

GUID

#define EFI_PEI_BOOT_IN_RECOVERY_MODE_PEIM_PPI \
  {0x17ee496a, 0xd8e4, 0x4b9a, 0x94, 0xd1, 0xce, 0x82, \
  0x72, 0x30, 0x8, 0x50}

PPI Interface Structure

None.

Description

This optional PPI is installed by the platform PEIM to designate that a recovery boot is in progress. Its purpose is to allow certain PEIMs that wish to be dispatched only during a recovery boot to include this PPI in their dependency expression (depex). Including this PPI in the depex allows the PEI Dispatcher to skip recovery-specific PEIMs during normal restarts and thus save on boot time. This PEIM has no associated PPI and is used only to designate the system state as being “in a crisis recovery dispatch.”

Status Codes Returned

None.

6.3.2. End of PEI Phase PPI (Optional)

6.3.2.1. EFI_PEI_END_OF_PEI_PHASE_PPI (Optional)

Summary

This PPI will be installed at the end of PEI for all boot paths, including normal, recovery, and S3. It allows for PEIMs to possibly quiesce hardware, build handoff information for the next phase of execution, or provide some terminal processing behavior.

GUID

#define EFI_PEI_END_OF_PEI_PHASE_PPI_GUID \
  {0x605EA650, 0xC65C, 0x42e1, 0xBA, 0x80, 0x91, 0xA5, \
  0x2A, 0xB6,0x18, 0xC6}

PPI Interface Structure

None.

Description

This PPI is installed by the DXE IPL PPI to indicate the end of the PEI usage of memory and ownership of memory allocation by the DXE phase.

For the BOOT_ON_S3_RESUME boot mode, this PPI is installed by the EFI_PEI_S3_RESUME_PPI.S3RestoreConfig() (Section 8.6 of the PI1.2 Specification, Volume 5) just before jump to OS waking vector.

The intended use model is for any agent that needs to do cleanup, such as memory services to convert internal metadata for tracking memory allocation into HOBs, to have some distinguished point in which to do so. The PEI Memory Services would register for a callback on the installation of this PPI.

Status Codes Returned

None.

6.3.3. PEI Reset PPI

6.3.3.1. EFI_PEI_RESET_PPI (Optional)

Summary

This PPI is installed by some platform- or chipset-specific PEIM that abstracts the Reset Service to other agents.

GUID

#define EFI_PEI_RESET_PPI_GUID \
  {0xef398d58, 0x9dfd, 0x4103, 0xbf, 0x94, 0x78, 0xc6, \
  0xf4, 0xfe, 0x71, 0x2f}

PPI Interface Structure

typedef struct _EFI_PEI_RESET_PPI {
  EFI_PEI_RESET_SYSTEM  ResetSystem;
} EFI_PEI_RESET_PPI;

Parameters

ResetSystem: A service to reset the platform. See the ResetSystem() function description in Reset Services.

Description

These services provide a simple reset service. See the ResetSystem() function description for a description of this service.

6.3.4. PEI Reset2 PPI

6.3.4.1. EFI_PEI_RESET2_PPI (Optional)

Summary

This PPI is installed by some platform- or chipset-specific PEIM that abstracts the ability to reset the platform.

GUID

#define EFI_PEI_RESET2_PPI_GUID \
{0x6cc45765, 0xcce4, 0x42fd, \
  {0xbc, 0x56, 0x1, 0x1a,0xaa, 0xc6, 0xc9, 0xa8}}

PPI Interface Structure

typedef struct _EFI_PEI_RESET2_PPI {
EFI_PEI_RESET2_SYSTEM   ResetSystem;
} EFI_PEI_RESET_PPI;

Parameters

ResetSystem: A service to reset the platform.

Description

These services provide a simple reset service. This is equivalent to the ResetSystem() API call in the UEFI2.4 specification.

6.3.4.2. ResetSystem()

Summary

Resets the entire platform.

Prototype

typedef
VOID
(EFIAPI *EFI_PEI_RESET2_SYSTEM) (
IN EFI_RESET_TYPE    ResetType,
IN EFI_STATUS        ResetStatus,
IN UINTN             DataSize,
IN VOID              *ResetData OPTIONAL
);

Parameters

ResetType: The type of reset to perform. Type EFI_RESET_TYPE is defined in “Related Definitions” below.

ResetStatus: The status code for the reset. If the system reset is part of a normal operation, the status code would be EFI_SUCCESS . If the system reset is due to some type of failure the most appropriate EFI Status code would be used.

DataSize: The size, in bytes, of ResetData .

ResetData: For a ResetType of EfiResetCold , EfiResetWarm , or EfiResetShutdown the data buffer starts with a Null-terminated string, optionally followed by additional binary data. The string is a description that the caller may use to further indicate the reason for the system reset. ResetData is only valid if ResetStatus is something other than EFI_SUCCESS unless the ResetType is EfiResetPlatformSpecific where a minimum amount of ResetData is always required.

//*******************************************************
// EFI_RESET_TYPE//
*******************************************************
typedef enum {
    EfiResetCold,
    EfiResetWarm,
    EfiResetShutdown,
    EfiResetPlatformSpecific
} EFI_RESET_TYPE;

Description

The ResetSystem() function resets the entire platform, including all processors and devices, and reboots the system.

Calling this interface with ResetType of EfiResetCold causes a system-wide reset. This sets all circuitry within the system to its initial state. This type of reset is asynchronous to system operation and operates without regard to cycle boundaries. EfiResetCold is tantamount to a system power cycle.

Calling this interface with ResetType of EfiResetWarm causes a system-wide initialization. The processors are set to their initial state, and pending cycles are not corrupted. If the system does not support this reset type, then an EfiResetCold must be performed.

Calling this interface with ResetType of EfiResetShutdown causes the system to enter a power state equivalent to the ACPI G2/S5 or G3 states. If the system does not support this reset type, then when the system is rebooted, it should exhibit the EfiResetCold attributes.

Calling this interface with ResetType of EfiResetPlatformSpecific causes a system-wide reset. The exact type of the reset is defined by the EFI_GUID that follows the Null-terminated Unicode string passed into ResetData . If the platform does not recognize the EFI_GUID in ResetData the platform must pick a supported reset type to perform.The platform may optionally log the parameters from any non-normal reset that occurs.

The ResetSystem() function does not return.

6.3.5. Status Code PPI (Optional)

6.3.5.1. EFI_PEI_PROGRESS_CODE_PPI (Optional)

Summary

This service is published by a PEIM. There can be only one instance of this service in the system. If there are multiple variable access services, this PEIM must multiplex these alternate accessors and provide this single, read-only service to the other PEIMs and the PEI Foundation. This singleton nature is important because the PEI Foundation will notify when this service is installed.

GUID

#define EFI_PEI_REPORT_PROGRESS_CODE_PPI_GUID \
  {0x229832d3, 0x7a30, 0x4b36, 0xb8, 0x27, 0xf4, 0xc, \
  0xb7, 0xd4, 0x54, 0x36);

PPI Interface Structure

typedef struct _EFI_PEI_PROGRESS_CODE_PPI {
  EFI_PEI_REPORT_STATUS_CODE       ReportStatusCode;
} EFI_PEI_PROGRESS_CODE_PPI;

Parameters

6.3.5.2. ReportStatusCode

Service that allows PEIMs to report status codes.

Description

See the ReportStatusCode function description for a description of this service.

6.3.6. Security PPI (Optional)

6.3.6.1. EFI_PEI_SECURITY2_PPI (Optional)

Summary

This PPI is installed by some platform PEIM that abstracts the security policy to the PEI Foundation, namely the case of a PEIM’s authentication state being returned during the PEI section extraction process.

GUID

#define EFI_PEI_SECURITY2_PPI_GUID \
  { 0xdcd0be23, 0x9586, 0x40f4, 0xb6, 0x43, 0x6, 0x52, \
  0x2c, 0xed, 0x4e, 0xde }

PPI Interface Structure

typedef struct _EFI_PEI_SECURITY2_PPI {
  EFI_PEI_SECURITY_AUTHENTICATION_STATE   AuthenticationState;
} EFI_PEI_SECURITY2_PPI;

Parameter

AuthenticationState: Allows the platform builder to implement a security policy in response to varying file authentication states. See the AuthenticationState() function description.

Description

This PPI is a means by which the platform builder can indicate a response to a PEIM’s authentication state. This can be in the form of a requirement for the PEI Foundation to skip a module using the DeferExecution Boolean output in the AuthenticationState() member function. Alternately, the Security PPI can invoke something like a cryptographic PPI that hashes the PEIM contents to log attestations, for which the FileHandle parameter in AuthenticationState() will be useful. If this PPI does not exist, PEIMs will be considered trusted.

6.3.6.2. EFI_PEI_SECURITY2_PPI.AuthenticationState()

Summary

Allows the platform builder to implement a security policy in response to varying file authentication states.

Prototype

typedef
EFI_STATUS
(EFIAPI *EFI_PEI_SECURITY_AUTHENTICATION_STATE) (
  IN CONST EFI_PEI_SERVICES       **PeiServices,
  IN CONST EFI_PEI_SECURITY2_PPI  *This,
  IN UINT32                        AuthenticationStatus,
  IN EFI_PEI_FV_HANDLE             FvHandle,
  IN EFI_PEI_FILE_HANDLE           FileHandle,
  IN OUT BOOLEAN                   *DeferExecution
);

Parameters

PeiServices: An indirect pointer to the PEI Services Table published by the PEI Foundation.

This: Interface pointer that implements the particular EFI_PEI_SECURITY2_PPI instance.

AuthenticationStatus: Authentication status of the file.

FvHandle: Handle of the volume in which the file resides. Type EFI_PEI_FV_HANDLE is defined in FfsFindNextVolume . This allows different policies depending on different firmware volumes.

FileHandle: Handle of the file under review. Type EFI_PEI FILE HANDLE is defined in FfsFindNextFile .

DeferExecution: Pointer to a variable that alerts the PEI Foundation to defer execution of a PEIM.

Description

This service is published by some platform PEIM. The purpose of this service is to expose a given platform’s policy-based response to the PEI Foundation. For example, if there is a PEIM in a GUIDed encapsulation section and the extraction of the PEI file section yields an authentication failure, there is no a priori policy in the PEI Foundation. Specifically, this situation leads to the question whether PEIMs that are either not in GUIDed sections or are in sections whose authentication fails should still be executed.

In fact, it is the responsibility of the platform builder to make this decision. This platform-scoped policy is a result that a desktop system might not be able to skip or not execute PEIMs because the skipped PEIM could be the agent that initializes main memory. Alternately, a system may require that unsigned PEIMs not be executed under any circumstances. In either case, the PEI Foundation simply multiplexes access to the Section Extraction PPI and the Security PPI. The Section Extraction PPI determines the contents of a section, and the Security PPI tells the PEI Foundation whether or not to invoke the PEIM.

The PEIM that publishes the AuthenticationState() service uses its parameters in the following ways:

AuthenticationStatus conveys the source information upon which the PEIM acts.
The DeferExecution value tells the PEI Foundation whether or not to dispatch the PEIM.

In addition, between receiving the AuthenticationState() from the PEI Foundation and returning with the DeferExecution value, the PEIM that publishes AuthenticationState() can do the following:

Log the file state.
Lock the firmware hubs in response to an unsigned PEIM being discovered.

These latter behaviors are platform- and market-specific and thus outside the scope of the PEI CIS.

Status Codes Returned

EFI_SUCCESS	The service performed its action successfully.
EFI_SECURITY_VIOLATION	The object cannot be trusted

6.3.7. Temporary RAM Support PPI (Optional)

6.3.7.1. EFI_PEI_TEMPORARY_RAM_SUPPORT_PPI (Optional)

Summary

This service allows for migrating from some contents of Temporary RAM store, which is instantiated during the SEC phase, into permanent RAM. The latter store will persist unmodified into the subsequent phase of execution, such as DXE. This service may be published by the SEC as part of the SEC-to-PEI handoff or published by any other PEIM.

GUID

#define EFI_PEI_TEMPORARY_RAM_SUPPORT_PPI_GUID
{0xdbe23aa9, 0xa345, 0x4b97,0x85, 0xb6, 0xb2, 0x26, 0xf1, 0x61, 0x73, 0x89}

Prototype

typedef struct _EFI_PEI_TEMPORARY_RAM_SUPPORT_PPI {
  TEMPORARY_RAM_MIGRATION         TemporaryRamMigration;
} EFI_PEI_TEMPORARY_RAM_SUPPORT_PPI;

Parameters

TemporaryRamMigration: Perform the migration of contents of Temporary RAM to Permanent RAM. This service may terminate the Temporary RAM, for example, if it cannot coexist with the Permanent RAM. See the TemporaryRamMigration()` function description.

Description

This service abstracts the ability to migrate contents of the platform early memory store. This is an optional PPI that is only required for platforms that may have side effects when both Temporary RAM and Permanent RAM are enabled. This PPI provides a service that orchestrates the complete transition from Temporary RAM to Permanent RAM that avoids side effects. This includes the migration of all data, a stack switch action, and possibly the disabling of Temporary RAM.

If a platform does not have any side effects when both Temporary RAM and Permanent RAM are enabled, and the platform is required to disable the use of Temporary RAM, then EFI_PEI_TEMPORARY_RAM_DONE should be produced.

If a platform does not have any side effects when both Temporary RAM and Permanent RAM are enabled, and the platform is not required to disable the use of Temporary RAM, then neither EFI_PEI_TEMPORARY_RAM_DONE nor EFI_PEI_TEMPORARY_RAM_SUPPORT_PPI should be produced.

6.3.7.2. EFI_PEI_TEMPORARY_RAM_SUPPORT_PPI.TemporaryRamMigration()

Summary

This service of the EFI_PEI_TEMPORARY_RAM_SUPPORT_PPI that migrates temporary RAM into permanent memory.

Prototype

typedef
EFI_STATUS
(EFIAPI * TEMPORARY_RAM_MIGRATION) (
  IN CONST EFI_PEI_SERVICES   **PeiServices,
  IN EFI_PHYSICAL_ADDRESS     TemporaryMemoryBase,
  IN EFI_PHYSICAL_ADDRESS     PermanentMemoryBase,
  IN UINTN CopySize
);

Parameters

PeiServices: Pointer to the PEI Services Table.

TemporaryMemoryBase: Source Address in temporary memory from which the SEC or PEIM will copy the Temporary RAM contents.

PermanentMemoryBase: Destination Address in permanent memory into which the SEC or PEIM will copy the Temporary RAM contents.

CopySize: Amount of memory to migrate from temporary to permanent memory.

Description

This service is published by the SEC module or a PEIM. It migrates the Temporary RAM contents into Permanent RAMRAM and performs all actions required to switch the active stack from Temporary RAM to Permanent RAM. The address range from PermanentMemoryBase to PermanentMemoryBase + CopySize should fix within the range of memory provided to the PEI Foundation as part of the InstallPeiMemory() core services. Also, since the SEC may have sequestered some of the Temporary RAM for its own data storage and PPI’s, the SEC handoff now includes addresses and sizes of both the “available” ( PeiTemporaryRamBase / PeiTemporaryRamSize ) and “total” ( TemporaryRamBase / TemporaryRamSize ) Temporary RAM as separate numbers.

PeiTemporaryRamBase is used by the PEI foundation for its resource management; TemporaryRamBase is used by the foundation as an input to this TemporaryRamMigration() service call. As such, the PEI foundation is the only agent who knows the full extent of the Temporary RAM store that needs migration to Permanent RAM. It will use this full extent as the CopySize argument in this PPI invocation. At minimum, the CopySize must include the portion of the Temporary RAM used by the SEC.

The PEI Foundation implementation will invoke this PPI service TemporaryRamMigration() , if present, after InstallPeiMemory() is invoked. EFI_PEI_PERMANENT_MEMORY_INSTALLED_PPI is installed after the PPI service TemporaryRamMigration() is invoked, providing a signal to PEIMs that permanent memory is available.

If the EFI_PEI_TEMPORARY_RAM_SUPPORT_PPI service is not available, a PEI foundation implementation shall copy the contents of the Temporary RAM to Permanent RAM directly and perform the stack switch action. The lack of this PPI is not an error condition.

The stack switch action, namely the beginning of usage of the permanent RAM as stack in lieu of the temporary RAM stack, is an integral capability of any PEI foundation implementation and need not have an API in this PPI or any other to externally-installed abstraction.

Status Codes Returned

EFI_SUCCESS	The data was successfully returned
EFI_INVALID_PARAMETER	PermanentMemoryBase + CopySize > TemporaryMemoryBase when TemporaryMemoryBase > PermanentMemoryBase

6.3.8. Temporary RAM Done PPI (Optional)

6.3.8.1. EFI_PEI_TEMPORARY_RAM_DONE_PPI (Optional)

Summary

The PPI that provides a service to disable the use of Temporary RAM.

GUID

#define EFI_PEI_TEMPORARY_RAM_DONE_PPI_GUID \
  { 0xceab683c, 0xec56, 0x4a2d, \
  { 0xa9, 0x6, 0x40, 0x53, 0xfa, 0x4e, 0x9c, 0x16 } }

Protocol Interface Structure

typedef struct _EFI_PEI_TEMPORARY_RAM_DONE_PPI {
  EFI_PEI_TEMPORARY_RAM_DONE   TemporaryRamDone;
} EFI_PEI_TEMPORARY_RAM_DONE_PPI;

Parameters

TemporaryRamDone: Disable the use of Temporary RAM.

Description

This is an optional PPI that may be produced by SEC or a PEIM. If present, it provide a service to disable the use of Temporary RAM. This service may only be called by the PEI Foundation after the transition from Temporary RAM to Permanent RAM is complete. This PPI provides an alternative to the Temporary RAM Migration PPI for system architectures that allow Temporary RAM and Permanent RAM to be enabled and accessed at the same time with no side effects.

6.3.8.2. EFI_PEI_TEMPORARY_RAM_DONE_PPI.TemporaryRamDone ()

Summary

Disable the use of Temporary RAM.

Prototype

typedef
EFI_STATUS
  (EFIAPI * EFI_PEI_TEMPORARY_RAM_DONE) (
    VOID
    );

Description

TemporaryRamDone() disables the use of Temporary RAM. If present, this service is invoked by the PEI Foundation after the EFI_PEI_PERMANANT_MEMORY_INSTALLED_PPI is installed.

Status Codes Returned

EFI_SUCCESS	Use of Temporary RAM was disabled.
EFI_DEVICE_ERROR	Temporary RAM could not be disabled.

6.3.9. EFI_PEI_CORE_FV_LOCATION_PPI

Summary

Indicates to the PEI Foundation which Firmware Volume contains the PEI Foundation.

GUID

#define EFI_PEI_CORE_FV_LOCATION_GUID \
  {0x52888eae, 0x5b10, 0x47d0, \
  {0xa8, 0x7f, 0xb8, 0x22, 0xab, 0xa0, 0xca, 0xf4}}

Prototype

typedef struct {
   VOID       *PeiCoreFvLocation;
} EFI_PEI_CORE_FV_LOCATION_PPI;

Parameters

PeiCoreFVLocation: Points to the first byte of the firmware volume which contains the PEI Foundation.

Description

PI Specification 1.6 and earlier versions required that the PEI Foundation reside in the Boot Firmware Volume (BFV). This allowed the PEI Foundation to assume that it can locate itself within the BFV. This assumption is no longer valid. As the PI Specification no longer defines a mechanism for the PEI Foundation to locate itself, a new method is needed. Specifically, the PEI Core can use the EFI_PEI_CORE_FV_LOCATION_PPI to ascertain its containing firmware volume location.

Specifically, if the PEI Foundation does not reside in the BFV, then SEC must pass the EFI_PEI_CORE_FV_LOCATION_PPI as a part of the PPI list provided to the PEI Foundation Entry Point. If this PPI is not present in the PPI list, the PEI Foundation shall assume that it resides within the BFV.

The PEI Foundation will use the EFI_PEI_CORE_FV_LOCATION_PPI for purposes of module dispatch if it exists. If it does not exist, the BootFirmwareVolume base in EFI_SEC_PEI_HAND_OFF will be used.