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] Disabling Auto-Refresh of DRAM Using Coreboot

[Berj K Chilingirian]

Hi Zoran,

Thanks for the reference; you make a great point. My hope is that experiments 
with DRAM will stand as a case study in support of open source firmware that 
fingerprints HW during boot with the intention of identifying 
counterfeit/faulty modules. Measuring the retention time of DRAM happens to be 
one technique, but I suspect there are other side-channels (e.g. power 
consumption, latencies) that expose self-identifying behaviors and that may 
extend to other HW modules of a system. In summary, I am interested in security 
extensions to Coreboot which provide a user with more transparency to what is 
under the hood of their machine.

I will certainly keep you all posted on the results! I am still struggling to 
properly turn off the auto-refresh of DRAM and measure the retention time in 
Coreboot. I would much appreciate any further guidance on how to do this (or 
especially if anyone can refer me to the AMD AGESA Memory team; I have been 
unable to find contact info online).

Thank you!
Berj

From: Zoran Stojsavljevic [zoran.stojsavlje...@gmail.com]
Sent: Saturday, March 25, 2017 5:28 AM
To: Berj K Chilingirian
Cc: Peter Stuge; coreboot
Subject: Re: [coreboot] Disabling Auto-Refresh of DRAM Using Coreboot

> For instance, the CPU may convey to the user during boot: “Your DRAM claims 
> it is made by manufacturer A but
> it is acting like it is made by manufacturer B. Manufacturer B is known to be 
> susceptible to these hardware trojans, defects, etc.”

Interesting work. To invent SW/FW algorithm to survey DRAM in order to find out 
what are retention times, and based upon that to construct SPD flash info.

The mortal problem with DDRs and refresh times waits just around the corner, 
since the technology of the gate, upon shrinking (present gate sizes around 
22/20nm) the refreshing time drops. As the stochastics/volatility about 
retention times rises. Very soon it'll hit Dead End (around 16/14nm).

And... Hitting (with the current technology) The Dead End (complete denial of 
Moore's Law, which is imminent), do you think it is worth?

Link to 
read.

Well... It is a true experimental job, and I wish you good luck with it. :-)

Please, keep us posted!

Zoran

On Fri, Mar 24, 2017 at 6:14 PM, Berj K Chilingirian 
> wrote:
Hi Zoran and Peter,

I’m actually interested in the retention time of DRAM cells for fingerprinting 
purposes (i.e. not for any kind of performance tuning). It turns out that 
retention time information (such as the distribution of retention times across 
the cells of DRAM) can be used to identify the manufacturer of that DRAM (see 
here, especially 
Figure 8, for details). The paper cited uses an FPGA implementation to measure 
the retention time. In contrast, I’m interested in seeing whether this 
relationship holds under a traditional setup and how it may then be leveraged 
to build secure systems that make their hardware (e.g. DRAM) transparent to the 
user without relying on static information like the SPD.

For instance, the CPU may convey to the user during boot: “Your DRAM claims it 
is made by manufacturer A but it is acting like it is made by manufacturer B. 
Manufacturer B is known to be susceptible to these hardware trojans, defects, 
etc.”

This is, of course, a very research oriented project with many strong 
assumptions, but I’m hoping that it will lead to some interesting results (it 
is part of my master’s thesis).

Thus, that is why I need to figure out a way to disable the auto-refresh of 
DRAM ;)

Best,
Berj
On Mar 24, 2017, at 8:01 AM, Zoran Stojsavljevic 
> wrote:

> Quantify data retention of unpowered memory.

Let us asses/investigate what is the technology of C (capacitor) in the 
presented 
diagram
 in my previous email!

The capacitor in the stacked capacitor scheme is constructed above the surface 
of the substrate. The capacitor is constructed from an oxide-nitride-oxide 
(ONO) dielectric sandwiched in between two layers of polysilicon plates (the 
top plate is shared by all DRAM cells in an IC), and its shape can be a 
rectangle, a cylinder, or some other more complex shape. There are two basic 
variations of the stacked capacitor, based on its location relative to the 
bitline—capacitor-over-bitline (COB) and capacitor-under-bitline (CUB). In a 
former variation, the capacitor is underneath the bitline, which is usually 
made of metal, and the bitline has a polysilicon contact that extends downwards 
to connect it to the access transistor's source terminal.

Well, let us search 

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] Coreboot gamers?

[taii...@gmx.com]

On 04/03/2017 08:25 AM, Denis 'GNUtoo' Carikli wrote:


On Sun, 2 Apr 2017 16:05:42 -0400
"taii...@gmx.com"  wrote:


Hey any other coreboot gamers?

Hi,


What are your specs, games do you play
and on what settings?

I don't play often, and some of the times, it's to test if the GPU
still works fine. I only play free software games, and I don't have
enough time to investigate games that are not packaged in the GNU/Linux
distribution[1] I use.

As the games I test/play:
- Xonotic
- Supertuxkart

I like a lot some other games, but they are probably not relevant here
because they are not that demanding with reguard to computer
specifications.
For instance Battle for wesnoth doesn't even require 3D acceleration...


I purchased my D16 specifically for IOMMU-GFX VM gaming, I have a
6274 with a geforce gtx 780 and the new highly multithreaded games
work great on it - right now I am playing battlefield 1 and wargame
red dragon on high settings. I do want to get a 6386 or dual 6328's
so that I can play older games though due to my CPU's crappy single
thread performance.

In the computers I have[2], the i945 thinkpads are too old to be able
to play recent supertuxkart versions on my distribution[1].
I didn't test gaming extensively yet on the Lenovo Thinkpad X200 as I
would need to go buy more RAM to do that: 2G of RAM isn't enough to
some of the more demanding games I care about.
You could get an ExpressCard eGPU for your x200 or x220's, I used to do 
that and it works decently.


I don't have my desktops here, and I don't remember the GPU models, I
only know that they are supported by nouveau and work with free
software firmwares. I use fanless GPUs to avoid them making too much
noise.
The nice side effect is that nouveau doesn't need to handle power
management to make use of them efficently.

I tested supertuxkart on the:
- Asus F2A85-M PRO
- Asus M4A785T-M

While I'm able to play, the ports are not complete yet and might
require additional hardware such as:
- USB Ethernet card in the case of the F2A85M PRO
- USB Sound card in the case of the M4A785T-M
I have always wondered what comes in to the porting choices of people, 
how come you are porting a 7xx series chipset board instead of an 8xx or 
9xx? (as they are better, newer and support IOMMU)
Or why leah had the KGPE-D16 ported and not one of the better newer 
(2014) Supermicro boards with dual northbridge (so way more pci-e lanes 
to go around) and onboard SR-IOV nics. (82576L vs D16's 82574L)

Thanks



Does anyone use Crossfire xDMA? It has dual 2.0 x16 slots and PCI-e
ACS so it should work (and people have reported it does with the
vendor bios)

It would be interesting to see how the free software linux drivers
handles it too:
- Nouveau doesn't seem to support[3].
- Radeon doesn't seem to support it either[4].
I game in a windows VM, so I would be attaching both cards to it. I 
would be getting radeon as nvidia doesn't like FOSS or IOMMU-GFX on 
their "consumer" platforms (see the code 43 "bug" they introduced)


However I wonder if SLI/Crossfire is still stricly required to be able
to efficently use several GPU in a computer:
It might be interesting to see if there are (less efficent?) ways to
use several GPUs in the same game with GPU offloading / render nodes.

I personally have 2 nvidia GPUs so it might be worth investigating it.

I would need to add support for the F2A85-M pro for the second pcie 16x
slot first though.

References:
---
[1]Parabola: https://www.parabola.nu/
[2]https://www.coreboot.org/User:GNUtoo#My_hardware
[3]https://nouveau.freedesktop.org/wiki/FeatureMatrix/
[4]https://www.x.org/wiki/RadeonFeature/
[5]https://wiki.archlinux.org/index.php/PRIME#PRIME_GPU_offloading

Denis.



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