[coreboot] VGA and Graphics

Tue Apr 4 20:43:46 CEST 2017

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 <coreboot at 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 at 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 <rminnich at gmail.com> 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 <rminnich at gmail.com> 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 at coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

-- 
WBR,
 Igor

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

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

-- 
WBR,
 Igor                            mailto:roxfan at skynet.be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20170404/f84ece0a/attachment.html>