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 <nic...@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 -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot