Re: [coreboot] VGA and Graphics

[Zoran Stojsavljevic]

You see, Nico, you implicitly answered to Ron's quest to make Coreboot
vBIOS/GOP WiKi page... :-)

> Maybe this helps you to untangle this: When the VBT was invented, it
> might have been named after Intel's Video BIOS because that was its
> first consumer. However the name is or has become unrelated to its func
tion.
> If somebody would come up with a name for the VBT, looking at what
> it is today, he might call it *Intel Graphics Driver Configuration Table*
> (IGDT). The acronym IGDT looks much different from VBE, no temptation
> to see them related. Also, why should GOP replace IGDT and reinvent how
> Intel develops its graphics drivers? GOP is just about pre-OS environ-
> ments (cross-vendor), while IGDT is common to all of Intel's graphics
drivers.

Nico/Matt,

You two (as a team) are the best candidates to make this Coreboot WiKi page.

It will have Thermonuclear Hit/Influence on the Open Net and Open Source. I
do agree on name:
*Intel Graphics Driver Configuration Table (IGDCT). Instead VBT!*

I'll tell to you: INTEL (devil) himself will consider to change VBT name to
what you have proposed. :-)

Does it sound reasonable?! ;-)

Thank you for understanding,
Zoran

On Wed, Apr 5, 2017 at 7:54 PM, Nico Huber  wrote:

> On 05.04.2017 17:03, Zoran Stojsavljevic 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.
>
> no, no, no, no. Since VBT is not related to the concept of a Video BIOS
> or any standard (how many people does it need to convince you? :-), it
> cannot be replaced by something (GOP) that continues this standards
> story.
>
> Maybe this helps you to untangle this: When the VBT was invented, it
> might have been named after Intel's Video BIOS because that was its
> first consumer. However the name is or has become unrelated to its func-
> tion. If somebody would come up with a name for the VBT, looking at what
> it is today, he might call it Intel Graphics Driver Configuration Table
> (IGDT). The acronym IGDT looks much different from VBE, no temptation
> to see them related. Also, why should GOP replace IGDT and reinvent how
> Intel develops its graphics drivers? GOP is just about pre-OS environ-
> ments (cross-vendor), while IGDT is common to all of Intel's graphics
> drivers.
>
> From another perspective: IGDT contains proprietary settings for Intel
> silicon, close to register level. VBE is, at its core, about high-level
> framebuffer (data in RAM) formats.
>
> Nico
>
> >
> > I'll continue to investigate.
> >
> > Thank you,
> > Zoran
> >
> > On Wed, Apr 5, 2017 at 4:54 PM, Matt DeVillier  >
> > wrote:
> >
> >> On Tue, Apr 4, 2017 at 10:12 PM, Zoran Stojsavljevic  >> 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
> 

Re: [coreboot] 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 <
coreboot@coreboot.org> 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> 

Re: [coreboot] VGA and Graphics

[Arthur Heymans]

Igor Skochinsky via coreboot  writes:

> Hello Patrick,
>
> Tuesday, April 4, 2017, 8:54:09 PM, you wrote:
>
> PR> VBT is documented by intel-gpu-tools. There's intel_vbt_decode
> PR> (former intel_bios_decode) available
> PR> 
> https://cgit.freedesktop.org/xorg/app/intel-gpu-tools/tree/tools/intel_vbt_decode.c
> PR> that will print all tables in human readable form.
>
> Nice find! I did not realize this tool supports that many structures;
> for some reason I thought it just prints some general info without details.
>
> So now that we have a dumper the following should be possible:
> 1) make a "decompiler" that would convert VBT from the option ROM into a 
> human/machine
> readable text format
> 2) make a "compiler" that would take that text format and create a
> binary VBT from it
> 3) put the binary VBT into the ACPI IGD OpRegion table ([1], [2]), or
> wherever the graphics driver can find it.
>

I think blobtool would fit that purpose quite nicely on the assumption
VBT is already extracted and that VBT has fixed locations for its
entries.  If one writes a blobtool spec file (which describes the
bitfields) it can serve both as a "decompiler" and as a "compiler".

>So, basically, an approach similar to ich9gen for the flash
>descriptor/gbe.

Blobtool handles ICH9 IFD and GBE compilation and decompilation too. ;)

>This should allow getting rid of the option ROM if real mode support is
>not required.

Would great to have indeed, who knows if other OS drivers will mandate
VBT one day.


Kind regards.
-- 
Arthur Heymans

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] VGA and Graphics

[Nico Huber]

On 05.04.2017 17:16, ron minnich wrote:
> Zoran, given that we still see _MP_ and even $PIR tables in BIOS, is it

These are obsoleted standards.

> possible that VBT might always be there even if it's not strictly needed?

This is a table used by only one vendor and nobody intended to replace
it so far.

> 
> How do non-EFI kernels get information about video if not via the VBT?

That's vendor specific. What information are you looking for?

Nico


-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] VGA and Graphics

[Igor Skochinsky via coreboot]

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.




-- 
WBR,
 Igormailto:skochin...@mail.ru


-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] VGA and Graphics

[Nico Huber]

On 05.04.2017 17:03, Zoran Stojsavljevic 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.

no, no, no, no. Since VBT is not related to the concept of a Video BIOS
or any standard (how many people does it need to convince you? :-), it
cannot be replaced by something (GOP) that continues this standards
story.

Maybe this helps you to untangle this: When the VBT was invented, it
might have been named after Intel's Video BIOS because that was its
first consumer. However the name is or has become unrelated to its func-
tion. If somebody would come up with a name for the VBT, looking at what
it is today, he might call it Intel Graphics Driver Configuration Table
(IGDT). The acronym IGDT looks much different from VBE, no temptation
to see them related. Also, why should GOP replace IGDT and reinvent how
Intel develops its graphics drivers? GOP is just about pre-OS environ-
ments (cross-vendor), while IGDT is common to all of Intel's graphics
drivers.

>From another perspective: IGDT contains proprietary settings for Intel
silicon, close to register level. VBE is, at its core, about high-level
framebuffer (data in RAM) formats.

Nico

> 
> I'll continue to investigate.
> 
> Thank you,
> Zoran
> 
> On Wed, Apr 5, 2017 at 4:54 PM, Matt DeVillier 
> wrote:
> 
>> On Tue, Apr 4, 2017 at 10:12 PM, Zoran Stojsavljevic > 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 >>


 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

Re: [coreboot] VGA and Graphics

[Igor Skochinsky via coreboot]

Hello Patrick,

Tuesday, April 4, 2017, 8:54:09 PM, you wrote:

PR> VBT is documented by intel-gpu-tools. There's intel_vbt_decode
PR> (former intel_bios_decode) available
PR> 
https://cgit.freedesktop.org/xorg/app/intel-gpu-tools/tree/tools/intel_vbt_decode.c
PR> that will print all tables in human readable form.

Nice find! I did not realize this tool supports that many structures;
for some reason I thought it just prints some general info without details.

So now that we have a dumper the following should be possible:
1) make a "decompiler" that would convert VBT from the option ROM into a 
human/machine
readable text format
2) make a "compiler" that would take that text format and create a
binary VBT from it
3) put the binary VBT into the ACPI IGD OpRegion table ([1], [2]), or
wherever the graphics driver can find it.

So, basically, an approach similar to ich9gen for the flash
descriptor/gbe.

This should allow getting rid of the option ROM if real mode support is
not required.

[1] 
https://01.org/sites/default/files/documentation/acpi_igd_opregion_spec_0.pdf
[2] https://lwn.net/Articles/429319/


PR> Am 4. April 2017 20:45:15 MESZ schrieb Nico Huber :
PR> Hi Ron,

PR> On 04.04.2017 19:46, ron minnich wrote:
PR>  Igor, if you are going to say things like "AFAIK there is no public
PR>  description of these tables' layout and contents, only Intel knows how to
PR>  build and parse them.", it's really a good idea to back it up with a
PR>  primary source, especially since you also use phrases like "I assume" and
PR>  "I guess". I am pretty sure you're wrong in this case. The V in VBT, as I
PR>  understand it, means VESA, and VESA has been a standard for about 30 years.
PR>  
PR>  Please, everyone, if you're going to move this conversation forward, you
PR>  need to cite primary sources at least, such as this one:
PR>  http://www.petesqbsite.com/sections/tutorials/tuts/vbe3.pdf.

PR> now you got confused too. I'll try to clarify.

PR> VBE means VESA (Video Electronics Standards Association) BIOS Extension.
PR> It's a Video BIOS interface extension (i.e. specifying additional BIOS
PR> calls). Don't know if it was public from the beginning (you often have
PR> to be a VESA member to get access to their "standards"), but the inter-
PR> face is used by many open source programs. It's vendor independent. Also
PR> it's off-topic, nobody was discussing it here.

PR> As Igor noted, VBE has absolutely nothing to do with VBT.

PR> VBT means Video BIOS Table. It's a 100% Intel specific table of confi-
PR> guration options for Intel's Video BIOS and Intel's graphics drivers.
PR> There is no public documentation, but as it's used by the Linux driver,
PR> at least the structure and some of the values are publicly "documented"
PR> [1]. Developers of the i915 Linux driver stated that they are not wil-
PR> ling to support systems without a VBT. Most features of the i915 driver
PR> work without a VBT by chance. But anything board specific, like inte-
PR> grated panels in laptops, will likely _not_ work. I'd also expect that
PR> they won't count it as a regression if something breaks but would still
PR> work with a VBT. (Windows won't even try to get things running without
PR> VBT, AFAIK.)

PR> An OEM should have access to Intel's binary configuration tool and the
PR> specification file for the VBT of his processor's generation. It comes
PR> along with the VBIOS, I suppose.

PR> Nico

PR> PS. Igor, Zoran please write text-only emails or at least make sure the
PR> text version is readable and quotes are visible as quotes.

PR> [1]
PR> https://www.kernel.org/doc/html/latest/gpu/i915.html#video-bios-table-vbt



-- 
WBR,
 Igor


-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] VGA and Graphics

[Igor Skochinsky via coreboot]

Hello ron,

Wednesday, April 5, 2017, 5:16:33 PM, you wrote:

rm> Zoran, given that we still see _MP_ and even $PIR tables in BIOS,
rm> is it possible that VBT might always be there even if it's not strictly 
needed?

rm> How do non-EFI kernels get information about video if not via the VBT?

int 10h would be my guess, or possibly that PMInfoBlock VBE3 table. Or
maybe they just load whatever driver matches the PCI ID and let it
handle the details.

rm> On Wed, Apr 5, 2017 at 8:03 AM Zoran Stojsavljevic
rm>  wrote:
rm> To Coreboot,

rm> http://www.uefi.org/sites/default/files/resources/UPFS11_P4_UEFI_GOP_AMD.pdf

rm> Please, read about GOP, and what GOP suppose to be.

rm> So, GOP actually need to replace vBIOS, VBT, legacy INT 10H, and
rm> complete VBE 3.0 standard. Why (I have no idea what INTEL does
rm> with GOP and how it implements it) it is not done in this
rm> fashion...?! At least this is my impression how this should be done.

rm> I'll continue to investigate.

rm> Thank you,
rm> Zoran

rm> On Wed, Apr 5, 2017 at 4:54 PM, Matt DeVillier
rm>  wrote:
rm> On Tue, Apr 4, 2017 at 10:12 PM, Zoran Stojsavljevic
rm>  wrote:
rm> Hello Matt,

rm> Pretty sure there is NO Option ROM, vBIOS and INT10H. Why INTEL
rm> for GOP uses VBT is point of debate. Probably just reduced
rm> functionality up to 1280x1024. So they have VBT to support BIOS phase GOP 
GFX. Only!

rm> From what I can tell, it's mainly used to provide the output
rm> connector types/mapping to the GOP driver, as well as level shifting etc.
rm>  

rm> But I am also 100% sure neither GOP, neither VBT survives post
rm> BIOS phase. It is out of mind to use VBT for WUXGA, or 1080p, or
rm> 4K displays, don't you agree? The detected GFX I/F are passed to
rm> Linux as Run Time info (via HOB). Then Linux brings from scratch
rm> GFX, using its own, modern I/Fs. And ports appropriate drivers to existing 
GFX info from HOB.

rm> The VBT data is used by both the Linux and Windows display
rm> drivers (via the OpRegion ACPI structure), and the latter will
rm> give you a nice black screen if your VBT is missing or incorrectly
rm> configured.  As I noted above, it appears to be used more for
rm> output/pipe info than display modes (which are all generated from
rm> EDID, outside of standard VESA/CEA ones)

rm> On Tue, Apr 4, 2017 at 10:12 PM, Zoran Stojsavljevic
rm>  wrote:
rm> Hello Matt,

rm> Pretty sure there is NO Option ROM, vBIOS and INT10H. Why INTEL
rm> for GOP uses VBT is point of debate. Probably just reduced
rm> functionality up to 1280x1024. So they have VBT to support BIOS phase GOP 
GFX. Only!

rm> But I am also 100% sure neither GOP, neither VBT survives post
rm> BIOS phase. It is out of mind to use VBT for WUXGA, or 1080p, or
rm> 4K displays, don't you agree? The detected GFX I/F are passed to
rm> Linux as Run Time info (via HOB). Then Linux brings from scratch
rm> GFX, using its own, modern I/Fs. And ports appropriate drivers to existing 
GFX info from HOB.

rm> Zoran

rm> On Tue, Apr 4, 2017 at 11:51 PM, Matt DeVillier
rm>  wrote:


rm> On Tue, Apr 4, 2017 at 2:23 PM, Zoran Stojsavljevic
rm>  wrote:
rm> Furthermore, let me tell you all that this is a mechanism to
rm> support ONLY The Legacy BIOS (UEFI works ONLY with GOP, but this
rm> is another dimension/discussion), and, to all of your knowledge
rm> (which I have no idea how deep it is, I doubt), VBT table survives
rm> postmortem BIOS. By Linux, it will be RELOCATED into much higher
rm> (over 1MB) 32bit protected mode memory (addresses recalculated),
rm> and still use INT10H, using vBIOS (Option ROM, my best guess) down there.


rm> no, the UEFI GOP driver needs the VBT to actually do anything. 
rm> Look at any current PC UEFI firmware, or even x86 ChromeOS
rm> firmware, and you'll see they all use/contain a VBT still.






-- 
WBR,
 Igor


-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [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.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 
> 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 
> 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

Re: [coreboot] VGA and Graphics

[Zoran Stojsavljevic]

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 
wrote:

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

Re: [coreboot] VGA and Graphics

[Matt DeVillier]

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 
> 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

Re: [coreboot] VGA and Graphics

[Zoran Stojsavljevic]

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 
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

Re: [coreboot] VGA and Graphics

[Matt DeVillier]

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

Re: [coreboot] VGA and Graphics

[ron minnich]

These are great corrections! Thanks everyone, sorry for my confusion.

The information I'm seeing here is really useful, would somebody consider
putting it on the wiki? Among other things, it would reduce my own levels
of confusion.

ron

On Tue, Apr 4, 2017 at 12:23 PM Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

> Wait a moment, Ron... :-)
>
> Igor is in some points correct. But I need to digest document, you've
> attached, much more in details. I recall some interesting things, reading
> this document, while reading some (jumping around) context.
>
> Very interesting discussion it is, although BIOS is associated with vBIOS
> and VBT in Option ROMs. I need to digest more about these data, you have
> presented, Ron.
>
> VBT stands for Video BIOS Table, VBE is VESA BIOS Extension. I am very
> sure these two things have very much to do with each other, since I can
> imagine that modes (described in VBE 3.0, are supported exactly by VBT,
> which needs to translate VBE modes to some Video timings, and video HSync,
> VSync, Back Porch, Front Porch, blanking dot and line intervals... Low
> Level GFX, which is not too much known to vast majority of the people.
>
> I would like all to look into the document
> http://www.petesqbsite.com/sections/tutorials/tuts/vbe3.pdf, page 19.
> These are the modes VBE 3.0 supports.
>
> 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.
>
> I would not draw so fast... As many of you do! ;-)
>
> Thank you,
> Zoran
>
> On Tue, Apr 4, 2017 at 7:46 PM, ron minnich  wrote:
>
> Igor, if you are going to say things like "AFAIK there is no public
> description of these tables' layout and contents, only Intel knows how to
> build and parse them.", it's really a good idea to back it up with a
> primary source, especially since you also use phrases like "I assume" and
> "I guess". I am pretty sure you're wrong in this case. The V in VBT, as I
> understand it, means VESA, and VESA has been a standard for about 30 years.
>
> Please, everyone, if you're going to move this conversation forward, you
> need to cite primary sources at least, such as this one:
> http://www.petesqbsite.com/sections/tutorials/tuts/vbe3.pdf.
>
>
> thanks
>
> ron
>
> On Tue, Apr 4, 2017 at 10:19 AM Igor Skochinsky via coreboot <
> coreboot@coreboot.org> wrote:
>
> Hello Zoran,
>
>
> Monday, April 3, 2017, 8:58:43 PM, you wrote:
>
>
>
> VBT should fulfill this VBE standard, as my best understanding is, or not?!
>
> VBE only describes the int 10h BIOS interface extensions, VBT are tables
> used by Intel to provide info about how to control the GPU (I assume).
> AFAIK there is no public description of these tables' layout and contents,
> only Intel knows how to build and parse them.
> Both VBE(code) and VBT (data) may be present in the video card's option
> ROM, I guess that's the only common part.
>
>
>
>
> Zoran
>
> On Mon, Apr 3, 2017 at 7:36 PM, Igor Skochinsky via coreboot <
> coreboot@coreboot.org> wrote:
> Hello Zoran,
>
> Monday, April 3, 2017, 9:24:41 AM, you wrote:
>
>
> > *VBT is not code, it's a table* -- that's what the T is -- and you can
> create it any way you want.
>
> Not going to say more, anyway. Just to point to the standard:
> https://en.wikipedia.org/wiki/
> VESA_BIOS_Extensions
> 
>
>
> Not sure why you posted this link. VBE is not VBT, it's a completely
> separate and different thing.
>
>
>
>
>
> To clever enough! ;-)
>
> Zoran
>
> On Mon, Apr 3, 2017 at 2:38 AM, ron minnich  wrote:
> As for graphics startup, here's what I learned when I was doing this in
> 2012/2013: the kernel could start sandy and ivy with no vbios needed.
> However, I have been told that the veil of secrecy has started to draw a
> bit closer in subsequent chipsets, and that something like a VGA BIOS/GOP
> has to run or graphics will not work. I really don't know, I have not
> looked at this in over 3 years.
>
> Todd, just to make sure we're on the same page, VBT is not code, it's a
> table -- that's what the T is -- and you can create it any way you want.
>
> Also, as for numbers: the fastest graphics startup, by far, was when we
> had coreboot- based startup with configuration specialized to the chromeos
> laptop. How fast? At one point we had a pixel booting to chromeos prompt in
> 2.7 seconds, reduced from 7.7 seconds when linux did the graphics init.
> We've seen that the linux graphics init is highly concurrent and
> generalized, and that tends to 

Re: [coreboot] VGA and Graphics

[Zoran Stojsavljevic]

Wait a moment, Ron... :-)

Igor is in some points correct. But I need to digest document, you've
attached, much more in details. I recall some interesting things, reading
this document, while reading some (jumping around) context.

Very interesting discussion it is, although BIOS is associated with vBIOS
and VBT in Option ROMs. I need to digest more about these data, you have
presented, Ron.

VBT stands for Video BIOS Table, VBE is VESA BIOS Extension. I am very sure
these two things have very much to do with each other, since I can imagine
that modes (described in VBE 3.0, are supported exactly by VBT, which needs
to translate VBE modes to some Video timings, and video HSync, VSync, Back
Porch, Front Porch, blanking dot and line intervals... Low Level GFX, which
is not too much known to vast majority of the people.

I would like all to look into the document
http://www.petesqbsite.com/sections/tutorials/tuts/vbe3.pdf, page 19. These
are the modes VBE 3.0 supports.

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.

I would not draw so fast... As many of you do! ;-)

Thank you,
Zoran

On Tue, Apr 4, 2017 at 7:46 PM, ron minnich  wrote:

> Igor, if you are going to say things like "AFAIK there is no public
> description of these tables' layout and contents, only Intel knows how to
> build and parse them.", it's really a good idea to back it up with a
> primary source, especially since you also use phrases like "I assume" and
> "I guess". I am pretty sure you're wrong in this case. The V in VBT, as I
> understand it, means VESA, and VESA has been a standard for about 30 years.
>
> Please, everyone, if you're going to move this conversation forward, you
> need to cite primary sources at least, such as this one:
> http://www.petesqbsite.com/sections/tutorials/tuts/vbe3.pdf.
>
>
> thanks
>
> ron
>
> On Tue, Apr 4, 2017 at 10:19 AM Igor Skochinsky via coreboot <
> coreboot@coreboot.org> wrote:
>
>> Hello Zoran,
>>
>>
>> Monday, April 3, 2017, 8:58:43 PM, you wrote:
>>
>>
>>
>> VBT should fulfill this VBE standard, as my best understanding is, or
>> not?!
>>
>> VBE only describes the int 10h BIOS interface extensions, VBT are tables
>> used by Intel to provide info about how to control the GPU (I assume).
>> AFAIK there is no public description of these tables' layout and contents,
>> only Intel knows how to build and parse them.
>> Both VBE(code) and VBT (data) may be present in the video card's option
>> ROM, I guess that's the only common part.
>>
>>
>>
>>
>> Zoran
>>
>> On Mon, Apr 3, 2017 at 7:36 PM, Igor Skochinsky via coreboot <
>> coreboot@coreboot.org> wrote:
>> Hello Zoran,
>>
>> Monday, April 3, 2017, 9:24:41 AM, you wrote:
>>
>>
>> > *VBT is not code, it's a table* -- that's what the T is -- and you can
>> create it any way you want.
>>
>> Not going to say more, anyway. Just to point to the standard:
>> https://en.wikipedia.org/wiki/
>> VESA_BIOS_Extensions
>> 
>>
>>
>> Not sure why you posted this link. VBE is not VBT, it's a completely
>> separate and different thing.
>>
>>
>>
>>
>>
>> To clever enough! ;-)
>>
>> Zoran
>>
>> On Mon, Apr 3, 2017 at 2:38 AM, ron minnich  wrote:
>> As for graphics startup, here's what I learned when I was doing this in
>> 2012/2013: the kernel could start sandy and ivy with no vbios needed.
>> However, I have been told that the veil of secrecy has started to draw a
>> bit closer in subsequent chipsets, and that something like a VGA BIOS/GOP
>> has to run or graphics will not work. I really don't know, I have not
>> looked at this in over 3 years.
>>
>> Todd, just to make sure we're on the same page, VBT is not code, it's a
>> table -- that's what the T is -- and you can create it any way you want.
>>
>> Also, as for numbers: the fastest graphics startup, by far, was when we
>> had coreboot- based startup with configuration specialized to the chromeos
>> laptop. How fast? At one point we had a pixel booting to chromeos prompt in
>> 2.7 seconds, reduced from 7.7 seconds when linux did the graphics init.
>> We've seen that the linux graphics init is highly concurrent and
>> generalized, and that tends to mean slow. Of course this was all far faster
>> than the 8086-mode vga BIOS supplied by "the vendor". But we were a bit
>> surprised to see how much faster coreboot was than the linux kernel.
>>
>> I doubt this speed difference matters any more, since boot time only
>> needs to be "fast enough" nowadays and 10 seconds seems to 

Re: [coreboot] VGA and Graphics

[Patrick Rudolph]

VBT is documented by intel-gpu-tools. There's intel_vbt_decode (former 
intel_bios_decode) available 
https://cgit.freedesktop.org/xorg/app/intel-gpu-tools/tree/tools/intel_vbt_decode.c
 that will print all tables in human readable form.
Regards Patrick

Am 4. April 2017 20:45:15 MESZ schrieb Nico Huber :
>Hi Ron,
>
>On 04.04.2017 19:46, ron minnich wrote:
>> Igor, if you are going to say things like "AFAIK there is no public
>> description of these tables' layout and contents, only Intel knows
>how to
>> build and parse them.", it's really a good idea to back it up with a
>> primary source, especially since you also use phrases like "I assume"
>and
>> "I guess". I am pretty sure you're wrong in this case. The V in VBT,
>as I
>> understand it, means VESA, and VESA has been a standard for about 30
>years.
>> 
>> Please, everyone, if you're going to move this conversation forward,
>you
>> need to cite primary sources at least, such as this one:
>> http://www.petesqbsite.com/sections/tutorials/tuts/vbe3.pdf.
>
>now you got confused too. I'll try to clarify.
>
>VBE means VESA (Video Electronics Standards Association) BIOS
>Extension.
>It's a Video BIOS interface extension (i.e. specifying additional BIOS
>calls). Don't know if it was public from the beginning (you often have
>to be a VESA member to get access to their "standards"), but the inter-
>face is used by many open source programs. It's vendor independent.
>Also
>it's off-topic, nobody was discussing it here.
>
>As Igor noted, VBE has absolutely nothing to do with VBT.
>
>VBT means Video BIOS Table. It's a 100% Intel specific table of confi-
>guration options for Intel's Video BIOS and Intel's graphics drivers.
>There is no public documentation, but as it's used by the Linux driver,
>at least the structure and some of the values are publicly "documented"
>[1]. Developers of the i915 Linux driver stated that they are not wil-
>ling to support systems without a VBT. Most features of the i915 driver
>work without a VBT by chance. But anything board specific, like inte-
>grated panels in laptops, will likely _not_ work. I'd also expect that
>they won't count it as a regression if something breaks but would still
>work with a VBT. (Windows won't even try to get things running without
>VBT, AFAIK.)
>
>An OEM should have access to Intel's binary configuration tool and the
>specification file for the VBT of his processor's generation. It comes
>along with the VBIOS, I suppose.
>
>Nico
>
>PS. Igor, Zoran please write text-only emails or at least make sure the
>text version is readable and quotes are visible as quotes.
>
>[1]
>https://www.kernel.org/doc/html/latest/gpu/i915.html#video-bios-table-vbt
>
>-- 
>coreboot mailing list: coreboot@coreboot.org
>https://www.coreboot.org/mailman/listinfo/coreboot
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] VGA and Graphics

[Nico Huber]

Hi Ron,

On 04.04.2017 19:46, ron minnich wrote:
> Igor, if you are going to say things like "AFAIK there is no public
> description of these tables' layout and contents, only Intel knows how to
> build and parse them.", it's really a good idea to back it up with a
> primary source, especially since you also use phrases like "I assume" and
> "I guess". I am pretty sure you're wrong in this case. The V in VBT, as I
> understand it, means VESA, and VESA has been a standard for about 30 years.
> 
> Please, everyone, if you're going to move this conversation forward, you
> need to cite primary sources at least, such as this one:
> http://www.petesqbsite.com/sections/tutorials/tuts/vbe3.pdf.

now you got confused too. I'll try to clarify.

VBE means VESA (Video Electronics Standards Association) BIOS Extension.
It's a Video BIOS interface extension (i.e. specifying additional BIOS
calls). Don't know if it was public from the beginning (you often have
to be a VESA member to get access to their "standards"), but the inter-
face is used by many open source programs. It's vendor independent. Also
it's off-topic, nobody was discussing it here.

As Igor noted, VBE has absolutely nothing to do with VBT.

VBT means Video BIOS Table. It's a 100% Intel specific table of confi-
guration options for Intel's Video BIOS and Intel's graphics drivers.
There is no public documentation, but as it's used by the Linux driver,
at least the structure and some of the values are publicly "documented"
[1]. Developers of the i915 Linux driver stated that they are not wil-
ling to support systems without a VBT. Most features of the i915 driver
work without a VBT by chance. But anything board specific, like inte-
grated panels in laptops, will likely _not_ work. I'd also expect that
they won't count it as a regression if something breaks but would still
work with a VBT. (Windows won't even try to get things running without
VBT, AFAIK.)

An OEM should have access to Intel's binary configuration tool and the
specification file for the VBT of his processor's generation. It comes
along with the VBIOS, I suppose.

Nico

PS. Igor, Zoran please write text-only emails or at least make sure the
text version is readable and quotes are visible as quotes.

[1]
https://www.kernel.org/doc/html/latest/gpu/i915.html#video-bios-table-vbt

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] VGA and Graphics

[Igor Skochinsky via coreboot]

Hello ron,

Tuesday, April 4, 2017, 7:46:12 PM, you wrote:



Igor, if you are going to say things like "AFAIK there is no public description 
of these tables' layout and contents, only Intel knows how to build and parse 
them.", it's really a good idea to back it up with a primary source, especially 
since you also use phrases like "I assume" and "I guess". I am pretty sure 
you're wrong in this case. The V in VBT, as I understand it, means VESA, and 
VESA has been a standard for about 30 years. 



Please, everyone, if you're going to move this conversation forward, you need 
to cite primary sources at least, such as this one: 
http://www.petesqbsite.com/sections/tutorials/tuts/vbe3.pdf. 


Thanks Ron and sorry for not providing any sources. However, VBT actually 
stands for "*Video* (not VESA) BIOS Table" , as mentioned e.g. in [2]:
"The Video BIOS Table (VBT) is a block of customizable platform-specific data 
used by the Video BIOS and device drivers such as Flat Panel Timings, OEM 
definable Mode Timing, GPIO pins, Clock, and more.". 

VESA (formerly Video Electronics Standards Association) is not a standard but 
an organization; they do make standards however, such as the above-mentioned 
VBE but also DDC, EDID, DisplayPort and others [4]. As far as I can tell, VBE 
has no relation to VBT (at least I could not find any mention of VBT in that 
VBE PDF).

And apparently I was wrong and there *is* some (high-level) description of 
what's in those tables. E.g. from [1] and [3]

"The VBT consists of a VBT Header (defined as struct vbt_header), a BDB Header 
(struct bdb_header), and a number of BIOS Data Blocks (BDB) that contain the 
actual configuration information. The VBT Header, and thus the VBT, begins with 
“$VBT” signature. The VBT Header contains the offset of the BDB Header. The 
data blocks are concatenated after the BDB Header. The data blocks have a 
1-byte Block ID, 2-byte Block Size, and Block Size bytes of data. (Block 53, 
the MIPI Sequence Block is an exception.)"

However I was not able to find a full list and exact layout of those blocks. 
Possibly some could be recovered from the i915 (and others) Intel driver 
sources (maybe enough to support Linux).

[1]  (Intel) Linux GPU Driver Developer’s Guide » drm/i915 Intel GFX Driver - 
https://01.org/linuxgraphics/gfx-docs/drm/gpu/i915.html
[2] Intel® Embedded Media and Graphics Driver User Guide - 
http://www.intel.com/content/dam/support/us/en/documents/boardsandkits/gfx_37.15.0.1073_usersguide.pdf
[3] Display Hardware Handling. Chapter 4 drm/i915 Intel GFX Driver 
https://01.org/linuxgraphics/gfx-docs/drm/ch04s02.html
[4] https://en.wikipedia.org/wiki/Video_Electronics_Standards_Association





thanks

ron

On Tue, Apr 4, 2017 at 10:19 AM Igor Skochinsky via coreboot 
 wrote:
Hello Zoran,


Monday, April 3, 2017, 8:58:43 PM, you wrote:



VBT should fulfill this VBE standard, as my best understanding is, or not?!



VBE only describes the int 10h BIOS interface extensions, VBT are tables used 
by Intel to provide info about how to control the GPU (I assume). AFAIK there 
is no public description of these tables' layout and contents, only Intel knows 
how to build and parse them.
Both VBE(code) and VBT (data) may be present in the video card's option ROM, I 
guess that's the only common part.




Zoran

On Mon, Apr 3, 2017 at 7:36 PM, Igor Skochinsky via coreboot 
 wrote:
Hello Zoran,

Monday, April 3, 2017, 9:24:41 AM, you wrote:


> VBT is not code, it's a table -- that's what the T is -- and you can create 
> it any way you want.

Not going to say more, anyway. Just to point to the standard:
https://en.wikipedia.org/wiki/VESA_BIOS_Extensions




Not sure why you posted this link. VBE is not VBT, it's a completely separate 
and different thing.





To clever enough! ;-)

Zoran

On Mon, Apr 3, 2017 at 2:38 AM, ron minnich  wrote:
As for graphics startup, here's what I learned when I was doing this in 
2012/2013: the kernel could start sandy and ivy with no vbios needed. However, 
I have been told that the veil of secrecy has started to draw a bit closer in 
subsequent chipsets, and that something like a VGA BIOS/GOP has to run or 
graphics will not work. I really don't know, I have not looked at this in over 
3 years.

Todd, just to make sure we're on the same page, VBT is not code, it's a table 
-- that's what the T is -- and you can create it any way you want. 

Also, as for numbers: the fastest graphics startup, by far, was when we had 
coreboot- based startup with configuration specialized to the chromeos laptop. 
How fast? At one point we had a pixel booting to chromeos prompt in 2.7 
seconds, reduced from 7.7 seconds when linux did the graphics init. We've seen 
that the linux graphics init is highly concurrent and generalized, and that 
tends to mean slow. Of course this was all far faster than the 8086-mode vga 
BIOS supplied by "the vendor". But we were a bit 

Re: [coreboot] VGA and Graphics

[ron minnich]

Igor, if you are going to say things like "AFAIK there is no public
description of these tables' layout and contents, only Intel knows how to
build and parse them.", it's really a good idea to back it up with a
primary source, especially since you also use phrases like "I assume" and
"I guess". I am pretty sure you're wrong in this case. The V in VBT, as I
understand it, means VESA, and VESA has been a standard for about 30 years.

Please, everyone, if you're going to move this conversation forward, you
need to cite primary sources at least, such as this one:
http://www.petesqbsite.com/sections/tutorials/tuts/vbe3.pdf.


thanks

ron

On Tue, Apr 4, 2017 at 10:19 AM Igor Skochinsky via coreboot <
coreboot@coreboot.org> wrote:

> Hello Zoran,
>
>
> Monday, April 3, 2017, 8:58:43 PM, you wrote:
>
>
>
> VBT should fulfill this VBE standard, as my best understanding is, or not?!
>
> VBE only describes the int 10h BIOS interface extensions, VBT are tables
> used by Intel to provide info about how to control the GPU (I assume).
> AFAIK there is no public description of these tables' layout and contents,
> only Intel knows how to build and parse them.
> Both VBE(code) and VBT (data) may be present in the video card's option
> ROM, I guess that's the only common part.
>
>
>
>
> Zoran
>
> On Mon, Apr 3, 2017 at 7:36 PM, Igor Skochinsky via coreboot <
> coreboot@coreboot.org> wrote:
> Hello Zoran,
>
> Monday, April 3, 2017, 9:24:41 AM, you wrote:
>
>
> > *VBT is not code, it's a table* -- that's what the T is -- and you can
> create it any way you want.
>
> Not going to say more, anyway. Just to point to the standard:
> https://en.wikipedia.org/wiki/
> VESA_BIOS_Extensions
> 
>
>
> Not sure why you posted this link. VBE is not VBT, it's a completely
> separate and different thing.
>
>
>
>
>
> To clever enough! ;-)
>
> Zoran
>
> On Mon, Apr 3, 2017 at 2:38 AM, ron minnich  wrote:
> As for graphics startup, here's what I learned when I was doing this in
> 2012/2013: the kernel could start sandy and ivy with no vbios needed.
> However, I have been told that the veil of secrecy has started to draw a
> bit closer in subsequent chipsets, and that something like a VGA BIOS/GOP
> has to run or graphics will not work. I really don't know, I have not
> looked at this in over 3 years.
>
> Todd, just to make sure we're on the same page, VBT is not code, it's a
> table -- that's what the T is -- and you can create it any way you want.
>
> Also, as for numbers: the fastest graphics startup, by far, was when we
> had coreboot- based startup with configuration specialized to the chromeos
> laptop. How fast? At one point we had a pixel booting to chromeos prompt in
> 2.7 seconds, reduced from 7.7 seconds when linux did the graphics init.
> We've seen that the linux graphics init is highly concurrent and
> generalized, and that tends to mean slow. Of course this was all far faster
> than the 8086-mode vga BIOS supplied by "the vendor". But we were a bit
> surprised to see how much faster coreboot was than the linux kernel.
>
> I doubt this speed difference matters any more, since boot time only needs
> to be "fast enough" nowadays and 10 seconds seems to do it for most people
> -- plus, any 5-second advantage in boot time vanishes as soon as you go to
> your first web page.
>
> ron
>
>
>
> On Sun, Apr 2, 2017 at 5:31 PM ron minnich  wrote:
> So, I'll mention go userland one last time, for a simple reason: I have it
> on good authority that at some places, saying you have a go userland
> instead of a c userland checks a check box on a security checklist. I think
> that's a sensible decision, having watched all the awful ways that C
> programs tend to go wrong :-)
>
> ron
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailm
> an/listinfo/coreboot
> 
>
>
>
>
>
>
>
>
> *--  WBR,  Igor *--
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/
> 
> mailman/listinfo/coreboot
> 
>
>
>
>
>
> *--  WBR,  Igor*
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] VGA and Graphics

[Igor Skochinsky via coreboot]

Hello Zoran,

Monday, April 3, 2017, 8:58:43 PM, you wrote:



VBT should fulfill this VBE standard, as my best understanding is, or not?!


VBE only describes the int 10h BIOS interface extensions, VBT are tables used 
by Intel to provide info about how to control the GPU (I assume). AFAIK there 
is no public description of these tables' layout and contents, only Intel knows 
how to build and parse them.
Both VBE(code) and VBT (data) may be present in the video card's option ROM, I 
guess that's the only common part.



Zoran

On Mon, Apr 3, 2017 at 7:36 PM, Igor Skochinsky via coreboot 
 wrote:
Hello Zoran,

Monday, April 3, 2017, 9:24:41 AM, you wrote:


> VBT is not code, it's a table -- that's what the T is -- and you can create 
> it any way you want.

Not going to say more, anyway. Just to point to the standard:
https://en.wikipedia.org/wiki/VESA_BIOS_Extensions



Not sure why you posted this link. VBE is not VBT, it's a completely separate 
and different thing.




To clever enough! ;-)

Zoran

On Mon, Apr 3, 2017 at 2:38 AM, ron minnich  wrote:
As for graphics startup, here's what I learned when I was doing this in 
2012/2013: the kernel could start sandy and ivy with no vbios needed. However, 
I have been told that the veil of secrecy has started to draw a bit closer in 
subsequent chipsets, and that something like a VGA BIOS/GOP has to run or 
graphics will not work. I really don't know, I have not looked at this in over 
3 years.

Todd, just to make sure we're on the same page, VBT is not code, it's a table 
-- that's what the T is -- and you can create it any way you want. 

Also, as for numbers: the fastest graphics startup, by far, was when we had 
coreboot- based startup with configuration specialized to the chromeos laptop. 
How fast? At one point we had a pixel booting to chromeos prompt in 2.7 
seconds, reduced from 7.7 seconds when linux did the graphics init. We've seen 
that the linux graphics init is highly concurrent and generalized, and that 
tends to mean slow. Of course this was all far faster than the 8086-mode vga 
BIOS supplied by "the vendor". But we were a bit surprised to see how much 
faster coreboot was than the linux kernel. 

I doubt this speed difference matters any more, since boot time only needs to 
be "fast enough" nowadays and 10 seconds seems to do it for most people -- 
plus, any 5-second advantage in boot time vanishes as soon as you go to your 
first web page.

ron



On Sun, Apr 2, 2017 at 5:31 PM ron minnich  wrote:
So, I'll mention go userland one last time, for a simple reason: I have it on 
good authority that at some places, saying you have a go userland instead of a 
c userland checks a check box on a security checklist. I think that's a 
sensible decision, having watched all the awful ways that C programs tend to go 
wrong :-)

ron

--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot





-- 
WBR,
 Igor

--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot




-- 
WBR,
 Igor-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] VGA and Graphics

[Zoran Stojsavljevic]

VBT should fulfill this VBE standard, as my best understanding is, or not?!

Zoran

On Mon, Apr 3, 2017 at 7:36 PM, Igor Skochinsky via coreboot <
coreboot@coreboot.org> wrote:

> Hello Zoran,
>
> Monday, April 3, 2017, 9:24:41 AM, you wrote:
>
>
> > *VBT is not code, it's a table* -- that's what the T is -- and you can
> create it any way you want.
>
> Not going to say more, anyway. Just to point to the standard:
> https://en.wikipedia.org/wiki/VESA_BIOS_Extensions
>
> Not sure why you posted this link. VBE is not VBT, it's a completely
> separate and different thing.
>
>
>
>
> To clever enough! ;-)
>
> Zoran
>
> On Mon, Apr 3, 2017 at 2:38 AM, ron minnich  wrote:
> As for graphics startup, here's what I learned when I was doing this in
> 2012/2013: the kernel could start sandy and ivy with no vbios needed.
> However, I have been told that the veil of secrecy has started to draw a
> bit closer in subsequent chipsets, and that something like a VGA BIOS/GOP
> has to run or graphics will not work. I really don't know, I have not
> looked at this in over 3 years.
>
> Todd, just to make sure we're on the same page, VBT is not code, it's a
> table -- that's what the T is -- and you can create it any way you want.
>
> Also, as for numbers: the fastest graphics startup, by far, was when we
> had coreboot- based startup with configuration specialized to the chromeos
> laptop. How fast? At one point we had a pixel booting to chromeos prompt in
> 2.7 seconds, reduced from 7.7 seconds when linux did the graphics init.
> We've seen that the linux graphics init is highly concurrent and
> generalized, and that tends to mean slow. Of course this was all far faster
> than the 8086-mode vga BIOS supplied by "the vendor". But we were a bit
> surprised to see how much faster coreboot was than the linux kernel.
>
> I doubt this speed difference matters any more, since boot time only needs
> to be "fast enough" nowadays and 10 seconds seems to do it for most people
> -- plus, any 5-second advantage in boot time vanishes as soon as you go to
> your first web page.
>
> ron
>
>
>
> On Sun, Apr 2, 2017 at 5:31 PM ron minnich  wrote:
> So, I'll mention go userland one last time, for a simple reason: I have it
> on good authority that at some places, saying you have a go userland
> instead of a c userland checks a check box on a security checklist. I think
> that's a sensible decision, having watched all the awful ways that C
> programs tend to go wrong :-)
>
> ron
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/
> mailm
> an/listinfo/coreboot 
>
>
>
>
>
> *--  WBR,  Igor*
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] VGA and Graphics

[Igor Skochinsky via coreboot]

Hello Zoran,

Monday, April 3, 2017, 9:24:41 AM, you wrote:


> VBT is not code, it's a table -- that's what the T is -- and you can create 
> it any way you want.

Not going to say more, anyway. Just to point to the standard:
https://en.wikipedia.org/wiki/VESA_BIOS_Extensions


Not sure why you posted this link. VBE is not VBT, it's a completely separate 
and different thing.



To clever enough! ;-)

Zoran

On Mon, Apr 3, 2017 at 2:38 AM, ron minnich  wrote:
As for graphics startup, here's what I learned when I was doing this in 
2012/2013: the kernel could start sandy and ivy with no vbios needed. However, 
I have been told that the veil of secrecy has started to draw a bit closer in 
subsequent chipsets, and that something like a VGA BIOS/GOP has to run or 
graphics will not work. I really don't know, I have not looked at this in over 
3 years.

Todd, just to make sure we're on the same page, VBT is not code, it's a table 
-- that's what the T is -- and you can create it any way you want. 

Also, as for numbers: the fastest graphics startup, by far, was when we had 
coreboot- based startup with configuration specialized to the chromeos laptop. 
How fast? At one point we had a pixel booting to chromeos prompt in 2.7 
seconds, reduced from 7.7 seconds when linux did the graphics init. We've seen 
that the linux graphics init is highly concurrent and generalized, and that 
tends to mean slow. Of course this was all far faster than the 8086-mode vga 
BIOS supplied by "the vendor". But we were a bit surprised to see how much 
faster coreboot was than the linux kernel. 

I doubt this speed difference matters any more, since boot time only needs to 
be "fast enough" nowadays and 10 seconds seems to do it for most people -- 
plus, any 5-second advantage in boot time vanishes as soon as you go to your 
first web page.

ron



On Sun, Apr 2, 2017 at 5:31 PM ron minnich  wrote:
So, I'll mention go userland one last time, for a simple reason: I have it on 
good authority that at some places, saying you have a go userland instead of a 
c userland checks a check box on a security checklist. I think that's a 
sensible decision, having watched all the awful ways that C programs tend to go 
wrong :-)

ron

--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot




-- 
WBR,
 Igor-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] VGA and Graphics

[Zoran Stojsavljevic]

> *VBT is not code, it's a table* -- that's what the T is -- and you can
create it any way you want.

Not going to say more, anyway. Just to point to the standard:
https://en.wikipedia.org/wiki/VESA_BIOS_Extensions

To clever enough! ;-)

Zoran

On Mon, Apr 3, 2017 at 2:38 AM, ron minnich  wrote:

> As for graphics startup, here's what I learned when I was doing this in
> 2012/2013: the kernel could start sandy and ivy with no vbios needed.
> However, I have been told that the veil of secrecy has started to draw a
> bit closer in subsequent chipsets, and that something like a VGA BIOS/GOP
> has to run or graphics will not work. I really don't know, I have not
> looked at this in over 3 years.
>
> Todd, just to make sure we're on the same page, VBT is not code, it's a
> table -- that's what the T is -- and you can create it any way you want.
>
> Also, as for numbers: the fastest graphics startup, by far, was when we
> had coreboot- based startup with configuration specialized to the chromeos
> laptop. How fast? At one point we had a pixel booting to chromeos prompt in
> 2.7 seconds, reduced from 7.7 seconds when linux did the graphics init.
> We've seen that the linux graphics init is highly concurrent and
> generalized, and that tends to mean slow. Of course this was all far faster
> than the 8086-mode vga BIOS supplied by "the vendor". But we were a bit
> surprised to see how much faster coreboot was than the linux kernel.
>
> I doubt this speed difference matters any more, since boot time only needs
> to be "fast enough" nowadays and 10 seconds seems to do it for most people
> -- plus, any 5-second advantage in boot time vanishes as soon as you go to
> your first web page.
>
> ron
>
>
>
> On Sun, Apr 2, 2017 at 5:31 PM ron minnich  wrote:
>
>> So, I'll mention go userland one last time, for a simple reason: I have
>> it on good authority that at some places, saying you have a go userland
>> instead of a c userland checks a check box on a security checklist. I think
>> that's a sensible decision, having watched all the awful ways that C
>> programs tend to go wrong :-)
>>
>> ron
>>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] VGA and Graphics

[ron minnich]

As for graphics startup, here's what I learned when I was doing this in
2012/2013: the kernel could start sandy and ivy with no vbios needed.
However, I have been told that the veil of secrecy has started to draw a
bit closer in subsequent chipsets, and that something like a VGA BIOS/GOP
has to run or graphics will not work. I really don't know, I have not
looked at this in over 3 years.

Todd, just to make sure we're on the same page, VBT is not code, it's a
table -- that's what the T is -- and you can create it any way you want.

Also, as for numbers: the fastest graphics startup, by far, was when we had
coreboot- based startup with configuration specialized to the chromeos
laptop. How fast? At one point we had a pixel booting to chromeos prompt in
2.7 seconds, reduced from 7.7 seconds when linux did the graphics init.
We've seen that the linux graphics init is highly concurrent and
generalized, and that tends to mean slow. Of course this was all far faster
than the 8086-mode vga BIOS supplied by "the vendor". But we were a bit
surprised to see how much faster coreboot was than the linux kernel.

I doubt this speed difference matters any more, since boot time only needs
to be "fast enough" nowadays and 10 seconds seems to do it for most people
-- plus, any 5-second advantage in boot time vanishes as soon as you go to
your first web page.

ron



On Sun, Apr 2, 2017 at 5:31 PM ron minnich  wrote:

> So, I'll mention go userland one last time, for a simple reason: I have it
> on good authority that at some places, saying you have a go userland
> instead of a c userland checks a check box on a security checklist. I think
> that's a sensible decision, having watched all the awful ways that C
> programs tend to go wrong :-)
>
> ron
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] VGA and Graphics

[ron minnich]

So, I'll mention go userland one last time, for a simple reason: I have it
on good authority that at some places, saying you have a go userland
instead of a c userland checks a check box on a security checklist. I think
that's a sensible decision, having watched all the awful ways that C
programs tend to go wrong :-)

ron
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] VGA and Graphics

[Trammell Hudson]

On Sun, Apr 02, 2017 at 09:18:10AM -0700, Todd Weaver wrote:
> [...]
> One of the three reasons we are including TPM in hardware is because of
> your great talk at 33c3 on Heads!

I'm glad to hear that it inspired you to include it!

> But I failed to see that it offered "boot menu type thing"

Currently there isn't any sort of boot selection menu; if
the default doesn't work you can drop into a "recovery shell",
which extends the PCRs to note that this has happened,
and allows the user to manually mount devices, fixup signatures,
run kexec, etc.

Adding a menuing system has been on the todo list for a while --
Zaolin started experimenting with plymouth, although it hasn't been
integrated into the rest of the system.

> [...]
> What we are looking at is to include or develop a solution that
> accomplishes these goals:
> 1) allows us to skip most of vbios (but sounds like still needs the VBT)
> 2) deliver a payload that has a path toward securing the boot process
> (e.g. Heads)
> 3) deliver a payload that can still offer a user to install their own OS
> (thus allowing user-configuration and control)

2 and 3 don't need to be separate stages, although it might make sense to
prototype them in two pieces to deal with ROM size issues.  This is the
approach the the Mass Open Cloud group is doing; their remote attestation
infrastructure is currently in python and has both glibc and OpenSSL
dependencies, so their Heads init script does a fetch, measure and
extract of a tar file from the network.  Porting it to work with
libtpm and musl-libc is later on their roadmap.

-- 
Trammell

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] VGA and Graphics

[Sam Kuper]

On 02/04/2017, Todd Weaver  wrote:
> On 04/01/2017 04:55 PM, Trammell Hudson wrote:
>> On Sat, Apr 01, 2017 at 07:43:40PM +, ron minnich wrote:
>>> For a payload chooser and such I can offer two options:
>>> 1) petitboot has a boot menu type thing
>>> 2) u-root (u-root.tk) is going to have a boot menu type thing, as we've
>>> been asked to do one.
>> Heads is coming along in usability and has a strong focus on securing
>> the boot process through TPM measurement and using the flash security
>> features.
>
> One of the three reasons we are including TPM in hardware is because of
> your great talk at 33c3 on Heads! But I failed to see that it offered
> "boot menu type thing"
>
>> It fits the 4.9.20 Linux kernel + initrd into 4 MB, including
>> all of the crypto, networking and other features.  The eventual user
>> kernel (or Xen hypervisor and dom0 kernel) are GPG verified and invoked
>> via
>> kexec for a slightly more secure, legacy free boot process.
>
> So this is referring more about "linux payload" than "boot menu type
> thing" correct? [...]
>
> What we are looking at is to include or develop a solution that
> accomplishes these goals:
> 1) allows us to skip most of vbios (but sounds like still needs the VBT)
> 2) deliver a payload that has a path toward securing the boot process
> (e.g. Heads)
> 3) deliver a payload that can still offer a user to install their own OS
> (thus allowing user-configuration and control)

Presumably petitboot, u-root, or another "boot menu type thing" could
be included in Heads? This would seem to be the best outcome.*

Whether that would still fit into 4MB is another matter, but it seems
worth a try. Even 8MB or 12MB would make it usable on some existing
motherboards without the need to desolder anything.

I look forward to seeing what emerges from your (hopeful) collaboration!

* Formal verification of all this would be even better, but that's
probably several years in the future :)

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] VGA and Graphics

[Todd Weaver]

On 04/01/2017 04:55 PM, Trammell Hudson wrote:
> On Sat, Apr 01, 2017 at 07:43:40PM +, ron minnich wrote:
>> Annnd with the linux payload we're back to linuxbios :-)
> It was a good idea in 1999, and it is still a good idea.

We *may* party like it's 1999 in 2017 then...

>> For a payload chooser and such I can offer two options:
>> 1) petitboot has a boot menu type thing
>> 2) u-root (u-root.tk) is going to have a boot menu type thing, as we've
>> been asked to do one.
> Heads is coming along in usability and has a strong focus on securing
> the boot process through TPM measurement and using the flash security
> features.

Trammell,
One of the three reasons we are including TPM in hardware is because of
your great talk at 33c3 on Heads! But I failed to see that it offered
"boot menu type thing"

> It fits the 4.9.20 Linux kernel + initrd into 4 MB, including
> all of the crypto, networking and other features.  The eventual user
> kernel (or Xen hypervisor and dom0 kernel) are GPG verified and invoked via
> kexec for a slightly more secure, legacy free boot process.

So this is referring more about "linux payload" than "boot menu type
thing" correct?

> More docs are online and pull requests are always appreciated:
>
>   http://osresearch.net/
>

What we are looking at is to include or develop a solution that
accomplishes these goals:
1) allows us to skip most of vbios (but sounds like still needs the VBT)
2) deliver a payload that has a path toward securing the boot process
(e.g. Heads)
3) deliver a payload that can still offer a user to install their own OS
(thus allowing user-configuration and control)

Thanks for writing!

Todd.



signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] VGA and Graphics

[Zoran Stojsavljevic]

>> Can we bypass the vbios/graphics within Coreboot and deliver the
>> Linux kernel payload and use its graphics?
> Yes, that would work. (In the case of Intel hardware) the Linux grap-
> phics driver does a superset of the things the VBIOS does. Actually,
> its default case is to ignore what the VBIOS did and start all over
> again. (One technical detail: You'd still have to put the Video BIOS
> Table, VBT into coreboot.)

As my very modest knowledge about vBIOS and Legacy BIOS is (I am, as
we speak, trying to understand much more in-depth about differences
between UEFI and Legacy), I think that, if you tend to bring Legacy
based Coreboot, there is NO chance to avoid VBT (Video BIOS Table),
which should/must be passed to Linux kernel, so Linux should/must
reuse it for its own GFX (with much richer super set of
functionality).

In contrary, if you use UEFI based context, then, instead of VBT
you'll use so called GOP driver (The Graphics Output Protocol (GOP) is
enabled by UEFI driver to support graphic
console output in the pre-OS phase).

The ultimate goal of GOP is to replace legacy VGA BIOS and eliminate
VGA HW functionality. Once you bring OS, it will NOT inherit GOP,
rather use its own GFX from scratch (sans VBT).

My two cent to this thread,
Zoran

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] VGA and Graphics

[Trammell Hudson]

On Sat, Apr 01, 2017 at 07:43:40PM +, ron minnich wrote:
> Annnd with the linux payload we're back to linuxbios :-)

It was a good idea in 1999, and it is still a good idea.

> For a payload chooser and such I can offer two options:
> 1) petitboot has a boot menu type thing
> 2) u-root (u-root.tk) is going to have a boot menu type thing, as we've
> been asked to do one.

Heads is coming along in usability and has a strong focus on securing
the boot process through TPM measurement and using the flash security
features.  It fits the 4.9.20 Linux kernel + initrd into 4 MB, including
all of the crypto, networking and other features.  The eventual user
kernel (or Xen hypervisor and dom0 kernel) are GPG verified and invoked via
kexec for a slightly more secure, legacy free boot process.

More docs are online and pull requests are always appreciated:

http://osresearch.net/

-- 
Trammell

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] VGA and Graphics

[ron minnich]

Annnd with the linux payload we're back to linuxbios :-)

For a payload chooser and such I can offer two options:
1) petitboot has a boot menu type thing
2) u-root (u-root.tk) is going to have a boot menu type thing, as we've
been asked to do one.

Overall I like the idea of the linux payload, of course :-)

If you're going to do that, however, I strongly recommend going with a 16 M
flash part. 8 will work for now but you're going to have issues long term.
Linux is not getting smaller over time ...

I'm actually working on this now so would like to help if possible.

with linux 4, and the new kexec "just load this file and boot it please"
support, it's very easy to use linux as a bootloader, far easier than it
used to be. We even have a kexec command written in Go in u-root. My
general experience is that linux is by far the best bootstrap out there, as
its drivers tend to be much more hardened than most bootloaders.

ron

On Sat, Apr 1, 2017 at 7:14 AM Todd Weaver  wrote:

> On 04/01/2017 05:24 AM, Nico Huber wrote:
> > On 01.04.2017 00:49, Todd Weaver wrote:
> >> On a related topic, but not related to vbios gfx; I met with
> >> Matthew Garrett while at LibrePlanet, and he mentioned that we needn't
> >> worry about graphics within coreboot or the vbios, but could just
> >> deliver Linux kernel and use the graphics stack from there.
> >>
> >> Can we bypass the vbios/graphics within
> >> coreboot and deliver the Linux kernel payload and use its graphics?
> > Yes, that would work. (In the case of Intel hardware) the Linux grap-
> > phics driver does a superset of the things the VBIOS does. Actually,
> > its default case is to ignore what the VBIOS did and start all over
> > again. (One technical detail: You'd still have to put the Video BIOS
> > Table, VBT into coreboot.)
>
> OK, we will research that.
>
> > However, you'd have no display before the kernel boots. That's a nit,
> > if you use the Linux kernel as payload but that comes with other impli-
> > cations. Currently, that would kill what I'd call the "legacy boot
> > experience". Without a payload like SeaBIOS, you can't just plug a USB
> > drive with a random OS on it and expect the system to boot from it.
>
> Yes, skipping "legacy boot experience" while a benefit (to avoid vbios)
> has the disadvantage of user control of replacing an OS with ease. So
> the next question is can we offer something similar after linux kernel
> payload? such as even a console based menu of boot options on esc? There
> may be existing projects I am unaware of that already look at linux
> kernel driven usb boot options.
>
> > Again, feel free to throw things at the coreboot mailing list.
>
> I am sending this there now. Thanks for your help!
>
> Todd.
>
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] VGA and Graphics

[Todd Weaver]

On 04/01/2017 05:24 AM, Nico Huber wrote:
> On 01.04.2017 00:49, Todd Weaver wrote:
>> On a related topic, but not related to vbios gfx; I met with
>> Matthew Garrett while at LibrePlanet, and he mentioned that we needn't
>> worry about graphics within coreboot or the vbios, but could just
>> deliver Linux kernel and use the graphics stack from there.
>>
>> Can we bypass the vbios/graphics within
>> coreboot and deliver the Linux kernel payload and use its graphics?
> Yes, that would work. (In the case of Intel hardware) the Linux grap-
> phics driver does a superset of the things the VBIOS does. Actually,
> its default case is to ignore what the VBIOS did and start all over
> again. (One technical detail: You'd still have to put the Video BIOS
> Table, VBT into coreboot.)

OK, we will research that.

> However, you'd have no display before the kernel boots. That's a nit,
> if you use the Linux kernel as payload but that comes with other impli-
> cations. Currently, that would kill what I'd call the "legacy boot
> experience". Without a payload like SeaBIOS, you can't just plug a USB
> drive with a random OS on it and expect the system to boot from it.

Yes, skipping "legacy boot experience" while a benefit (to avoid vbios)
has the disadvantage of user control of replacing an OS with ease. So
the next question is can we offer something similar after linux kernel
payload? such as even a console based menu of boot options on esc? There
may be existing projects I am unaware of that already look at linux
kernel driven usb boot options.

> Again, feel free to throw things at the coreboot mailing list.

I am sending this there now. Thanks for your help!

Todd.



signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot