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,