[coreboot] How to handle vbt.bin

[Nico Huber]

On 16.04.2018 08:44, Patrick Rudolph wrote:
> On 2018-04-15 11:30 PM, Nico Huber wrote:
>> On 15.04.2018 17:12, Patrick Rudolph wrote:
>>> 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 ?
>>
>> Sure I can, in some cases even with cbfstool.
>>
>>>
>>> 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.
>>
>> Yeah, same when we add the VBT to the main repo.
>>
>>>
>>> The benefit of having it in blobs repo is that it increases compability
>>> and user friendliness. Just tick the Kconfig option, done.
>>
>> Not true, you'd also have to tick USE_BLOBS (and wonder why it's neces-
>> sary in case your platform doesn't need real (code) blobs). The benefit
>> of having it in the main repo is that it increases sanity and user-
>> friendliness. Just leave the default, done.
>>
> I guess the solution is simple. Let's not call VBT a BLOB.

Yes. Sorry, I thought we already agreed on that. Now that I looked back,
nobody wrote it down literally yet (in this thread).

> 1) It's not that large ~3-7KiB in times of mobile devices that have
> multiple GiB of storage.
> 2) In coreboot BLOB is considered to contain code. VBT is only data.
> 3) One could argue that it's basically a key value file, where the keys
> are predefined through VBT version and section IDs. Such a file is
> called configuration file.
> 
> If it's a configuration file, it should *not* be placed in blobs repo.
> We should also update the Kconfig option USE_BLOBS and explain that it
> is only for files that contain executable code. It's not clear for me
> reading the current help message.

Yes, we really should make that explicit. It's also how the term blob is
generally used wrt. software [1].

[1] https://en.wikipedia.org/wiki/Binary_blob