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