[coreboot] How to handle vbt.bin

[Patrick Rudolph]

On Sun, 2018-04-15 at 13:43 +0200, Nico Huber wrote:
> On 15.04.2018 12:48, Patrick Rudolph wrote:
> > On Thu, 2018-04-05 at 11:34 -0500, Matt DeVillier wrote:
> > > On Thu, Apr 5, 2018 at 11:29 AM, Nico Huber <nico.h at gmx.de> wrote:
> > > > On 05.04.2018 18:15, Matt DeVillier wrote:
> > > > > 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).
> > 
> > I would like to see them in 3rd party repo, as we don't process them,
> > as Matt pointed out.
> > 
> > > > Files are concatenated, I don't see how this is treating sth. as
> > > > source.
> > > > 
> > 
> > They are changed from ASCII/text to binary format, so yes it's a source
> > file.
> 
> lol. I had that discussion before, and no: hexdumping something doesn't
> make it source (code).
> 
> Is this really where you want to draw the line? can I put my ME firmware
> into the main repo too if I hexdump it?
> 
> Btw. there is no reason to have SPDs as hex. Should we move them to
> 3rdparty/blobs too?
> 
For SPDs: No. As you can't extract them from vendor image, can you ?

For VBT: Why not. A user is free to choose to use the blob from blobs
repo, extract it his own from vendor image, use a VGA option ROM or use
the fake VBT mechanism.

The benefit of having it in blobs repo is that it increases compability
and user friendliness. Just tick the Kconfig option, done.

It is independed from a free tool to generate a VBT (which would be
nice to have).

> Nico
> 
> PS. Please fix your mail client. It shouldn't break quoted lines.
> 
> PPS. If VBT ends up in 3rdparty/blobs, please also make a distinction
>      in Kconfig between binary programs and configuration data (or get
>      rid of USE_BLOBS).