Hi
Recently there has been some development towards better handling of the VBT (Video BIOS Table) on Intel targets within coreboot. [1],[2](and a whole lot of patches that hook up this code).
VBT is usually a part of the option rom for the Intel integrated graphic device. It is pure configuration data that is in binary format, has a variable length and is fully documented. The OS typically needs to know a few things about the hardware like on which I2C address to talk to SDVO devices, which I2C pins to use for the VGA port (standalone or shared with DVI-I port). Linux can typically work to some extend without it by it assumes some defaults but the Windows drivers fails to work without it. I heard it is also a hard requirement for the GOP (pre-os driver).
Usually this VBT data is passed on via the option rom address for video devices (0xc0000) but this can also be passed on via ACPI via a pointer, which coreboot can do (either by extracting it from an option rom in cbfs or via a cbfsfile named vbt.bin)
Now the real question.
Since this is purely configuration data that is also fully documented it holds no copyright and can be included into the coreboot project without legal troubles. Now one would be able to generate this binary file but due to its modularity and variable length such generator would be tedious to create. So currently the option are to either include the binary in the blob repo or in the main repo.
An argument was made that it belongs in the main repo in the src/mainboard/*/*/ dir as we already have binary configuration data in there, namely SPD (serial presence detect) for soldered dram. Also having the policy of allowing (and encouraging) such binaries in the main repo could make it easier for users to run their self-build coreboot roms on devices from big coreboot vendors (like Google).
So what are your thoughts on this?
Kind regards
Arthur Heymans
--------------
[1] https://review.coreboot.org/#/c/coreboot/+/18902/ [2] https://review.coreboot.org/#/c/coreboot/+/19905/
my instinct is to put it in the 3rd party blobs repo, since it's added to the CBFS w/o modification (ie, is treated like a blob), unlike the SPD hex files which are selectively ordered and assembled into the spd.bin (ie, treated as source).
For the example case you sited of users building coreboot images for Chromebooks (eg), they still need numerous other platform/device specific blobs (ie, FSP), so having the vbt alone in the main repo is really not of any consequence. I'd also like to see those other required blobs in the 3rd party blobs repo, but that's an entirely separate issue :)
On Thu, Apr 5, 2018 at 3:24 AM, Arthur Heymans arthur@aheymans.xyz wrote:
Hi
Recently there has been some development towards better handling of the VBT (Video BIOS Table) on Intel targets within coreboot. [1],[2](and a whole lot of patches that hook up this code).
VBT is usually a part of the option rom for the Intel integrated graphic device. It is pure configuration data that is in binary format, has a variable length and is fully documented. The OS typically needs to know a few things about the hardware like on which I2C address to talk to SDVO devices, which I2C pins to use for the VGA port (standalone or shared with DVI-I port). Linux can typically work to some extend without it by it assumes some defaults but the Windows drivers fails to work without it. I heard it is also a hard requirement for the GOP (pre-os driver).
Usually this VBT data is passed on via the option rom address for video devices (0xc0000) but this can also be passed on via ACPI via a pointer, which coreboot can do (either by extracting it from an option rom in cbfs or via a cbfsfile named vbt.bin)
Now the real question.
Since this is purely configuration data that is also fully documented it holds no copyright and can be included into the coreboot project without legal troubles. Now one would be able to generate this binary file but due to its modularity and variable length such generator would be tedious to create. So currently the option are to either include the binary in the blob repo or in the main repo.
An argument was made that it belongs in the main repo in the src/mainboard/*/*/ dir as we already have binary configuration data in there, namely SPD (serial presence detect) for soldered dram. Also having the policy of allowing (and encouraging) such binaries in the main repo could make it easier for users to run their self-build coreboot roms on devices from big coreboot vendors (like Google).
So what are your thoughts on this?
Kind regards
Arthur Heymans
[1] https://review.coreboot.org/#/c/coreboot/+/18902/ [2] https://review.coreboot.org/#/c/coreboot/+/19905/
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Arthur Heymans wrote:
one would be able to generate this binary file but due to its modularity and variable length such generator would be tedious to create.
How tedious?
Do you know where documentation can be found?
//Peter
On 15.04.2018 14:28, Peter Stuge wrote:
Arthur Heymans wrote:
one would be able to generate this binary file but due to its modularity and variable length such generator would be tedious to create.
How tedious?
I think the tedious part is choosing which fields you want to fill. The available fields vary between generations. There's lots of historical ballast and you don't know which fields are required (VBT is mostly nee- ded for Windows and who knows what the driver does there; when it comes to Linux, we should at least try to talk some sense into the developer's to tell us which information they really need).
Do you know where documentation can be found?
The most comprehensive documentation I know about the various sub-tables and how they are organized is the i915 Linux driver code that reads it. There are also per-platform description files that tell a "binary modi- fication program" by Intel what bit is what. You can find them sometimes along the FSP releases (e.g. [1]; 9972 lines, yeah!).
If somebody really wants to digest complete VBTs, I think the best shot would be to translate these description files into something nicer and have a tool like bincfg [2] to translate human readable VBTs into binary ones (based on the description). And talk Intel into always releasing the description files, ofc.
Nico
[1] https://github.com/IntelFsp/FSP/blob/BayTrail/BayTrailFspBinPkg/Vbios/Vga.bs... [2] https://review.coreboot.org/cgit/coreboot.git/tree/util/bincfg/
Nico Huber wrote:
VBT is mostly nee- ded for Windows and who knows what the driver does there; when it comes to Linux, we should at least try to talk some sense into the developer's to tell us which information they really need.
I wouldn't assume that they know in advance - I think they may just have to deal with whatever is produced by hardware engineering.
Do you know where documentation can be found?
The most comprehensive documentation I know about the various sub-tables and how they are organized is the i915 Linux driver code that reads it. There are also per-platform description files that tell a "binary modi- fication program" by Intel what bit is what. You can find them sometimes along the FSP releases (e.g. [1]; 9972 lines, yeah!).
BSF describes the data structure perfectly. (What a fun file format! :)
Zoran's Wikipedia article links to this, which clears up the binary format:
https://cgit.freedesktop.org/xorg/app/intel-gpu-tools/tree/tools/intel_vbt_d...
If somebody really wants to digest complete VBTs, I think the best shot would be to translate these description files into something nicer and have a tool like bincfg [2] to translate human readable VBTs into binary ones (based on the description).
That makes perfect sense.
A human readable VBT representation has a clear place in the mainboard directory for all applicable platforms. That would be a good thing.
I don't know if the entire data structure must neccessarily be integrated into Kconfig, but maybe if someone has a lot of free time... :)
//Peter
-
Arthur Heymans -
Matt DeVillier -
Nico Huber -
Peter Stuge