[coreboot] VGA and Graphics

[ron minnich]

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.stojsavljevic at 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.devillier at gmail.com>
> wrote:
>
> On Tue, Apr 4, 2017 at 10:12 PM, Zoran Stojsavljevic <
> zoran.stojsavljevic at 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.stojsavljevic at 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.devillier at gmail.com>
> wrote:
>
>
>
> On Tue, Apr 4, 2017 at 2:23 PM, Zoran Stojsavljevic <
> zoran.stojsavljevic at 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.
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20170405/6f7f37c9/attachment.html>