I'd vote for not checking binaries into the coreboot source tree at all. Personally, I'd like to get rid of the vbt binaries and have a tool to compile them as well. My understanding was that there wasn't documentation for the VBT fields, but it seems that maybe this is no longer the case. [1]
In general I agree, but it seems hard to get authoritative sources on the precise format, even for SPD dumps - that ought to be standardized but get repurposed in lots of "wonderful" ways by memory reference code. As far as we know, the "spec" to these files is the reference code, and that's not public.
Some of the SPD tools we use on newer chipsets (for lp4x?) may come close to that. In which case: why ship hex dumps or binaries at all?
As far as vendors adding custom flags, I don't see how binary vs text solves any problem there.
The transition here removes the hex-to-bin translation that's been fragile. Michael offers a patch that fixes things for him - that I'm relatively sure breaks building that part of the tree on other UNIX systems, since I vaguely remember having had these issues myself. My guess would be Solaris but it might be some odd BSD as well.
The text files we ship are plain hex dumps. They don't add anything of value, do they? So why should we pretend that they're "source" and make our live miserable?
My proposal is to get this in to remove the pain point that this is dealing with (the fragile hex-to-bin translation) and whoever is motivated to do so looks into providing a higher level description for these files and translating things to that, removing the opaque datasets we have (no matter the format) from the tree.
To view, visit change 44775. To unsubscribe, or for help writing mail filters, visit settings.