[coreboot] SPD binaries in coreboot

Aaron Durbin adurbin at google.com
Fri Oct 23 17:39:32 CEST 2015

On Fri, Oct 23, 2015 at 10:33 AM, Peter Stuge <peter at stuge.se> wrote:
> Patrick Georgi wrote:
>> we carry the SPD data in coreboot.
> ..
>> Currently, they're stored in a hexdump format
> ..
>> I see essentially two ways out of this
> ..
>> We could build our own tool to parse hex files and dump binary,
> If we create a tool for this process I think we can find a better
> "source" format than hex files. Someone needs to take a look at the
> JEDEC standard and think of what might be suitable.
>> or we could ship SPD data as binary from the start
> I am actually strongly in favor of this approach. Converting SPD data
> from human readable to machine readable is an orthogonal problem to
> fixing the structure of our codebase, and there is no reason not to
> solve the structural problem without first having to invent a new
> data format.
>> 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?)
> I guess JEDEC does have a structured format. Maybe it's XML or JSON. :)

I don't believe JEDEC has a format. And the one thing missing here is
that there is no standard way of distributing these files. In fact,
I've mainly seen spreadsheets as a form of distribution from the
memory manufacturers.

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

The issue is that spds are for dimms while soldered down dram aren't
dimms. The spds provide the illusion of an actual dimm to the memory
training code which needs specific values. And because of this those
files need to be edited at times because of errors.

FWIW, LPDDR has the ability to be queried on the command bus so these
constructs should go away over time.

> Unblobing SPD files is an excellent entry-level project which we
> could keep on shelf. Maybe for next GSoC..
> Fixing structure is more important IMO and shouldn't need to block on that.

What's the specific structural gripe you have? The snippet of
duplicated Makefile code?

More information about the coreboot mailing list