[coreboot] How to handle vbt.bin

[Zoran Stojsavljevic]

Lot af talk, no work... All of this is already architected. I already did
some ground work here (also parts assembled from Coreboot responses
approximately a year ago):
https://en.wikipedia.org/wiki/Coreboot/VBT

The thing which needs to be done ASAP (in *RED*):

   1. Make a "decompiler" that would convert VBT from the option ROM into a
   human/machine readable text format
   2. *Make a "compiler" that would take that text format and create a
   binary VBT from it*
   3. Put the binary VBT into the ACPI IGD OpRegion table (or wherever the
   graphics driver can find it).

1. is already done (I extracted small subset of the functions from INTEL
GPU tools here):
https://github.com/ZoranStojsavljevic/Video-BIOS-Table-parser-assembler

So, volunteers needed (I abandoned long time ago this effort in favour of
YOCTO Project, Linux and Hypervisors & Virtual Machines handling). ;-)

Best Regards,
Zoran
_______

On Mon, Apr 16, 2018 at 10:44 AM, Nico Huber <nico.h at gmx.de> wrote:

> 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
>
> --
> 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/20180416/9e11d994/attachment.html>