Zoran, given that we still see _MP_ and even $PIR tables in BIOS, is it possible that VBT might always be there even if it's not strictly needed?
How do non-EFI kernels get information about video if not via the VBT? On Wed, Apr 5, 2017 at 8:03 AM Zoran Stojsavljevic < zoran.stojsavlje...@gmail.com> wrote: > To Coreboot, > > > http://www.uefi.org/sites/default/files/resources/UPFS11_P4_UEFI_GOP_AMD.pdf > > Please, read about GOP, and what GOP suppose to be. > > So, GOP actually need to replace vBIOS, VBT, legacy INT 10H, and complete > VBE 3.0 standard. Why (I have no idea what INTEL does with GOP and how it > implements it) it is not done in this fashion...?! At least this is my > impression how this should be done. > > I'll continue to investigate. > > Thank you, > Zoran > > On Wed, Apr 5, 2017 at 4:54 PM, Matt DeVillier <matt.devill...@gmail.com> > wrote: > > On Tue, Apr 4, 2017 at 10:12 PM, Zoran Stojsavljevic < > zoran.stojsavlje...@gmail.com> wrote: > > Hello Matt, > > Pretty sure there is NO Option ROM, vBIOS and INT10H. Why INTEL for GOP > uses VBT is point of debate. Probably just reduced functionality up to > 1280x1024. So they have VBT to support BIOS phase GOP GFX. Only! > > > From what I can tell, it's mainly used to provide the output connector > types/mapping to the GOP driver, as well as level shifting etc. > > > > But I am also 100% sure neither GOP, neither VBT survives post BIOS phase. > It is out of mind to use VBT for WUXGA, or 1080p, or 4K displays, don't you > agree? The detected GFX I/F are passed to Linux as Run Time info (via HOB). > Then Linux brings from scratch GFX, using its own, modern I/Fs. And ports > appropriate drivers to existing GFX info from HOB. > > > The VBT data is used by both the Linux and Windows display drivers (via > the OpRegion ACPI structure), and the latter will give you a nice black > screen if your VBT is missing or incorrectly configured. As I noted above, > it appears to be used more for output/pipe info than display modes (which > are all generated from EDID, outside of standard VESA/CEA ones) > > On Tue, Apr 4, 2017 at 10:12 PM, Zoran Stojsavljevic < > zoran.stojsavlje...@gmail.com> wrote: > > Hello Matt, > > Pretty sure there is NO Option ROM, vBIOS and INT10H. Why INTEL for GOP > uses VBT is point of debate. Probably just reduced functionality up to > 1280x1024. So they have VBT to support BIOS phase GOP GFX. Only! > > But I am also 100% sure neither GOP, neither VBT survives post BIOS phase. > It is out of mind to use VBT for WUXGA, or 1080p, or 4K displays, don't you > agree? The detected GFX I/F are passed to Linux as Run Time info (via HOB). > Then Linux brings from scratch GFX, using its own, modern I/Fs. And ports > appropriate drivers to existing GFX info from HOB. > > Zoran > > On Tue, Apr 4, 2017 at 11:51 PM, Matt DeVillier <matt.devill...@gmail.com> > wrote: > > > > On Tue, Apr 4, 2017 at 2:23 PM, Zoran Stojsavljevic < > zoran.stojsavlje...@gmail.com> wrote: > > Furthermore, let me tell you all that this is a mechanism to support ONLY > The Legacy BIOS (UEFI works ONLY with GOP, but this is another > dimension/discussion), and, to all of your knowledge (which I have no idea > how deep it is, I doubt), VBT table survives postmortem BIOS. By Linux, it > will be RELOCATED into much higher (over 1MB) 32bit protected mode memory > (addresses recalculated), and still use INT10H, using vBIOS (Option ROM, my > best guess) down there. > > > no, the UEFI GOP driver needs the VBT to actually do anything. Look at > any current PC UEFI firmware, or even x86 ChromeOS firmware, and you'll see > they all use/contain a VBT still. > > > > >
-- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot