<div dir="ltr"><div><div><div><div>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):<br><a href="https://en.wikipedia.org/wiki/Coreboot/VBT">https://en.wikipedia.org/wiki/Coreboot/VBT</a><br><br></div>The thing which needs to be done ASAP (in <span style="color:rgb(255,0,0)"><u><i><b>RED</b></i></u></span>):<br><ol>
<li>Make a "decompiler" that would convert VBT from the option ROM into a human/machine readable text format</li>
<li><u><span style="color:rgb(255,0,0)"><i><b>Make a "compiler" that would take that text format and create a binary VBT from it</b></i></span></u></li>
<li>Put the binary VBT into the ACPI IGD OpRegion table (or wherever the graphics driver can find it).</li>
</ol>1. is already done (I extracted small subset of the functions from INTEL GPU tools here):<br><a href="https://github.com/ZoranStojsavljevic/Video-BIOS-Table-parser-assembler">https://github.com/ZoranStojsavljevic/Video-BIOS-Table-parser-assembler</a><br><br></div>So, volunteers needed (I abandoned long time ago this effort in favour of YOCTO Project, Linux and Hypervisors & Virtual Machines handling). ;-)<br><br></div>Best Regards,<br></div>Zoran<br>_______<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 16, 2018 at 10:44 AM, Nico Huber <span dir="ltr"><<a href="mailto:nico.h@gmx.de" target="_blank">nico.h@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 16.04.2018 08:44, Patrick Rudolph wrote:<br>
> On 2018-04-15 11:30 PM, Nico Huber wrote:<br>
>> On 15.04.2018 17:12, Patrick Rudolph wrote:<br>
>>> On Sun, 2018-04-15 at 13:43 +0200, Nico Huber wrote:<br>
>>>> On 15.04.2018 12:48, Patrick Rudolph wrote:<br>
>>>>> On Thu, 2018-04-05 at 11:34 -0500, Matt DeVillier wrote:<br>
>>>>>> On Thu, Apr 5, 2018 at 11:29 AM, Nico Huber <<a href="mailto:nico.h@gmx.de">nico.h@gmx.de</a>> wrote:<br>
>>>>>>> On 05.04.2018 18:15, Matt DeVillier wrote:<br>
>>>>>>>> my instinct is to put it in the 3rd party blobs repo, since it's added to<br>
>>>>>>>> the CBFS w/o modification (ie, is treated like a blob), unlike the SPD hex<br>
>>>>>>>> files which are selectively ordered and assembled into the spd.bin (ie,<br>
>>>>>>>> treated as source).<br>
>>>>><br>
>>>>> I would like to see them in 3rd party repo, as we don't process them,<br>
>>>>> as Matt pointed out.<br>
>>>>><br>
>>>>>>> Files are concatenated, I don't see how this is treating sth. as<br>
>>>>>>> source.<br>
>>>>>>><br>
>>>>><br>
>>>>> They are changed from ASCII/text to binary format, so yes it's a source<br>
>>>>> file.<br>
>>>><br>
>>>> lol. I had that discussion before, and no: hexdumping something doesn't<br>
>>>> make it source (code).<br>
>>>><br>
>>>> Is this really where you want to draw the line? can I put my ME firmware<br>
>>>> into the main repo too if I hexdump it?<br>
>>>><br>
>>>> Btw. there is no reason to have SPDs as hex. Should we move them to<br>
>>>> 3rdparty/blobs too?<br>
>>>><br>
>>> For SPDs: No. As you can't extract them from vendor image, can you ?<br>
>><br>
>> Sure I can, in some cases even with cbfstool.<br>
>><br>
>>><br>
>>> For VBT: Why not. A user is free to choose to use the blob from blobs<br>
>>> repo, extract it his own from vendor image, use a VGA option ROM or use<br>
>>> the fake VBT mechanism.<br>
>><br>
>> Yeah, same when we add the VBT to the main repo.<br>
>><br>
>>><br>
>>> The benefit of having it in blobs repo is that it increases compability<br>
>>> and user friendliness. Just tick the Kconfig option, done.<br>
>><br>
>> Not true, you'd also have to tick USE_BLOBS (and wonder why it's neces-<br>
>> sary in case your platform doesn't need real (code) blobs). The benefit<br>
>> of having it in the main repo is that it increases sanity and user-<br>
>> friendliness. Just leave the default, done.<br>
>><br>
> I guess the solution is simple. Let's not call VBT a BLOB.<br>
<br>
</div></div>Yes. Sorry, I thought we already agreed on that. Now that I looked back,<br>
nobody wrote it down literally yet (in this thread).<br>
<span class=""><br>
> 1) It's not that large ~3-7KiB in times of mobile devices that have<br>
> multiple GiB of storage.<br>
> 2) In coreboot BLOB is considered to contain code. VBT is only data.<br>
> 3) One could argue that it's basically a key value file, where the keys<br>
> are predefined through VBT version and section IDs. Such a file is<br>
> called configuration file.<br>
> <br>
> If it's a configuration file, it should *not* be placed in blobs repo.<br>
> We should also update the Kconfig option USE_BLOBS and explain that it<br>
> is only for files that contain executable code. It's not clear for me<br>
> reading the current help message.<br>
<br>
</span>Yes, we really should make that explicit. It's also how the term blob is<br>
generally used wrt. software [1].<br>
<br>
[1] <a href="https://en.wikipedia.org/wiki/Binary_blob" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/<wbr>Binary_blob</a><br>
<div class="HOEnZb"><div class="h5"><br>
-- <br>
coreboot mailing list: <a href="mailto:coreboot@coreboot.org">coreboot@coreboot.org</a><br>
<a href="https://mail.coreboot.org/mailman/listinfo/coreboot" rel="noreferrer" target="_blank">https://mail.coreboot.org/<wbr>mailman/listinfo/coreboot</a><br>
</div></div></blockquote></div><br></div>