On Friday, October 23, 2015, Aaron Durbin <adurbin@google.com javascript:_e(%7B%7D,'cvml','adurbin@google.com');> wrote:
On Fri, Oct 23, 2015 at 10:33 AM, Peter Stuge peter@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@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot