[coreboot] SPD binaries in coreboot

[Martin Roth]

> So, is there a third option that I'm missing? Other opinions?
>> > The third option would be a plain text format which is easy to parse
>> > but still covers the spec well.

I'd say that we should store the SPDs as binaries - these are easy to
use at build time, and there's no reason to build them every time.
They change, but infrequently.  Then we need a better tool.

It would be really nice to have a tool to update the binaries in a
reasonable way.  Using a hex editor on the binary or updating hex
values in a table are just as bad as far as I'm concerned.  The hex
value text file is just easier to review, but you still have to go to
the JEDEC specs to know what the heck just changed.

 It would be really handy to have a tool that would read in a binary
SPD, and allow you to edit the JEDEC values.  It should understand all
of the different JEDEC SPD specs.  The easiest way would be to
interpret the binary SPD and output all the fields to a text file
where they can then be edited.  Then it could read the text file and
generate a new SPD.

At that point, it doesn't much matter what language it's written in -
it's not in the critical build path.  I think Ron volunteered to write
it if we use go.  :)



Alternatively, the text files could be stored as text and generated
every time, but this puts the tool back in the build path and forces
constraints on the language.  Back to writing it in c?
Or we could store both binary and text and just use the binary at
build time.  This allows for ease of review and ease of use.

Martin