coreboot April 2017

coreboot@coreboot.org

65 participants
143 discussions

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

04 Apr '17

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 ron minnich 04 Apr '17

04 Apr '17

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.stojsavljevic(a)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 <rminnich(a)gmail.com> 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(a)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(a)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/ > <https://en.wikipedia.org/wiki/VESA_BIOS_Extensions>VESA_BIOS_Extensions > <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(a)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(a)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(a)coreboot.org > https://www.coreboot.org/mailm > <https://www.coreboot.org/mailman/listinfo/coreboot>an/listinfo/coreboot > <https://www.coreboot.org/mailman/listinfo/coreboot> > > > > > > > > > *-- WBR, Igor *-- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/ > <https://www.coreboot.org/mailman/listinfo/coreboot> > mailman/listinfo/coreboot > <https://www.coreboot.org/mailman/listinfo/coreboot> > > > > > > *-- WBR, Igor* > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot > > >

1 0

Re: [coreboot] Disabling Auto-Refresh of DRAM Using Coreboot
by Berj K Chilingirian 04 Apr '17

04 Apr '17

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.stojsavljevic(a)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.<https://www.techinsights.com/uploadedFiles/Public_Website/Content_-_Primary…> 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 <berjc(a)mit.edu<mailto:berjc@mit.edu>> 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<http://www.pdl.cmu.edu/PDL-FTP/NVM/dram-retention_isca13.pdf>, 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 <zoran.stojsavljevic(a)gmail.com<mailto:zoran.stojsavljevic@gmail.com>> wrote: > Quantify data retention of unpowered memory. Let us asses/investigate what is the technology of C (capacitor) in the presented diagram<https://upload.wikimedia.org/wikipedia/commons/b/bd/DRAM_Cell_Structure_%28…> 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 more (on the ONO - Oxide-Nitride-Oxide dielectric material): The commonly used technology for non-volatile Flash memory application consists of a stacked-gate transistor with dual gates. The Oxide-Nitride-Oxide (ONO) stacks constitute the inter-poly dielectric layer between those gates. These top and bottom polycrystalline silicon plates are also known as the control gate (CG) and the floating gate (FG) respectively. During read and write operation of a flash memory device, a high electrical bias needs to be applied through the control gate in order for electrons to be tunneled through the thin tunnel oxide towards the floating gate which is surrounded by dielectric material. Although the same material is used in DRAMs and FLASHes (as in one case for dielectric in Cs, in other channel material for the FETs with dual gates), the design of DRAMs and FLASHes are essentially very different, as I see. It seems to me that in case of C, ONO is dielectric which holds the capacitor charge, and leaks it through dielectric, in the case of dual gate FETs we have here The Tunnel Effect, which captures some number of free electrons inside the ONO. Well... I am also curious (as you, Peter), what will be the retention time, but, as a difference to you, I think that after maximum of 7.8us x 2 some bits (maybe 5% of them, even less, but certainly more than 0.1%) will be corrupted. Now, after the quick analysis/assessment I made, now I understand why all the DRAM companies are trying to pack future DDRs as FLASHes. Never came to me before to investigate this... But there is always the first time (courtesy of Mr, Chilingirian, Massachusetts Institute of Technology). ;-) Zoran _______ On Fri, Mar 24, 2017 at 12:19 PM, Peter Stuge <peter(a)stuge.se<mailto:peter@stuge.se>> wrote: Zoran Stojsavljevic wrote: > I am not sure what are you really trying to do, Quantify data retention of unpowered memory. > and, mostly WHY you are trying to do what you are trying to do?! To challenge the assumption that data is lost without power. It is an interesting area of research because that assumption - or simplification - is so widespread, although not at all correct. //Peter -- coreboot mailing list: coreboot(a)coreboot.org<mailto:coreboot@coreboot.org> https://www.coreboot.org/mailman/listinfo/coreboot

1 0

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

04 Apr '17

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 <rminnich(a)gmail.com> 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(a)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(a)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/ >> <https://en.wikipedia.org/wiki/VESA_BIOS_Extensions>VESA_BIOS_Extensions >> <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(a)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(a)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(a)coreboot.org >> https://www.coreboot.org/mailm >> <https://www.coreboot.org/mailman/listinfo/coreboot>an/listinfo/coreboot >> <https://www.coreboot.org/mailman/listinfo/coreboot> >> >> >> >> >> >> >> >> >> *-- WBR, Igor *-- >> coreboot mailing list: coreboot(a)coreboot.org >> https://www.coreboot.org/ >> <https://www.coreboot.org/mailman/listinfo/coreboot>mailm >> an/listinfo/coreboot <https://www.coreboot.org/mailman/listinfo/coreboot> >> >> >> >> >> >> *-- WBR, Igor* >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://www.coreboot.org/mailman/listinfo/coreboot > >

1 0

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

04 Apr '17

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

1 0

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

04 Apr '17

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_… [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(a)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(a)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(a)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(a)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(a)coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot -- WBR, Igor -- coreboot mailing list: coreboot(a)coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot -- WBR, Igor -- coreboot mailing list: coreboot(a)coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot -- WBR, Igor mailto:roxfan@skynet.be

1 0

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

04 Apr '17

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(a)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(a)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(a)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(a)coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot -- WBR, Igor -- coreboot mailing list: coreboot(a)coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot -- WBR, Igor

2 1

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

03 Apr '17

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(a)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(a)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(a)coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot -- WBR, Igor

2 1

Overheating on f2a85-m
by Piotr Kubaj 03 Apr '17

03 Apr '17

I've installed Coreboot on ASUS F2A85-M. Everything works fine, but the CPU overheats when doing something intensive (like video playing) and the OS crashes. Browsing the internet and watching movies doesn't make it sweat. I use FreeBSD 11.0-RELEASE and Gentoo Linux. My CPU is X4 750k. I lowered the RAM voltage to 1.35V but it doesn't really help. Enabling power saving features also doesn't make a difference. Everything works fine on vendor UEFI, so this issue is specific to Coreboot. Any idea what I can do? -- ________________________________________ / A domineering man married a mere wisp \ | of a girl. He came back from his | | honeymoon a chastened man. He'd become | \ aware of the will of the wisp. / ---------------------------------------- \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || ||

4 5

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

03 Apr '17

> *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 <rminnich(a)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(a)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(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

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