[coreboot] Re: [RFC] Pre-Memory Sign-of-Life using Intel uGOP

[Patrick Georgi via coreboot]

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
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: [RFC] Pre-Memory Sign-of-Life using Intel uGOP

[Tim Wawrzynczak]

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  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 
> AuthorDate: Thu Apr 12 19:25:37 2018 +0530
> Commit: Patrick Georgi 
> CommitDate: Tue Mar 19 21:41:01 2019 +
>
> drivers/intel/fsp2_0: Implement EFI_MP_SERVICES_PPI structure APIs
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org