[coreboot] SPD binaries in coreboot

[Martin Roth]

I like what I understand Nico's proposal to be: Store the SPD data as
a c struct with all of the different JEDEC fields broken out.  it
would relatively trivial to compile this into an SPD binary, or it can
be used in whatever other fashion is desired.  A tool to convert from
a binary SPD to the structure file would be desirable to help the
transition, but it's out of the build path.

I believe this satisfies all the requirements:
- It's easy to review differences.
- It can be be built with no new tools.
- The fields are broken out, so you can actually tell what you're doing.




On Fri, Oct 23, 2015 at 12:44 PM, ron minnich <rminnich at gmail.com> wrote:
> Aaron is my hero :-)
>
> ron
>
> On Fri, Oct 23, 2015 at 11:35 AM Aaron Durbin <adurbin at google.com> wrote:
>>
>> This one's for Ron.
>>
>> On Fri, Oct 23, 2015 at 10:32 AM, ron minnich <rminnich at gmail.com> wrote:
>> > Build the tool in go. It's trivial. If you have an idea how it ought to
>> > work
>> > I can set it up in the playground in a few minutes.
>> >
>> > ron
>> >
>> > On Fri, Oct 23, 2015 at 8:24 AM Patrick Georgi <pgeorgi at google.com>
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >> Some mainboards come with soldered-on memory without SPD ROM. For
>> >> these, we carry the SPD data in coreboot.
>> >>
>> >> Currently, they're stored in a hexdump format that is then converted
>> >> to binary at build time. The various mechanisms of doing so fail on
>> >> some platform or another:
>> >>  - "echo -e -n $stuff" isn't well-liked by some shells (emits "e -n
>> >> $stuff")
>> >>  - "printf '\x42'" isn't well-liked by some shells (or /usr/bin/printf
>> >> tools) that don't support hexadecimal formats
>> >>  - "printf '\0377'" isn't well-liked by some non-conforming, but
>> >> existing
>> >> shells
>> >>  - xxd -rg1 $file > $file.bin requires xxd, which comes with vim and
>> >> may just not exist
>> >>
>> >> I see essentially two ways out of this, before we can start reducing
>> >> duplication across the tree in that area:
>> >> We could build our own tool to parse hex files and dump binary, or we
>> >> could ship SPD data as binary from the start (and only have to
>> >> concatenate them).
>> >>
>> >> The second option has the appeal of being much simpler (and there
>> >> isn't really a "preferred form" for editing SPD data that I'm aware of
>> >> - is there?), but looks icky at a glance because it's binary (but it's
>> >> really just as impenetrable as the equivalent hexdump).
>> >>
>> >> So what do these files contain? Parameters (as in: facts) about the
>> >> hardware's size, layout, and timing, and a bunch of vendor/model
>> >> identifier strings.
>> >>
>> >>
>> >> So, is there a third option that I'm missing? Other opinions?
>> >> Patrick
>> >> --
>> >> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
>> >> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
>> >> Hamburg
>> >> Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
>> >>
>> >> --
>> >> coreboot mailing list: coreboot at coreboot.org
>> >> http://www.coreboot.org/mailman/listinfo/coreboot
>> >
>> >
>> > --
>> > coreboot mailing list: coreboot at coreboot.org
>> > http://www.coreboot.org/mailman/listinfo/coreboot
>
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot