#define PEI_PREMEM_GRAPHICS_PPI_GUID \
{ \
  0x31a4622d, 0x0e21, 0x40a2, 0x80, 0xdb, 0xc4, 0x42, 0x08, 0xfc, 0xe1, 0xb5 \
};

struct {
  UINT32                    Version;
  PREMEM_PEI_GRAPHICS_INIT  PreMemGraphicsPpiInit;
  PREMEM_PEI_GRAPHICS_EXIT  PreMemGraphicsPpiExit;
} PEI_MICRO_GRAPHICS_PPI;

µGOP depends on a limited of PEI services:

1. InstallPpi() to install the PEIM Graphics PPI
   
2. LocatePpi() to access PEIM-to-PEIM Interface (PPI) Dependencies
   
3. AllocatePool() to dynamically allocate memory to handle internal data structure such as display information …
   
4. GetHobList() and CreateHob() to access Hand Off Blocks (HOB) holding runtime data
   
5. ReportStatusCode() to report debug information which coreboot prints using printk.
   

Those services implemented in coreboot are pretty straightforward and fit in less than 300 lines of code.

µGOP expects to find the PEI services pointer in the architecture size word immediately preceding the Interrupt Descriptor Table (IDT) (cf. Platform Initialization (PI) Specification 5.4 PEI Services Table Retrieval). Since coreboot x86/exception module already sets up the IDT and as we do not want to disrupt this configuration we create a copy of the IDT. But we include an extra architecture size word preceding the table to store the PEI services pointer.

Note that FSP memory installs its own IDT but it backups and restores the one we have set up. Therefore, there is no risk of having PEI services pointer conflicts.

As we need to execute the µGOP binary in place, we need to perform a relocation operation of the Portable Executable binary. Since memory space is limited in the pre-memory stages, it is preferable to perform a static relocation operation during the firmware stitching operation.

Fortunately, most of the logic and code is already available as this operation is performed on the FSP-M binary. We only have to add explicit support for EFI binaries (cf. 76762 cbfstool: Add relocation support for EFI binaries).

As µGOP requires the Video BIOS Table (VBT) and since memory space is limited in the pre-memory stages, it is preferable to keep VBT in uncompressed form in CBFS. We introduced the CONFIG_VBT_CBFS_COMPRESSION configuration entry to allow this (cf. 76816 drivers/intel/gma/Kconfig: Add VBT compression configuration entry).

When CONFIG_UGOP_EARLY_GRAPHICS is set

1. ugop.efi is included as a CBFS file
   
2. romstage includes extra code: pei.c, ugop.c and ux.c
   
3. vbt.bin is stored uncompressed instead of lzma compressed
   

The use of µGOP in coreboot represents a size increase of around 84 KB per region (COREBOOT, FW_MAIN_A and FW_MAIN_B).

On a Meteor Lake Google Rex board, we performed 5 warm reset cycles (without and with CONFIG_UGOP_EARLY_GRAPHICS set) and we collected the cbmem -t outputs. We computed the median time of each duration (time between two timestamps) and then performed a comparison with a threshold of 0.5 ms.

The only relevant impact is the verification of the image (507 → 508): +4.7 ms and it can be explained by the 84 KB size increase of the image.

Overall the boot time impact is about 5 ms and concentrated on verstage.

For µGOP to execute properly, we have to provide some memory allocation services (allocate_pool and create_hob). These services relies on cache-as-ram memory reservation (.bss section). We looked at the two new object files:

With µGOP sign-of-life, there is an extra 7 KB cache-as-ram use.

The SPINOR and cache-as-RAM space use along with the boot performance penalty are limited and comparable to what it would be with libgfxinit.

We also noticed that µGOP is faster to bring-up graphics than libgfxinit. Indeed, according to previously captured numbers on Raptor Lake compared to some number of µGOP on Meteor Lake, µGOP is three times faster to bring up graphics than libgfxinit on an eDP panel (119 ms vs 373 ms).

–
Jeremy
One Emacs to rule them all