[coreboot] How to handle vbt.bin

[Matt DeVillier]

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 at 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 at coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20180405/07e37c44/attachment.html>