coreboot April 2017

coreboot@coreboot.org

65 participants
143 discussions

Re: [coreboot] VGA and Graphics
by Igor Skochinsky 05 Apr '17

05 Apr '17

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> <matt.devillier(a)gmail.com> wrote: ZS> On Tue, Apr 4, 2017 at 10:12 PM, Zoran Stojsavljevic ZS> <zoran.stojsavljevic(a)gmail.com> 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> <zoran.stojsavljevic(a)gmail.com> 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> <matt.devillier(a)gmail.com> wrote: ZS> On Tue, Apr 4, 2017 at 2:23 PM, Zoran Stojsavljevic ZS> <zoran.stojsavljevic(a)gmail.com> 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, Igor mailto:skochinsky@mail.ru

2 1

Re: [coreboot] VGA and Graphics
by Patrick Rudolph 05 Apr '17

05 Apr '17

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_… that will print all tables in human readable form. Regards Patrick Am 4. April 2017 20:45:15 MESZ schrieb Nico Huber <nico.h(a)gmx.de>: >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(a)coreboot.org >https://www.coreboot.org/mailman/listinfo/coreboot

3 2

Re: [coreboot] VGA and Graphics
by Nico Huber 05 Apr '17

05 Apr '17

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

1 0

Re: [coreboot] VGA and Graphics
by Igor Skochinsky 05 Apr '17

05 Apr '17

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> <zoran.stojsavljevic(a)gmail.com> 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> <matt.devillier(a)gmail.com> wrote: rm> On Tue, Apr 4, 2017 at 10:12 PM, Zoran Stojsavljevic rm> <zoran.stojsavljevic(a)gmail.com> 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> <zoran.stojsavljevic(a)gmail.com> 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> <matt.devillier(a)gmail.com> wrote: rm> On Tue, Apr 4, 2017 at 2:23 PM, Zoran Stojsavljevic rm> <zoran.stojsavljevic(a)gmail.com> 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

1 0

The OpenSSD Project
by Taiidan＠gmx.com 05 Apr '17

05 Apr '17

An alternative to blobbed drive firmware. http://www.openssd-project.org/wiki/The_OpenSSD_Project I would like to share this and ask for opinions before I add it to the wiki. It is really neat that you can upgrade the memory chips individually, which should offset the high price.

2 1

ASUS KGPE-D16 Automated Test Failure [master]
by Raptor Engineering Automated Coreboot Test Stand 05 Apr '17

05 Apr '17

The ASUS KGPE-D16 fails verification for branch master as of commit c5f10f9d857215319c015af3673fadfe1ff3de34 The following tests failed: BOOT_FAILURE Commits since last successful test: c5f10f9 soc/intel/common: allow lpss i2c time-based data hold time See attached log for details This message was automatically generated from Raptor Engineering's ASUS KGPE-D16 test stand Want to test on your own equipment? Check out https://www.raptorengineering.com/content/REACTS/intro.html Raptor Engineering also offers coreboot consulting services! Please visit https://www.raptorengineering.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineering.com> regarding any issues stemming from this notification

1 0

Re: [coreboot] VGA and Graphics
by ron minnich 05 Apr '17

05 Apr '17

Zoran, given that we still see _MP_ and even $PIR tables in BIOS, is it possible that VBT might always be there even if it's not strictly needed? How do non-EFI kernels get information about video if not via the VBT? On Wed, Apr 5, 2017 at 8:03 AM Zoran Stojsavljevic < zoran.stojsavljevic(a)gmail.com> wrote: > To Coreboot, > > > http://www.uefi.org/sites/default/files/resources/UPFS11_P4_UEFI_GOP_AMD.pdf > > Please, read about GOP, and what GOP suppose to be. > > So, GOP actually need to replace vBIOS, VBT, legacy INT 10H, and complete > VBE 3.0 standard. Why (I have no idea what INTEL does with GOP and how it > implements it) it is not done in this fashion...?! At least this is my > impression how this should be done. > > I'll continue to investigate. > > Thank you, > Zoran > > On Wed, Apr 5, 2017 at 4:54 PM, Matt DeVillier <matt.devillier(a)gmail.com> > wrote: > > On Tue, Apr 4, 2017 at 10:12 PM, Zoran Stojsavljevic < > zoran.stojsavljevic(a)gmail.com> wrote: > > Hello Matt, > > Pretty sure there is NO Option ROM, vBIOS and INT10H. Why INTEL for GOP > uses VBT is point of debate. Probably just reduced functionality up to > 1280x1024. So they have VBT to support BIOS phase GOP GFX. Only! > > > From what I can tell, it's mainly used to provide the output connector > types/mapping to the GOP driver, as well as level shifting etc. > > > > But I am also 100% sure neither GOP, neither VBT survives post BIOS phase. > It is out of mind to use VBT for WUXGA, or 1080p, or 4K displays, don't you > agree? The detected GFX I/F are passed to Linux as Run Time info (via HOB). > Then Linux brings from scratch GFX, using its own, modern I/Fs. And ports > appropriate drivers to existing GFX info from HOB. > > > The VBT data is used by both the Linux and Windows display drivers (via > the OpRegion ACPI structure), and the latter will give you a nice black > screen if your VBT is missing or incorrectly configured. As I noted above, > it appears to be used more for output/pipe info than display modes (which > are all generated from EDID, outside of standard VESA/CEA ones) > > On Tue, Apr 4, 2017 at 10:12 PM, Zoran Stojsavljevic < > zoran.stojsavljevic(a)gmail.com> wrote: > > Hello Matt, > > Pretty sure there is NO Option ROM, vBIOS and INT10H. Why INTEL for GOP > uses VBT is point of debate. Probably just reduced functionality up to > 1280x1024. So they have VBT to support BIOS phase GOP GFX. Only! > > But I am also 100% sure neither GOP, neither VBT survives post BIOS phase. > It is out of mind to use VBT for WUXGA, or 1080p, or 4K displays, don't you > agree? The detected GFX I/F are passed to Linux as Run Time info (via HOB). > Then Linux brings from scratch GFX, using its own, modern I/Fs. And ports > appropriate drivers to existing GFX info from HOB. > > Zoran > > On Tue, Apr 4, 2017 at 11:51 PM, Matt DeVillier <matt.devillier(a)gmail.com> > wrote: > > > > On Tue, Apr 4, 2017 at 2:23 PM, Zoran Stojsavljevic < > zoran.stojsavljevic(a)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. > > > > >

1 0

Re: [coreboot] VGA and Graphics
by Zoran Stojsavljevic 05 Apr '17

05 Apr '17

To Coreboot, http://www.uefi.org/sites/default/files/resources/UPFS11_P4_UEFI_GOP_AMD.pdf Please, read about GOP, and what GOP suppose to be. So, GOP actually need to replace vBIOS, VBT, legacy INT 10H, and complete VBE 3.0 standard. Why (I have no idea what INTEL does with GOP and how it implements it) it is not done in this fashion...?! At least this is my impression how this should be done. I'll continue to investigate. Thank you, Zoran On Wed, Apr 5, 2017 at 4:54 PM, Matt DeVillier <matt.devillier(a)gmail.com> wrote: > On Tue, Apr 4, 2017 at 10:12 PM, Zoran Stojsavljevic <zoran. > stojsavljevic(a)gmail.com> wrote: > >> Hello Matt, >> >> Pretty sure there is NO Option ROM, vBIOS and INT10H. Why INTEL for GOP >> uses VBT is point of debate. Probably just reduced functionality up to >> 1280x1024. So they have VBT to support BIOS phase GOP GFX. Only! >> > > From what I can tell, it's mainly used to provide the output connector > types/mapping to the GOP driver, as well as level shifting etc. > > >> >> But I am also 100% sure neither GOP, neither VBT survives post BIOS >> phase. It is out of mind to use VBT for WUXGA, or 1080p, or 4K displays, >> don't you agree? The detected GFX I/F are passed to Linux as Run Time info >> (via HOB). Then Linux brings from scratch GFX, using its own, modern I/Fs. >> And ports appropriate drivers to existing GFX info from HOB. >> > > The VBT data is used by both the Linux and Windows display drivers (via > the OpRegion ACPI structure), and the latter will give you a nice black > screen if your VBT is missing or incorrectly configured. As I noted above, > it appears to be used more for output/pipe info than display modes (which > are all generated from EDID, outside of standard VESA/CEA ones) > > On Tue, Apr 4, 2017 at 10:12 PM, Zoran Stojsavljevic < > zoran.stojsavljevic(a)gmail.com> wrote: > >> Hello Matt, >> >> Pretty sure there is NO Option ROM, vBIOS and INT10H. Why INTEL for GOP >> uses VBT is point of debate. Probably just reduced functionality up to >> 1280x1024. So they have VBT to support BIOS phase GOP GFX. Only! >> >> But I am also 100% sure neither GOP, neither VBT survives post BIOS >> phase. It is out of mind to use VBT for WUXGA, or 1080p, or 4K displays, >> don't you agree? The detected GFX I/F are passed to Linux as Run Time info >> (via HOB). Then Linux brings from scratch GFX, using its own, modern I/Fs. >> And ports appropriate drivers to existing GFX info from HOB. >> >> Zoran >> >> On Tue, Apr 4, 2017 at 11:51 PM, Matt DeVillier <matt.devillier(a)gmail.com >> > wrote: >> >>> >>> >>> On Tue, Apr 4, 2017 at 2:23 PM, Zoran Stojsavljevic < >>> zoran.stojsavljevic(a)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. >>> >> >> >

1 0

Re: [coreboot] VGA and Graphics
by Matt DeVillier 05 Apr '17

05 Apr '17

On Tue, Apr 4, 2017 at 10:12 PM, Zoran Stojsavljevic < zoran.stojsavljevic(a)gmail.com> wrote: > Hello Matt, > > Pretty sure there is NO Option ROM, vBIOS and INT10H. Why INTEL for GOP > uses VBT is point of debate. Probably just reduced functionality up to > 1280x1024. So they have VBT to support BIOS phase GOP GFX. Only! > >From what I can tell, it's mainly used to provide the output connector types/mapping to the GOP driver, as well as level shifting etc. > > But I am also 100% sure neither GOP, neither VBT survives post BIOS phase. > It is out of mind to use VBT for WUXGA, or 1080p, or 4K displays, don't you > agree? The detected GFX I/F are passed to Linux as Run Time info (via HOB). > Then Linux brings from scratch GFX, using its own, modern I/Fs. And ports > appropriate drivers to existing GFX info from HOB. > The VBT data is used by both the Linux and Windows display drivers (via the OpRegion ACPI structure), and the latter will give you a nice black screen if your VBT is missing or incorrectly configured. As I noted above, it appears to be used more for output/pipe info than display modes (which are all generated from EDID, outside of standard VESA/CEA ones) On Tue, Apr 4, 2017 at 10:12 PM, Zoran Stojsavljevic < zoran.stojsavljevic(a)gmail.com> wrote: > Hello Matt, > > Pretty sure there is NO Option ROM, vBIOS and INT10H. Why INTEL for GOP > uses VBT is point of debate. Probably just reduced functionality up to > 1280x1024. So they have VBT to support BIOS phase GOP GFX. Only! > > But I am also 100% sure neither GOP, neither VBT survives post BIOS phase. > It is out of mind to use VBT for WUXGA, or 1080p, or 4K displays, don't you > agree? The detected GFX I/F are passed to Linux as Run Time info (via HOB). > Then Linux brings from scratch GFX, using its own, modern I/Fs. And ports > appropriate drivers to existing GFX info from HOB. > > Zoran > > On Tue, Apr 4, 2017 at 11:51 PM, Matt DeVillier <matt.devillier(a)gmail.com> > wrote: > >> >> >> On Tue, Apr 4, 2017 at 2:23 PM, Zoran Stojsavljevic < >> zoran.stojsavljevic(a)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. >> > >

1 0

Re: [coreboot] VGA and Graphics
by Zoran Stojsavljevic 05 Apr '17

05 Apr '17

Hello Matt, Pretty sure there is NO Option ROM, vBIOS and INT10H. Why INTEL for GOP uses VBT is point of debate. Probably just reduced functionality up to 1280x1024. So they have VBT to support BIOS phase GOP GFX. Only! But I am also 100% sure neither GOP, neither VBT survives post BIOS phase. It is out of mind to use VBT for WUXGA, or 1080p, or 4K displays, don't you agree? The detected GFX I/F are passed to Linux as Run Time info (via HOB). Then Linux brings from scratch GFX, using its own, modern I/Fs. And ports appropriate drivers to existing GFX info from HOB. Zoran On Tue, Apr 4, 2017 at 11:51 PM, Matt DeVillier <matt.devillier(a)gmail.com> wrote: > > > On Tue, Apr 4, 2017 at 2:23 PM, Zoran Stojsavljevic < > zoran.stojsavljevic(a)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. >

1 0

← Newer
1
...
9
10
11
12
13
14
15
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot April 2017