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