[coreboot] SPD binaries in coreboot

[Duncan Laurie]

On Friday, October 23, 2015, Aaron Durbin <adurbin at google.com
<javascript:_e(%7B%7D,'cvml','adurbin at google.com');>> wrote:

> 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.
>
>
There is a format but it's kind of a mess.  On the one hand it would be
nice to be able to define the memory by human readable geometry and timing
for when we only get a datasheet and have to craft the DPS, but this is
hopefully a rare case.



> >
> >> 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.
>
>
This is why we went from binary firms to hex in the first place, it is
important to be able to easily edit and review changes.

-duncan



> 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?
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151023/3a2858d4/attachment-0001.html>