Dear coreboot developers,
With Raptor Lake, we introduced the Pre-Memory Sign-of-Life feature which displays an on-screen message while firmware components such as coreboot, Firmware Support Package Memory (FSP-M) or, CSME perform long time operations during pre-memory stages.
We propose to take advantage of a proprietary driver Intel already supports, validates and includes in FSP silicon: the Intel Graphics PEIM (Pre-EFI Initialization Module) driver also known as the GOP (Graphical Output Protocol) driver.
This driver is designed to run in post-memory initialization stages. Therefore, we derived a new version capable of running in pre-memory stages which we called microGOP. This version is specifically designed to perform graphics legacy VGA initialization.
We intend to keep providing such a binary base solution on the long run as it addresses our software convergence goals and is compatible with early platform development stage constraints. [libgfxinit] supports can always be added later by the open-source community once the Graphics Programmer Reference Manuals are published.
Below, we present the work we performed to run this microGOP driver from coreboot romstage. It allows to initialize graphics with a very similar flow compared to [libgfxinit] use.
Our goal is to start collecting feedback. We will release all the patches on coreboot.org under the [ugop] topic soon.
[libgfxinit] https://github.com/coreboot/libgfxinit
[ugop] https://review.coreboot.org/q/topic:ugop
1 microGOP driver interface ===========================
The uGOP PEIM provides the following PEIM-to-PEIM protocol under the `31a4622d-0e21-40a2-80db-c44208fce1b5' GUID.
,---- | #define PEI_PREMEM_GRAPHICS_PPI_GUID \ | { \ | 0x31a4622d, 0x0e21, 0x40a2, 0x80, 0xdb, 0xc4, 0x42, 0x08, 0xfc, 0xe1, 0xb5 \ | }; `----
The protocol is composed of three fields.
,---- | struct { | UINT32 Version; | PREMEM_PEI_GRAPHICS_INIT PreMemGraphicsPpiInit; | PREMEM_PEI_GRAPHICS_EXIT PreMemGraphicsPpiExit; | } PEI_MICRO_GRAPHICS_PPI; `----
1. The current `Version' is `0x00010000'. Where the upper 16 bits represent the major (1) and the lower 16 bits represent the minor number. 2. `PreMemGraphicsPpiInit()' ,---- | typedef | EFI_STATUS | (EFIAPI *PREMEM_PEI_GRAPHICS_INIT) ( | IN VOID *Vbt | ); `---- The `PreMemGraphicsPpiInit()' should be supplied with a pointer to the Video BIOS Table. 3. `PreMemGraphicsPpiExit()' does not take any parameters. This function must be called to disable VGA graphics configuration once not necessary anymore. Not performing this operation may lead to undesirable behaviour when other graphics stack starts (GOP in FSP-S or Operating System driver).
2 Integration =============
As we intend to run microGOP driver in romstage, we want to keep the required coreboot code as small and efficient as possible. For this reason, we discarded re-using the EDK2 code which would have a major impact on the romstage binary size in addition to adding complication to the build scripts. Instead, we implemented a limited set of Pre-EFI Initialization services. The code is small and designed to accommodate a simple PEIM driver such as microGOP.
2.1 PEI services ~~~~~~~~~~~~~~~~
microGOP 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.
2.2 PEI services pointer ~~~~~~~~~~~~~~~~~~~~~~~~
microGOP 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.
[Platform Initialization (PI) Specification] https://uefi.org/sites/default/files/resources/PI_Spec_1_6.pdf
[coreboot x86/exception] https://github.com/coreboot/coreboot/blob/master/src/arch/x86/exception.c
2.3 Portable Executable Relocation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
As we need to execute the microGOP 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]).
[76762 cbfstool: Add relocation support for EFI binaries] https://review.coreboot.org/c/coreboot/+/76762
2.4 Uncompressed VBT ~~~~~~~~~~~~~~~~~~~~
As microGOP 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]).
[76816 drivers/intel/gma/Kconfig: Add VBT compression configuration entry] https://review.coreboot.org/c/coreboot/+/76816
3 Code flow ===========
4 Performances analysis =======================
The analysis below is based on a microGOP binary with eDP and HDMI support.
4.1 Size impact ~~~~~~~~~~~~~~~
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
CBFS File UGOP_EARLY_GRAPHICS=n (bytes) UGOP_EARLY_GRAPHICS=y (bytes) Delta (bytes) ---------------------------------------------------------------------------------------- microGOP 0 68448 68448 romstage 126128 136256 10128 vbt.bin 1264 9216 7952 ---------------------------------------------------------------------------------------- *Total* 127392 213920 *86528*
The use of microGOP in coreboot represents a size increase of around 84 KB per region (`COREBOOT', `FW_MAIN_A' and `FW_MAIN_B').
4.2 Regular Boot time impact (no Sign-of-Life) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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.
Start ID Start Description End ID End Description Delta (ms) ------------------------------------------------------------------------------------------------------------------------- 947 CSE received 'CPU Reset Done Ack sent' from PMC 991 Die Management Unit (DMU) load completed +1.0 507 starting to verify body (load+SHA2+RSA) 508 finished loading body +4.7 510 finished verifying body signature (RSA) 511 starting TPM PCR extend -0.8 1030 finished EC verification 1040 finished storage device initialization +1.4
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'.
4.3 Cache-As-Ram ~~~~~~~~~~~~~~~~
For microGOP 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:
Object file .bss section size (bytes) ---------------------------------------- pei.o 6730 ugop.o 9 ---------------------------------------- *6739*
With microGOP sign-of-life, there is an extra 7 KB cache-as-ram use.
4.4 Conclusion ~~~~~~~~~~~~~~
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 microGOP is faster to bring-up graphics than libgfxinit. Indeed, according to previously captured numbers on Raptor Lake compared to some number of microGOP on Meteor Lake, microGOP is three times faster to bring up graphics than libgfxinit on an eDP panel (119 ms vs 373 ms).
5 Summary =========
This Sign-of-Life microGOP driver based implementation presents the following advantages: - it needs a limited code addition - it has a limited impact on the performance - its flow and boot performance impact is comparable to libgfxinit solution - it is compatible with our software convergence goals - it can be available during new platform development early stages which help our partners to test the feature and stabilize the platform
Regards,
Hi Jeremy,
Thanks for posting this. I know that you're planning on doing a presentation about this in this week's leadership meeting and look forward to that. https://coreboot.org/calendar.html
A few questions: 1) How does the uGOP driver work with libgfxinit? Does using uGOP mean that the full GOP driver then needs to be used, or can the system transition back to libgfxinit after memory is initialized.
2) When is the Graphics Programmer Reference Manuals going to be published so that the support can be added? Is this planned for next month, next year, or not currently planned, but hoped for?
3) Is there a reason that the uGOP driver can't be open sourced, at least once the Graphics Programmer Reference Manuals are released?
4) When you talk about the differences in time between the uGOP driver and libgfxinit, is that strictly due to when they are called, or is there some further difference that the uGOP driver is able to accomplish that libgfxinit wouldn't ever be able to do?
5) Is there a reason that Intel is unwilling to add (or help add) the required code to libgfxinit, an open source solution that according to your notes should be comparable to the uGOP binary solution? Would Intel be willing to help once the reference manuals are released, or is any cooperation between intel and the community on libgfxinit just not able to happen?
6) I assume that the uGOP driver is completely optional, and is only needed to show early signs of life. Is that correct, or could the uGOP driver become mandatory at some point?
Please understand that any unhappiness about this plan is not directed at you personally (or *should* not be), but just the idea of adding yet another binary blob to the coreboot boot flow. I've been in this same spot and understand the frustration of just trying to get your work done, while the community is unhappy about the direction of the work being done.
Thanks very much. Martin
Aug 14, 2023, 14:53 by jeremy.compostella@intel.com:
Dear coreboot developers,
With Raptor Lake, we introduced the Pre-Memory Sign-of-Life feature which displays an on-screen message while firmware components such as coreboot, Firmware Support Package Memory (FSP-M) or, CSME perform long time operations during pre-memory stages.
We propose to take advantage of a proprietary driver Intel already supports, validates and includes in FSP silicon: the Intel Graphics PEIM (Pre-EFI Initialization Module) driver also known as the GOP (Graphical Output Protocol) driver.
This driver is designed to run in post-memory initialization stages. Therefore, we derived a new version capable of running in pre-memory stages which we called µGOP. This version is specifically designed to perform graphics legacy VGA initialization.
We intend to keep providing such a binary base solution on the long run as it addresses our software convergence goals and is compatible with early platform development stage constraints. > libgfxinit https://github.com/coreboot/libgfxinit> supports can always be added later by the open-source community once the Graphics Programmer Reference Manuals are published.
Below, we present the work we performed to run this µGOP driver from coreboot romstage. It allows to initialize graphics with a very similar flow compared to > libgfxinit https://github.com/coreboot/libgfxinit> use.
Our goal is to start collecting feedback. We will release all the patches on coreboot.org under the > ugop https://review.coreboot.org/q/topic:ugop> topic soon.
1.> µGOP driver interface
The uGOP PEIM provides the following PEIM-to-PEIM protocol under the > 31a4622d-0e21-40a2-80db-c44208fce1b5> GUID.
#define> > PEI_PREMEM_GRAPHICS_PPI_GUID> { \ 0x31a4622d, 0x0e21, 0x40a2, 0x80, 0xdb, 0xc4, 0x42, 0x08, 0xfc, 0xe1, 0xb5 };
The protocol is composed of three fields.
struct> { > UINT32> > Version> ; > PREMEM_PEI_GRAPHICS_INIT> > PreMemGraphicsPpiInit> ; > PREMEM_PEI_GRAPHICS_EXIT> > PreMemGraphicsPpiExit> ;} > PEI_MICRO_GRAPHICS_PPI> ; The current > Version> is > 0x00010000> . Where the upper 16 bits represent the major (1) and the lower 16 bits represent the minor number.
PreMemGraphicsPpiInit()
typedef> EFI_STATUS> (> EFIAPI> *> PREMEM_PEI_GRAPHICS_INIT> ) ( IN > VOID> *> Vbt> );
The > PreMemGraphicsPpiInit()> should be supplied with a pointer to the Video BIOS Table.
PreMemGraphicsPpiExit()> does not take any parameters. This function must be called to disable VGA graphics configuration once not necessary anymore. Not performing this operation may lead to undesirable behaviour when other graphics stack starts (GOP in FSP-S or Operating System driver). 2.> Integration
As we intend to run µGOP driver in romstage, we want to keep the required coreboot code as small and efficient as possible. For this reason, we discarded re-using the EDK2 code which would have a major impact on the romstage binary size in addition to adding complication to the build scripts. Instead, we implemented a limited set of Pre-EFI Initialization services. The code is small and designed to accommodate a simple PEIM driver such as µGOP.
2.1.> PEI services
µGOP depends on a limited of PEI services:
InstallPpi()> to install the PEIM Graphics PPI LocatePpi()> to access PEIM-to-PEIM Interface (PPI) Dependencies AllocatePool()> to dynamically allocate memory to handle internal data structure such as display information … GetHobList()> and > CreateHob()> to access Hand Off Blocks (HOB) holding runtime data 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.
2.2.> PEI services pointer
µ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 https://uefi.org/sites/default/files/resources/PI_Spec_1_6.pdf> > 5.4 PEI Services Table Retrieval> ). Since > coreboot x86/exception https://github.com/coreboot/coreboot/blob/master/src/arch/x86/exception.c> 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.
2.3.> Portable Executable Relocation
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 https://review.coreboot.org/c/coreboot/+/76762> ).
2.4.> Uncompressed VBT
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 https://review.coreboot.org/c/coreboot/+/76816> ).
3.> Code flow
4.> Performances analysis
The analysis below is based on a µGOP binary with eDP and HDMI support.
4.1.> Size impact
When > CONFIG_UGOP_EARLY_GRAPHICS> is set
ugop.efi> is included as a CBFS file romstage> includes extra code: > pei.c> , > ugop.c> and > ux.c vbt.bin> is stored uncompressed instead of lzma compressed CBFS File UGOP_EARLY_GRAPHICS=n (bytes) UGOP_EARLY_GRAPHICS=y (bytes) Delta (bytes) µGOP 0 68448 68448 romstage 126128 136256 10128 vbt.bin 1264 9216 7952 Total 127392 213920 86528
The use of µGOP in coreboot represents a size increase of around 84 KB per region (> COREBOOT> , > FW_MAIN_A> and > FW_MAIN_B> ).
4.2.> Regular Boot time impact (no Sign-of-Life)
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.
Start ID Start Description End ID End Description Delta (ms) 947 CSE received 'CPU Reset Done Ack sent' from PMC 991 Die Management Unit (DMU) load completed +1.0 507 starting to verify body (load+SHA2+RSA) 508 finished loading body +4.7 510 finished verifying body signature (RSA) 511 starting TPM PCR extend -0.8 1030 finished EC verification 1040 finished storage device initialization +1.4
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> .
4.3.> Cache-As-Ram
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:
Object file .bss section size (bytes) pei.o 6730 ugop.o 9 6739
With µGOP sign-of-life, there is an extra 7 KB cache-as-ram use.
4.4.> Conclusion
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).
5.> Summary
This Sign-of-Life µGOP driver based implementation presents the following advantages:
it needs a limited code addition it has a limited impact on the performance its flow and boot performance impact is comparable to libgfxinit solution it is compatible with our software convergence goals it can be available during new platform development early stages which help our partners to test the feature and stabilize the platform
Regards,
– Jeremy One Emacs to rule them all
Hi Jeremy,
Thanks for posting this. I know that you're planning on doing a presentation about this in this week's leadership meeting and look forward to that. https://coreboot.org/calendar.html
A few questions:
- How does the uGOP driver work with libgfxinit? Does using uGOP mean
that the full GOP driver then needs to be used, or can the system transition back to libgfxinit after memory is initialized.
uGOP does not interact with libgfxinit. However, even though we could not test it, there is no reason to think libgfxinit would not work properly if run after uGOP.
- When is the Graphics Programmer Reference Manuals going to be
published so that the support can be added? Is this planned for next month, next year, or not currently planned, but hoped for?
We do not have a clear commitment that the Meteor Lake Programmer Manual are going to published publicly. i915 public driver code can be used as a reference once it fully supports Meteor Lake graphics generation.
- Is there a reason that the uGOP driver can't be open sourced, at
least once the Graphics Programmer Reference Manuals are released?
We cannot open-source the code for platforms for which the PRMs are not publicly published and we currently do not have a commitment for having RPMs for Meteor Lake.
- When you talk about the differences in time between the uGOP driver
and libgfxinit, is that strictly due to when they are called, or is there some further difference that the uGOP driver is able to accomplish that libgfxinit wouldn't ever be able to do?
This is not due to the way they are being called. We have not investigated the reasons behind why uGOP and GOP also are faster to bring up graphics. This is just an observation.
- Is there a reason that Intel is unwilling to add (or help add) the
required code to libgfxinit, an open source solution that according to your notes should be comparable to the uGOP binary solution? Would Intel be willing to help once the reference manuals are released, or is any cooperation between intel and the community on libgfxinit just not able to happen?
libgfxinit presents some challenges for us: - This component is only used by coreboot which does fit our software platform convergence goal - it is open-source which prevent us from using it as a solution until PRMs are publicly published - It is written in SPARK making it very specific and also most Intel GFX engineers are not familiar with ADA.
- I assume that the uGOP driver is completely optional, and is only
needed to show early signs of life. Is that correct, or could the uGOP driver become mandatory at some point?
uGOP is only an option we want to make available for pre-memory Sign-of-Life use-cases. uGOP, even though it looks like yet another blob, is actually mostly just sharing what is already in FSP-S. We are offering to make it available outside of FSP-M to offer more flexibility in the use-cases for coreboot and chromebook devices.
Please understand that any unhappiness about this plan is not directed at you personally (or *should* not be), but just the idea of adding yet another binary blob to the coreboot boot flow. I've been in this same spot and understand the frustration of just trying to get your work done, while the community is unhappy about the direction of the work being done.
Thanks very much. Martin
Aug 14, 2023, 14:53 by jeremy.compostella@intel.com:
Dear coreboot developers,
With Raptor Lake, we introduced the Pre-Memory Sign-of-Life feature
which displays an on-screen message while firmware components such as coreboot, Firmware Support Package Memory (FSP-M) or, CSME perform long time operations during pre-memory stages.
We propose to take advantage of a proprietary driver Intel already
supports, validates and includes in FSP silicon: the Intel Graphics PEIM (Pre-EFI Initialization Module) driver also known as the GOP (Graphical Output Protocol) driver.
This driver is designed to run in post-memory initialization
stages. Therefore, we derived a new version capable of running in pre-memory stages which we called µGOP. This version is specifically designed to perform graphics legacy VGA initialization.
We intend to keep providing such a binary base solution on the long
run as it addresses our software convergence goals and is compatible with early platform development stage constraints. > libgfxinit https://github.com/coreboot/libgfxinit> supports can always be added later by the open-source community once the Graphics Programmer Reference Manuals are published.
Below, we present the work we performed to run this µGOP driver from
coreboot romstage. It allows to initialize graphics with a very similar flow compared to > libgfxinit https://github.com/coreboot/libgfxinit> use.
Our goal is to start collecting feedback. We will release all the
patches on coreboot.org under the > ugop https://review.coreboot.org/q/topic:ugop> topic soon.
1.> µGOP driver interface
The uGOP PEIM provides the following PEIM-to-PEIM protocol under the 31a4622d-0e21-40a2-80db-c44208fce1b5> GUID.
#define> > PEI_PREMEM_GRAPHICS_PPI_GUID> { \ 0x31a4622d, 0x0e21,
0x40a2, 0x80, 0xdb, 0xc4, 0x42, 0x08, 0xfc, 0xe1, 0xb5 };
The protocol is composed of three fields.
struct> { > UINT32> > Version> ; > PREMEM_PEI_GRAPHICS_INIT> >
PreMemGraphicsPpiInit> ; > PREMEM_PEI_GRAPHICS_EXIT> > PreMemGraphicsPpiExit> ;} > PEI_MICRO_GRAPHICS_PPI> ;
The current > Version> is > 0x00010000> . Where the upper 16 bits
represent the major (1) and the lower 16 bits represent the minor number.
PreMemGraphicsPpiInit()
typedef> EFI_STATUS> (> EFIAPI> *> PREMEM_PEI_GRAPHICS_INIT> ) ( IN VOID> *> Vbt> );
The > PreMemGraphicsPpiInit()> should be supplied with a pointer to
the Video BIOS Table.
PreMemGraphicsPpiExit()> does not take any parameters. This function
must be called to disable VGA graphics configuration once not necessary anymore. Not performing this operation may lead to undesirable behaviour when other graphics stack starts (GOP in FSP-S or Operating System driver).
2.> Integration
As we intend to run µGOP driver in romstage, we want to keep the
required coreboot code as small and efficient as possible. For this reason, we discarded re-using the EDK2 code which would have a major impact on the romstage binary size in addition to adding complication to the build scripts. Instead, we implemented a limited set of Pre-EFI Initialization services. The code is small and designed to accommodate a simple PEIM driver such as µGOP.
2.1.> PEI services
µGOP depends on a limited of PEI services:
InstallPpi()> to install the PEIM Graphics PPI LocatePpi()> to access PEIM-to-PEIM Interface (PPI) Dependencies AllocatePool()> to dynamically allocate memory to handle internal
data structure such as display information …
GetHobList()> and > CreateHob()> to access Hand Off Blocks (HOB) holding runtime data 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.
2.2.> PEI services pointer
µ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 https://uefi.org/sites/default/files/resources/PI_Spec_1_6.pdf> > 5.4 PEI Services Table Retrieval> ). Since > coreboot x86/exception https://github.com/coreboot/coreboot/blob/master/src/arch/x86/exception.c> 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.
2.3.> Portable Executable Relocation
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 https://review.coreboot.org/c/coreboot/+/76762> ).
2.4.> Uncompressed VBT
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 https://review.coreboot.org/c/coreboot/+/76816> ).
3.> Code flow
4.> Performances analysis
The analysis below is based on a µGOP binary with eDP and HDMI support.
4.1.> Size impact
When > CONFIG_UGOP_EARLY_GRAPHICS> is set
ugop.efi> is included as a CBFS file romstage> includes extra code: > pei.c> , > ugop.c> and > ux.c vbt.bin> is stored uncompressed instead of lzma compressed CBFS File UGOP_EARLY_GRAPHICS=n (bytes) UGOP_EARLY_GRAPHICS=y (bytes) Delta (bytes) µGOP 0 68448 68448 romstage 126128 136256 10128 vbt.bin 1264 9216 7952 Total 127392 213920 86528
The use of µGOP in coreboot represents a size increase of around 84
KB per region (> COREBOOT> , > FW_MAIN_A> and > FW_MAIN_B> ).
4.2.> Regular Boot time impact (no Sign-of-Life)
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.
Start ID Start Description End ID End Description Delta (ms) 947 CSE received 'CPU Reset Done Ack sent' from PMC 991 Die Management Unit (DMU) load completed +1.0 507 starting to verify body (load+SHA2+RSA) 508 finished loading body +4.7 510 finished verifying body signature (RSA) 511 starting TPM PCR extend -0.8 1030 finished EC verification 1040 finished storage device initialization +1.4
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> .
4.3.> Cache-As-Ram
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:
Object file .bss section size (bytes) pei.o 6730 ugop.o 9 6739
With µGOP sign-of-life, there is an extra 7 KB cache-as-ram use.
4.4.> Conclusion
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).
5.> Summary
This Sign-of-Life µGOP driver based implementation presents the following advantages:
it needs a limited code addition it has a limited impact on the performance its flow and boot performance impact is comparable to libgfxinit solution it is compatible with our software convergence goals it can be available during new platform development early stages
which help our partners to test the feature and stabilize the platform
Regards,
– Jeremy One Emacs to rule them all
Hi Jeremy,
On 24.08.23 00:24, Compostella, Jeremy wrote:
- Is there a reason that the uGOP driver can't be open sourced, at
least once the Graphics Programmer Reference Manuals are released?
We cannot open-source the code for platforms for which the PRMs are not publicly published and we currently do not have a commitment for having RPMs for Meteor Lake.
there's something that hit the news shortly after today's meeting: https://www.phoronix.com/news/Intel-Lunar-Lake-Display-Linux
I know this doesn't mean that code is already working. Still, it would seem that some of your colleagues are about 24 months ahead of you when it comes to what they can publish. I'm starting to wonder, do you maybe talk to the wrong people internally at Intel?
Or are we really talking about customers that want the driver ready more than 2 years before platform launch? In which case I'd have to say, you seem rather late for MTL, no matter what driver.
Regards, Nico
Hi Jeremy,
On 14.08.23 22:52, Compostella, Jeremy wrote:
We propose to take advantage of a proprietary driver Intel already supports, validates and includes in FSP silicon: the Intel Graphics PEIM (Pre-EFI Initialization Module) driver also known as the GOP (Graphical Output Protocol) driver.
just to make sure nobody makes wrong assumptions: Will the uGOP be open-source or proprietary as well? I first thought the latter. But your proposed code-flow looks like some sort of dynamic linking with coreboot.
We intend to keep providing such a binary base solution on the long run as it addresses our software convergence goals and is compatible with early platform development stage constraints. [libgfxinit] supports can always be added later by the open-source community once the Graphics Programmer Reference Manuals are published.
Sad to hear about this decision. It seems Intel is forgetting about non-consumer products (e.g. embedded market) where the code isn't needed years ahead of a platform launch.
We also noticed that microGOP is faster to bring-up graphics than libgfxinit. Indeed, according to previously captured numbers on Raptor Lake compared to some number of microGOP on Meteor Lake, microGOP is three times faster to bring up graphics than libgfxinit on an eDP panel (119 ms vs 373 ms).
Configuring the hardware and bringing up the eDP link should take about 20~30ms mostly depending on how long it takes to read the EDID. The longer delays are likely about panel power sequencing. IIRC, libgfxinit falls back to hardcoded default values if the sequencer is unconfigured, while the GOP just leaves it like that. Chromebooks often skip the configuration[1] in firmware and leave it to the OS driver. Using wrong delays probably doesn't hurt on a rare interactive boot. However, I guess doing this on regular boots might not be the best idea.
Nico
+ Subrata
On Tue, 22 Aug 2023 at 15:35, Nico Huber nico.h@gmx.de wrote:
Hi Jeremy,
On 14.08.23 22:52, Compostella, Jeremy wrote:
We propose to take advantage of a proprietary driver Intel already
supports, validates and includes in FSP silicon: the Intel Graphics PEIM (Pre-EFI Initialization Module) driver also known as the GOP (Graphical Output Protocol) driver.
just to make sure nobody makes wrong assumptions: Will the uGOP be open-source or proprietary as well? I first thought the latter. But your proposed code-flow looks like some sort of dynamic linking with coreboot.
We intend to keep providing such a binary base solution on the long run
as it addresses our software convergence goals and is compatible with early platform development stage constraints. [libgfxinit] supports can always be added later by the open-source community once the Graphics Programmer Reference Manuals are published.
Sad to hear about this decision. It seems Intel is forgetting about non-consumer products (e.g. embedded market) where the code isn't needed years ahead of a platform launch.
We also noticed that microGOP is faster to bring-up graphics than
libgfxinit. Indeed, according to previously captured numbers on Raptor Lake compared to some number of microGOP on Meteor Lake, microGOP is three times faster to bring up graphics than libgfxinit on an eDP panel (119 ms vs 373 ms).
Configuring the hardware and bringing up the eDP link should take about 20~30ms mostly depending on how long it takes to read the EDID. The longer delays are likely about panel power sequencing. IIRC, libgfxinit falls back to hardcoded default values if the sequencer is unconfigured, while the GOP just leaves it like that. Chromebooks often skip the configuration[1] in firmware and leave it to the OS driver. Using wrong delays probably doesn't hurt on a rare interactive boot. However, I guess doing this on regular boots might not be the best idea.
Nico
[1] https://doc.coreboot.org/gfx/display-panel.html
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi
We propose to take advantage of a proprietary driver Intel already
supports, validates and includes in FSP silicon: the Intel Graphics PEIM (Pre-EFI Initialization Module) driver also known as the GOP (Graphical Output Protocol) driver.
Usually the reasoning for using a binary is because the hardware cannot be publicly documented (e.g. DRAM controller) or because they are cryptographically signed. That is however not the case for Intel display controllers as typically both code (Intel i915 driver) and documentation exist. Maybe it's just marketing, but I was under the impression that Intel is actively promoting open source on the graphics side with initiatives as oneAPI.
I think allowing binary only PEI modules just because they exist and are supported by the vendor is a very slippery slope. The same argument could be applied to pretty much everything (just include your code doing X as a PEI module), which goes against the project goals of coreboot being an open source project. This is of course not part of your proposal but I'm cautious of it.
To nuance this, other vendors only provide a proprietary VBIOS as an option for graphic init so it's not particularly worse.
2.1. PEI services
µ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.
That looks like some form of linking, which might result in legal troubles as the GPL does not allow it. We already have code similar to ReportStatusCode and ramstage PPI so maybe it's not a problem.
On a technical note: only coreboot's ramstage has a heap. Romstage has less resources available so we avoided using a heap thus far. AllocatePool would break that tradition. How does one know how much heap is needed? It's best to avoid memory allocations at runtime.
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).
Is this relevant? I was under the impression that the display is only used to notify the user of a very long DRAM init, where regular boots use cached results. If the dram init is orders of magnitude longer than the display init this performance difference is meaningless.
it is compatible with our software convergence goals
Can you elaborate on this?
Thanks for taking the time to clearly present your arguments!
Arthur
On Tue, Aug 22, 2023 at 3:35 PM Nico Huber nico.h@gmx.de wrote:
Hi Jeremy,
On 14.08.23 22:52, Compostella, Jeremy wrote:
We propose to take advantage of a proprietary driver Intel already
supports, validates and includes in FSP silicon: the Intel Graphics PEIM (Pre-EFI Initialization Module) driver also known as the GOP (Graphical Output Protocol) driver.
just to make sure nobody makes wrong assumptions: Will the uGOP be open-source or proprietary as well? I first thought the latter. But your proposed code-flow looks like some sort of dynamic linking with coreboot.
We intend to keep providing such a binary base solution on the long run
as it addresses our software convergence goals and is compatible with early platform development stage constraints. [libgfxinit] supports can always be added later by the open-source community once the Graphics Programmer Reference Manuals are published.
Sad to hear about this decision. It seems Intel is forgetting about non-consumer products (e.g. embedded market) where the code isn't needed years ahead of a platform launch.
We also noticed that microGOP is faster to bring-up graphics than
libgfxinit. Indeed, according to previously captured numbers on Raptor Lake compared to some number of microGOP on Meteor Lake, microGOP is three times faster to bring up graphics than libgfxinit on an eDP panel (119 ms vs 373 ms).
Configuring the hardware and bringing up the eDP link should take about 20~30ms mostly depending on how long it takes to read the EDID. The longer delays are likely about panel power sequencing. IIRC, libgfxinit falls back to hardcoded default values if the sequencer is unconfigured, while the GOP just leaves it like that. Chromebooks often skip the configuration[1] in firmware and leave it to the OS driver. Using wrong delays probably doesn't hurt on a rare interactive boot. However, I guess doing this on regular boots might not be the best idea.
Nico
[1] https://doc.coreboot.org/gfx/display-panel.html
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi Arthur,
On 23.08.23 10:41, Arthur Heymans wrote:
We already have code similar to ReportStatusCode
can you point me to the code integrating this? I could find this identifier only in vendorcode/ headers. Is it for debugging?
and ramstage PPI so maybe it's not a problem.
I thought this was kept optional--one of the many things dumped into our repo that didn't take off. Just checked and it's enabled by default oO, but I could disable it and coreboot built. Does anybody use this PPI "feature" in a product?
Nico
ReportStatusCode() to report debug information which coreboot prints
using printk.
can you point me to the code integrating this? I could find this
identifier only in vendorcode/ headers. Is it for debugging?
I meant code calling back to the coreboot console in general for debugging. A few examples: 1) https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/src... 2) https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/src...
I thought this was kept optional--one of the many things dumped into our
repo that didn't take off. Just checked and it's enabled by default oO, but I could disable it and coreboot built. Does anybody use this PPI "feature" in a product?
I thought the CPU PPI was enabled by default and necessary(?) on all Intel products (except xeon-sp) since Intel Icelake. If the PPI is not provided the FSP will do the whole CPU init on its own:
/** Offset 0x06B0 - CpuMpPpi <b>Optional</b> pointer to the boot loader's implementation of EFI_PEI_MP_SERVICES_PPI. If not NULL, FSP will use the boot loader's implementation of multiprocessing.
On Wed, Aug 23, 2023 at 11:14 AM Nico Huber nico.h@gmx.de wrote:
Hi Arthur,
On 23.08.23 10:41, Arthur Heymans wrote:
We already have code similar to ReportStatusCode
can you point me to the code integrating this? I could find this identifier only in vendorcode/ headers. Is it for debugging?
and ramstage PPI so maybe it's not a problem.
I thought this was kept optional--one of the many things dumped into our repo that didn't take off. Just checked and it's enabled by default oO, but I could disable it and coreboot built. Does anybody use this PPI "feature" in a product?
Nico
On 23.08.23 11:32, Arthur Heymans wrote:
ReportStatusCode() to report debug information which coreboot prints
using printk.
can you point me to the code integrating this? I could find this
identifier only in vendorcode/ headers. Is it for debugging?
I meant code calling back to the coreboot console in general for debugging. A few examples:
https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/src... 2) https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/src...
Thanks, seems ok to me to use it for debugging.
I thought this was kept optional--one of the many things dumped into our
repo that didn't take off. Just checked and it's enabled by default oO, but I could disable it and coreboot built. Does anybody use this PPI "feature" in a product?
I thought the CPU PPI was enabled by default and necessary(?) on all Intel products (except xeon-sp) since Intel Icelake.
That is what we were told initially, but then the `SkipMpInit` UPD stayed and there was effort to keep it working, e.g.
8409f156d588 (soc/intel/alderlake: Remove dependency of FSP-S CpuMpPei Module)
Grepping right now, this seems to be missing for Meteor Lake, though.
Nico
Hi Arthur,
supports, validates and includes in FSP silicon: the Intel Graphics PEIM (Pre-EFI Initialization Module) driver also known as the GOP (Graphical Output Protocol) driver.
Usually the reasoning for using a binary is because the hardware cannot be publicly documented (e.g. DRAM controller) or because they are cryptographically signed. That is however not the case for Intel display controllers as typically both code (Intel i915 driver) and documentation exist. Maybe it's just marketing, but I was under the impression that Intel is actively promoting open source on the graphics side with initiatives as oneAPI.
There is information of the graphics IP which cannot be currently make public. i915 driver fully supporting this generation will eventually be published but the documentation isn't not yet available and we do not even know when and if it will be publicly available.
I think allowing binary only PEI modules just because they exist and are supported by the vendor is a very slippery slope. The same argument could be applied to pretty much everything (just include your code doing X as a PEI module), which goes against the project goals of coreboot being an open source project. This is of course not part of your proposal but I'm cautious of it.
To nuance this, other vendors only provide a proprietary VBIOS as an option for graphic init so it's not particularly worse.
I absolutely agree with your point but the availability is not the only reason. We currently cannot publish an open-source driver fully supporting this graphics generation while at the same time we need to enable coreboot for Meteor Lake with the support of Pre-Me mory sign-of-life. \microP}GOP, even though it looks like yet another blob is actually mostly just sharing what is already in FSP-S. Instead of making it part of FSP-M, we would like to make it available separately to offer more flexibility in the use-cases for coreboot and chromebook devices.
That looks like some form of linking, which might result in legal troubles as the GPL does not allow it. We already have code similar to ReportStatusCode and ramstage PPI so maybe it's not a problem.
This is not drastically different than what is done with FSP today and the API to support is publicly documented.
On a technical note: only coreboot's ramstage has a heap. Romstage has less resources available so we avoided using a heap thus far. AllocatePool would break that tradition. How does one know how much heap is needed? It's best to avoid memory allocations at runtime.
The allocation service has been calibrated for the need of microGOP.
it is compatible with our software convergence goals
Can you elaborate on this?
It is difficult and time consuming to support very different and various implementation of a graphics driver. libgfxinit is only used by coreboot. GOP is widely used by Intel product using variable IA firmware platforms.
Regards,
Hi Jeremy and all the rest of the Intel folk who took the time to come to the coreboot meeting today. I wasn't thrilled with the message you were there to present, but I was happy to see all who attended.
I may be incorrect, but I assume that Google has been talking with Intel about displaying a screen during memory training for roughly the same amount of time that it's been discussed with AMD. For us, I believe that discussion started well over a year ago.
For this to be brought up now, with the argument of "Well, we need it for this coming platform" seems like a problem brought on by not having this discussion with the coreboot community much earlier in the process. The urgency of getting a solution merged at this point is not coreboot's doing or responsibility, and it seems like coreboot is being pressured to accept it based on the timing, which doesn't feel great.
The argument of "we'd like one solution for both coreboot and UEFI firmware" seems reasonable to me, but there seems to have been little attention paid to what coreboot, an open source project, actually wants. Instead, the position seems to be one of forcing coreboot to use what the UEFI firmware uses.
I don't like that idea, but as was said in the meeting today, coreboot is willing to accept that, but on the condition that the source for the binary (and future similar binaries) is made open. To show good faith Intel could guarantee that the source will be opened when it can (supplying a date) and release the GOP driver source for platforms that do have released PRMs.
You say here that the uGOP functionality already exists in the FSP, but since it's a proprietary blob, I can't actually *tell* what's in there (not that I'm doubting your word). This argument is also one of "What's the harm in just one more blob?" which has no reason to ever end. At some point, we need to say "no more". This seems like a reasonable time.
I understand why companies feel like they need to keep some things proprietary, even if I don't like it. This blob just doesn't feel like one of those things. This feels like something that could be opened, Intel just can't be bothered to do the work to open it, at least not in a timely manner.
Someone inside Intel has the authority to open source this binary. Someone can get the programmer manual released. If this is an important feature for this Chromebook, surely that person will decide that it makes sense to open source it so that it can be used with coreboot. If they decide it's not important enough, that's fine too.
Apologies again to all the engineers who are stuck in the middle here. I'll buy a round of drinks if I see you at the Open Source Firmware Conference in October.
Martin
Aug 23, 2023, 16:25 by jeremy.compostella@intel.com:
Hi Jeremy,
Thanks for posting this. I know that you're planning on doing a presentation about this in this week's leadership meeting and look forward to that. https://coreboot.org/calendar.html
A few questions:
- How does the uGOP driver work with libgfxinit? Does using uGOP mean
that the full GOP driver then needs to be used, or can the system transition back to libgfxinit after memory is initialized.
uGOP does not interact with libgfxinit. However, even though we could not test it, there is no reason to think libgfxinit would not work properly if run after uGOP.
- When is the Graphics Programmer Reference Manuals going to be
published so that the support can be added? Is this planned for next month, next year, or not currently planned, but hoped for?
We do not have a clear commitment that the Meteor Lake Programmer Manual are going to published publicly. i915 public driver code can be used as a reference once it fully supports Meteor Lake graphics generation.
- Is there a reason that the uGOP driver can't be open sourced, at
least once the Graphics Programmer Reference Manuals are released?
We cannot open-source the code for platforms for which the PRMs are not publicly published and we currently do not have a commitment for having RPMs for Meteor Lake.
- When you talk about the differences in time between the uGOP driver
and libgfxinit, is that strictly due to when they are called, or is there some further difference that the uGOP driver is able to accomplish that libgfxinit wouldn't ever be able to do?
This is not due to the way they are being called. We have not investigated the reasons behind why uGOP and GOP also are faster to bring up graphics. This is just an observation.
- Is there a reason that Intel is unwilling to add (or help add) the
required code to libgfxinit, an open source solution that according to your notes should be comparable to the uGOP binary solution? Would Intel be willing to help once the reference manuals are released, or is any cooperation between intel and the community on libgfxinit just not able to happen?
libgfxinit presents some challenges for us:
- This component is only used by coreboot which does fit our software
platform convergence goal
- it is open-source which prevent us from using it as a solution until
PRMs are publicly published
- It is written in SPARK making it very specific and also most Intel
GFX engineers are not familiar with ADA.
- I assume that the uGOP driver is completely optional, and is only
needed to show early signs of life. Is that correct, or could the uGOP driver become mandatory at some point?
uGOP is only an option we want to make available for pre-memory Sign-of-Life use-cases. uGOP, even though it looks like yet another blob, is actually mostly just sharing what is already in FSP-S. We are offering to make it available outside of FSP-M to offer more flexibility in the use-cases for coreboot and chromebook devices.
Please understand that any unhappiness about this plan is not directed at you personally (or *should* not be), but just the idea of addingmakmakinging yet another binary blob to the coreboot boot flow. I've been in this same spot and understand the frustration of just trying to get your work done, while the community is unhappy about the direction of the work being done.
Thanks very much. Martin
Aug 14, 2023, 14:53 by jeremy.compostella@intel.com:
Dear coreboot developers,
With Raptor Lake, we introduced the Pre-Memory Sign-of-Life feature
which displays an on-screen message while firmware components such as coreboot, Firmware Support Package Memory (FSP-M) or, CSME perform long time operations during pre-memory stages.
We propose to take advantage of a proprietary driver Intel already
supports, validates and includes in FSP silicon: the Intel Graphics PEIM (Pre-EFI Initialization Module) driver also known as the GOP (Graphical Output Protocol) driver.
This driver is designed to run in post-memory initialization
stages. Therefore, we derived a new version capable of running in pre-memory stages which we called µGOP. This version is specifically designed to perform graphics legacy VGA initialization.
We intend to keep providing such a binary base solution on the long
run as it addresses our software convergence goals and is compatible with early platform development stage constraints. > libgfxinit https://github.com/coreboot/libgfxinit> supports can always be added later by the open-source community once the Graphics Programmer Reference Manuals are published.
Below, we present the work we performed to run this µGOP driver from
coreboot romstage. It allows to initialize graphics with a very similar flow compared to > libgfxinit https://github.com/coreboot/libgfxinit> use.
Our goal is to start collecting feedback. We will release all the
patches on coreboot.org under the > ugop https://review.coreboot.org/q/topic:ugop> topic soon.
1.> µGOP driver interface
The uGOP PEIM provides the following PEIM-to-PEIM protocol under the 31a4622d-0e21-40a2-80db-c44208fce1b5> GUID.
#define> > PEI_PREMEM_GRAPHICS_PPI_GUID> { \ 0x31a4622d, 0x0e21,
0x40a2, 0x80, 0xdb, 0xc4, 0x42, 0x08, 0xfc, 0xe1, 0xb5 };
The protocol is composed of three fields.
struct> { > UINT32> > Version> ; > PREMEM_PEI_GRAPHICS_INIT> >
PreMemGraphicsPpiInit> ; > PREMEM_PEI_GRAPHICS_EXIT> > PreMemGraphicsPpiExit> ;} > PEI_MICRO_GRAPHICS_PPI> ;
The current > Version> is > 0x00010000> . Where the upper 16 bits
represent the major (1) and the lower 16 bits represent the minor number.
PreMemGraphicsPpiInit()
typedef> EFI_STATUS> (> EFIAPI> *> PREMEM_PEI_GRAPHICS_INIT> ) ( IN VOID> *> Vbt> );
The > PreMemGraphicsPpiInit()> should be supplied with a pointer to
the Video BIOS Table.
PreMemGraphicsPpiExit()> does not take any parameters. This function
must be called to disable VGA graphics configuration once not necessary anymore. Not performing this operation may lead to undesirable behaviour when other graphics stack starts (GOP in FSP-S or Operating System driver).
2.> Integration
As we intend to run µGOP driver in romstage, we want to keep the
required coreboot code as small and efficient as possible. For this reason, we discarded re-using the EDK2 code which would have a major impact on the romstage binary size in addition to adding complication to the build scripts. Instead, we implemented a limited set of Pre-EFI Initialization services. The code is small and designed to accommodate a simple PEIM driver such as µGOP.
2.1.> PEI services
µGOP depends on a limited of PEI services:
InstallPpi()> to install the PEIM Graphics PPI LocatePpi()> to access PEIM-to-PEIM Interface (PPI) Dependencies AllocatePool()> to dynamically allocate memory to handle internal
data structure such as display information …
GetHobList()> and > CreateHob()> to access Hand Off Blocks (HOB) holding runtime data 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.
2.2.> PEI services pointer
µ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 https://uefi.org/sites/default/files/resources/PI_Spec_1_6.pdf> > 5.4 PEI Services Table Retrieval> ). Since > coreboot x86/exception https://github.com/coreboot/coreboot/blob/master/src/arch/x86/exception.c> 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.
2.3.> Portable Executable Relocation
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 https://review.coreboot.org/c/coreboot/+/76762> ).
2.4.> Uncompressed VBT
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 https://review.coreboot.org/c/coreboot/+/76816> ).
3.> Code flow
4.> Performances analysis
The analysis below is based on a µGOP binary with eDP and HDMI support.
4.1.> Size impact
When > CONFIG_UGOP_EARLY_GRAPHICS> is set
ugop.efi> is included as a CBFS file romstage> includes extra code: > pei.c> , > ugop.c> and > ux.c vbt.bin> is stored uncompressed instead of lzma compressed CBFS File UGOP_EARLY_GRAPHICS=n (bytes) UGOP_EARLY_GRAPHICS=y (bytes) Delta (bytes) µGOP 0 68448 68448 romstage 126128 136256 10128 vbt.bin 1264 9216 7952 Total 127392 213920 86528
The use of µGOP in coreboot represents a size increase of around 84
KB per region (> COREBOOT> , > FW_MAIN_A> and > FW_MAIN_B> ).
4.2.> Regular Boot time impact (no Sign-of-Life)
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.
Start ID Start Description End ID End Description Delta (ms) 947 CSE received 'CPU Reset Done Ack sent' from PMC 991 Die Management Unit (DMU) load completed +1.0 507 starting to verify body (load+SHA2+RSA) 508 finished loading body +4.7 510 finished verifying body signature (RSA) 511 starting TPM PCR extend -0.8 1030 finished EC verification 1040 finished storage device initialization +1.4
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> .
4.3.> Cache-As-Ram
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:
Object file .bss section size (bytes) pei.o 6730 ugop.o 9 6739
With µGOP sign-of-life, there is an extra 7 KB cache-as-ram use.
4.4.> Conclusion
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).
5.> Summary
This Sign-of-Life µGOP driver based implementation presents the following advantages:
it needs a limited code addition it has a limited impact on the performance its flow and boot performance impact is comparable to libgfxinit solution it is compatible with our software convergence goals it can be available during new platform development early stages
which help our partners to test the feature and stabilize the platform
Regards,
– Jeremy One Emacs to rule them all
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
On 24.08.23 07:02, Martin Roth via coreboot wrote:
I don't like that idea, but as was said in the meeting today, coreboot is willing to accept that, but on the condition that the source for the binary (and future similar binaries) is made open. To show good faith Intel could guarantee that the source will be opened when it can (supplying a date) and release the GOP driver source for platforms that do have released PRMs.
IMO releasing a PRM can't act as a reference point for this. As Intel decides when and if the release of PRMs happens and that is often more than a year after a platform launch, the code would be outdated and use- less by then.
But before entertaining the idea of a later open-sourced blob further, I want everybody to be aware of the following: Last time a similar blob interface was merged upstream, it took 11 months to get it through review[1]. And that was for an optional interface; the blob can do its primary job without it. So even if by some miracle we would agree on a blob now, it would still need to be designed, discussed and reviewed. It's too late for Meteor Lake anyway. So I don't see why the community should bother with it.
Nico
[1] commit 6662cb3dc2c4fe56cb75f83e1e7015287870cf01 Author: Subrata Banik subratabanik@google.com AuthorDate: Thu Apr 12 19:25:37 2018 +0530 Commit: Patrick Georgi patrick@coreboot.org CommitDate: Tue Mar 19 21:41:01 2019 +0000
drivers/intel/fsp2_0: Implement EFI_MP_SERVICES_PPI structure APIs
I have to say I'm a little disappointed that this is where things stand now. I worked on bringing libgfxinit as up-to-date as I was able to at the time that we, as a community, could continue not using the GOP at all for pre-OS graphics. There was also a hope that Intel would release the PRMs earlier (or at least under NDA to say, Google) and develop libgfxinit under a private branch until the PRMs were released so that we could have libgfxinit as up-to-date as the Linux i915 drivers, i.e. available before the platform is released. Of course, as soon as i915 patches are posted to the kernel mailing list, work could also begin in parallel without the PRMs by reading the patches and trying to port them to libgfxinit.
Also, to be perfectly honest, I don't understand why this "sign-of-life" feature is so critical that it must be available during development. When I (and a few others) came up with the idea at Google, the entire point of the feature is so that end-users who must undergo some kind of firmware update before memory is available or require a new DRAM training session can know that their device which usually boots in a few seconds will take longer during this specific boot. It is not particularly useful during development, as developers should know why their device is taking longer to boot.
Because of this and what I said up above about porting to libgfxinit as soon as i915 patches are available, there ought to be enough time in the product lifecycle to do that port before the product is released, hence making this uGOP unnecessary.
Anyway that's my two cents as someone who was previously involved in this area but is now just an outsider community member now :) -Tim
On Thu, Aug 24, 2023 at 11:21 AM Nico Huber nico.h@gmx.de wrote:
On 24.08.23 07:02, Martin Roth via coreboot wrote:
I don't like that idea, but as was said in the meeting today, coreboot
is willing to accept that, but on the condition that the source for the binary (and future similar binaries) is made open. To show good faith Intel could guarantee that the source will be opened when it can (supplying a date) and release the GOP driver source for platforms that do have released PRMs.
IMO releasing a PRM can't act as a reference point for this. As Intel decides when and if the release of PRMs happens and that is often more than a year after a platform launch, the code would be outdated and use- less by then.
But before entertaining the idea of a later open-sourced blob further, I want everybody to be aware of the following: Last time a similar blob interface was merged upstream, it took 11 months to get it through review[1]. And that was for an optional interface; the blob can do its primary job without it. So even if by some miracle we would agree on a blob now, it would still need to be designed, discussed and reviewed. It's too late for Meteor Lake anyway. So I don't see why the community should bother with it.
Nico
[1] commit 6662cb3dc2c4fe56cb75f83e1e7015287870cf01 Author: Subrata Banik subratabanik@google.com AuthorDate: Thu Apr 12 19:25:37 2018 +0530 Commit: Patrick Georgi patrick@coreboot.org CommitDate: Tue Mar 19 21:41:01 2019 +0000
drivers/intel/fsp2_0: Implement EFI_MP_SERVICES_PPI structure APIs
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Am 27.08.2023 um 19:18 schrieb Tim Wawrzynczak:
Also, to be perfectly honest, I don't understand why this "sign-of-life" feature is so critical that it must be available during development. When I (and a few others) came up with the idea at Google, the entire point of the feature is so that end-users who must undergo some kind of firmware update before memory is available or require a new DRAM training session can know that their device which usually boots in a few seconds will take longer during this specific boot. It is not particularly useful during development, as developers should know why their device is taking longer to boot.
This is an important point: The "Sign of Life" stuff is only needed when the cache is busted. The only situation where we expect (and, as far as I can tell, see) that coming up is when the memory init code changes incompatibly.
By definition the earliest point in time where this can happen is with the first firmware update (if that already breaks the cache, which isn't a given).
Because of this and what I said up above about porting to libgfxinit as soon as i915 patches are available, there ought to be enough time in the product lifecycle to do that port before the product is released, hence making this uGOP unnecessary.
Given the above, SOL is only required after the device is on the market, an even more comfortable position: By that point the entire "welp, muh secrets!!!1" charade is already over.
(And yes, that requires somebody to keep track of additional development effort/costs after release / before the first cache-breaking update)
More options to consider: extend the update procedure so that it can convert an older cache format into a newer cache format as required. That sidesteps that entire "we need to tell the user that their device is busy with no interaction for the next 60 seconds doing stuff they can't appreciate because it's too opaque."
Patrick
-
Arthur Heymans -
Compostella, Jeremy -
Lean Sheng Tan -
Martin Roth -
Nico Huber -
Patrick Georgi -
Tim Wawrzynczak