Hello Zoran,
Wednesday, April 5, 2017, 5:03:33 PM, you wrote:
ZS> To Coreboot,
ZS> http://www.uefi.org/sites/default/files/resources/UPFS11_P4_UEFI_GOP_AMD.pdf
ZS> Please, read about GOP, and what GOP suppose to be.
ZS> So, GOP actually need to replace vBIOS, VBT, legacy INT 10H, and ZS> complete VBE 3.0 standard. Why (I have no idea what INTEL does ZS> with GOP and how it implements it) it is not done in this ZS> fashion...?! At least this is my impression how this should be done.
Well, yes, the GOP is used in UEFI for video output (e.g. in the UEFI shell or the BIOS setup screens) and in theory any OS can use it to access video after boot although I don't know any OS that does; at least both Linux and Windows use their own drivers which talk to the hardware directly (and those drivers seem to require VBT currently). Though I think the Windows bootloader (winload.efi) can use GOP to display the boot menu.
Intel provides a binary-only GOP driver (IntelGopDriver.efi) to OEMs who embed it into their UEFI implementations. I don't know if it itself requires VBT.
ZS> I'll continue to investigate.
ZS> Thank you, ZS> Zoran
ZS> On Wed, Apr 5, 2017 at 4:54 PM, Matt DeVillier ZS> matt.devillier@gmail.com wrote: ZS> On Tue, Apr 4, 2017 at 10:12 PM, Zoran Stojsavljevic ZS> zoran.stojsavljevic@gmail.com wrote: ZS> Hello Matt,
ZS> Pretty sure there is NO Option ROM, vBIOS and INT10H. Why INTEL ZS> for GOP uses VBT is point of debate. Probably just reduced ZS> functionality up to 1280x1024. So they have VBT to support BIOS phase GOP GFX. Only!
ZS> From what I can tell, it's mainly used to provide the output ZS> connector types/mapping to the GOP driver, as well as level shifting etc. ZS>
ZS> But I am also 100% sure neither GOP, neither VBT survives post ZS> BIOS phase. It is out of mind to use VBT for WUXGA, or 1080p, or ZS> 4K displays, don't you agree? The detected GFX I/F are passed to ZS> Linux as Run Time info (via HOB). Then Linux brings from scratch ZS> GFX, using its own, modern I/Fs. And ports appropriate drivers to existing GFX info from HOB.
ZS> The VBT data is used by both the Linux and Windows display ZS> drivers (via the OpRegion ACPI structure), and the latter will ZS> give you a nice black screen if your VBT is missing or incorrectly ZS> configured. As I noted above, it appears to be used more for ZS> output/pipe info than display modes (which are all generated from ZS> EDID, outside of standard VESA/CEA ones)
ZS> On Tue, Apr 4, 2017 at 10:12 PM, Zoran Stojsavljevic ZS> zoran.stojsavljevic@gmail.com wrote: ZS> Hello Matt,
ZS> Pretty sure there is NO Option ROM, vBIOS and INT10H. Why INTEL ZS> for GOP uses VBT is point of debate. Probably just reduced ZS> functionality up to 1280x1024. So they have VBT to support BIOS phase GOP GFX. Only!
ZS> But I am also 100% sure neither GOP, neither VBT survives post ZS> BIOS phase. It is out of mind to use VBT for WUXGA, or 1080p, or ZS> 4K displays, don't you agree? The detected GFX I/F are passed to ZS> Linux as Run Time info (via HOB). Then Linux brings from scratch ZS> GFX, using its own, modern I/Fs. And ports appropriate drivers to existing GFX info from HOB.
ZS> Zoran
ZS> On Tue, Apr 4, 2017 at 11:51 PM, Matt DeVillier ZS> matt.devillier@gmail.com wrote:
ZS> On Tue, Apr 4, 2017 at 2:23 PM, Zoran Stojsavljevic ZS> zoran.stojsavljevic@gmail.com wrote: ZS> Furthermore, let me tell you all that this is a mechanism to ZS> support ONLY The Legacy BIOS (UEFI works ONLY with GOP, but this ZS> is another dimension/discussion), and, to all of your knowledge ZS> (which I have no idea how deep it is, I doubt), VBT table survives ZS> postmortem BIOS. By Linux, it will be RELOCATED into much higher ZS> (over 1MB) 32bit protected mode memory (addresses recalculated), ZS> and still use INT10H, using vBIOS (Option ROM, my best guess) down there.
ZS> no, the UEFI GOP driver needs the VBT to actually do anything. ZS> Look at any current PC UEFI firmware, or even x86 ChromeOS ZS> firmware, and you'll see they all use/contain a VBT still.