[coreboot] SPD binaries in coreboot

[Alex G.]

On 10/23/2015 12:54 PM, Aaron Durbin wrote:
> 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.

Nobody said "encode" that in a C struct. The proposal, AFAIU is to have
dynamic code that serializes/deserializes from struct to SPD. Last time
someone tried to compile a C struct into a binary SPD, it didn't turn
out too well (and it's probably why we don't do it).

Not that I agree with the proposal, but we already have deserialization
code in the tree. It's not a stretch to write the inverse operation.

Alex

> 
>>
>>
>> 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
>>>>>>>
>>
>