[coreboot] SPD binaries in coreboot

[Aaron Durbin]

On Fri, Oct 23, 2015 at 2:43 PM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:
> On 23.10.2015 21:15, Martin Roth wrote:
>> 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.
>
> Now that would be a nice way to combine the benefits of diffable source
> and no-tool builds.
>
> Ron, is that solution is acceptable to you?
>
> Side note: There is a tool called decode-dimms which can be fed with
> binary SPD dumps. It decodes everything in the SPD and could serve as a
> nice way to verify the output of Ron's magic SPD tool.

Do people realize these binaries sit in cbfs? Are we going to compile
random c files into object files then objcopy them? Then add to cbfs?
Also, the SPD format is quite silly as it is w.r.t. values crossing
multiple fields in a byte, etc. There's not really a good way to
encode that in a C struct.


>
>
> Regards,
> Carl-Daniel
>
>> 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
>>>>>>
>