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