Re: [coreboot] VGA and Graphics

[Igor Skochinsky]

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>  wrote:
ZS> On Tue, Apr 4, 2017 at 10:12 PM, Zoran Stojsavljevic
ZS>  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>  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>  wrote:

ZS> On Tue, Apr 4, 2017 at 2:23 PM, Zoran Stojsavljevic
ZS>  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.

VGA and Graphics

[Zoran Stojsavljevic]

Man, I did not know that my picking on Legacy vBIOS, VBT, and legacy
mechanisms will make such a noise. And so many responses.

I should say, I am glad that I provoked such an avalanche of info, since, I
have to say, I am learning a lot reading this email thread. I hope others
learn a lot too. And... We all are trying to connect missing puzzles. I
certainly do (and pass to you what I do know - NOT always the case)!

I just came back from BBALL, and I am pretty dead, as dead cat's last
jump... It was tough on my body (3:3 on full real court, two hoops, 2
hours)... I'll try reasonably to reply to these emails! :-(
> 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.

Igor,

In present BIOSes (most of them are 64b, thus UEFI), as I understand, there
are three modes of operations:
[1] Legacy only (CSM ON);
[2] Combined mode (have no idea how this does work);
[3] True UEFI (CSM OFF)!

Now, I never use/used mode [2]. I am NOT fan of mixing these modes. I use
[1] if I must too, but my preferred mode is [3].

Regarding these two modes,:
[1] Legacy - does use vBIOS (maximum size 64KB), INT 10H, VBT, and all this
is inherited by OS.
[3] UEFI - does use GOP driver (MORE that 64KB in size, there is no such a
limit as for vBIOS).

These are The Facts. Matt (De Viller) can beat me with the baseball bat,
but this I know, this is in concrete. I would NOT change (about what I
wrote here above) my opinion.

It seems that, after GOP dies, still, orphaned VBT survives post mortem
UEFI (as part of UEFI run time data passed to OS).

I (here, Matt makes me doubtful, and I will thank him for that) always was
naive and thought that VBT is NOT part of GOP driver. But, apparently, I
might be mistaken, and Matt (De Viller) is probably right.

Now... The bloody name VBT is one which confuses me: Video BIOS Table
(VBT). This is my problem, but, if I better think, maybe INTEL CCG/OTC pros
wanted just to continue to inherit the transparency. About what I think,
about VBT, I'll reply to Matt (DaEmon) and Coreboot himself. ;-)

I am glad that I missed some points. :-)

Zoran

On Wed, Apr 5, 2017 at 7:59 PM, Igor Skochinsky via coreboot <
[e-mail]> wrote:
> 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>  wrote:
> ZS> On Tue, Apr 4, 2017 at 10:12 PM, Zoran Stojsavljevic
> ZS>  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>  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>  wrote:
>
> ZS> On Tue, Apr 4, 2017 at 2:23 PM, Zoran Stojsavljevic
> ZS>  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.