On Friday, October 23, 2015, Aaron Durbin <<a href="javascript:_e(%7B%7D,'cvml','adurbin@google.com');" target="_blank">adurbin@google.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Oct 23, 2015 at 10:33 AM, Peter Stuge <<a>peter@stuge.se</a>> wrote:<br>
> Patrick Georgi wrote:<br>
>> we carry the SPD data in coreboot.<br>
> ..<br>
>> Currently, they're stored in a hexdump format<br>
> ..<br>
>> I see essentially two ways out of this<br>
> ..<br>
>> We could build our own tool to parse hex files and dump binary,<br>
><br>
> If we create a tool for this process I think we can find a better<br>
> "source" format than hex files. Someone needs to take a look at the<br>
> JEDEC standard and think of what might be suitable.<br>
><br>
><br>
>> or we could ship SPD data as binary from the start<br>
><br>
> I am actually strongly in favor of this approach. Converting SPD data<br>
> from human readable to machine readable is an orthogonal problem to<br>
> fixing the structure of our codebase, and there is no reason not to<br>
> solve the structural problem without first having to invent a new<br>
> data format.<br>
><br>
><br>
>> The second option has the appeal of being much simpler (and there<br>
>> isn't really a "preferred form" for editing SPD data that I'm aware of<br>
>> - is there?)<br>
><br>
> I guess JEDEC does have a structured format. Maybe it's XML or JSON. :)<br>
><br>
<br>
I don't believe JEDEC has a format. And the one thing missing here is<br>
that there is no standard way of distributing these files. In fact,<br>
I've mainly seen spreadsheets as a form of distribution from the<br>
memory manufacturers.<br>
<br></blockquote><div><br></div><div>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. <span></span></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
>> So, is there a third option that I'm missing? Other opinions?<br>
><br>
> The third option would be a plain text format which is easy to parse<br>
> but still covers the spec well.<br>
<br>
The issue is that spds are for dimms while soldered down dram aren't<br>
dimms. The spds provide the illusion of an actual dimm to the memory<br>
training code which needs specific values. And because of this those<br>
files need to be edited at times because of errors.<br>
<br></blockquote><div><br></div><div>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.</div><div><br></div><div>-duncan </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
FWIW, LPDDR has the ability to be queried on the command bus so these<br>
constructs should go away over time.<br>
<br>
><br>
><br>
> Unblobing SPD files is an excellent entry-level project which we<br>
> could keep on shelf. Maybe for next GSoC..<br>
><br>
> Fixing structure is more important IMO and shouldn't need to block on that.<br>
<br>
What's the specific structural gripe you have? The snippet of<br>
duplicated Makefile code?<br>
<br>
--<br>
coreboot mailing list: <a>coreboot@coreboot.org</a><br>
<a href="http://www.coreboot.org/mailman/listinfo/coreboot" target="_blank">http://www.coreboot.org/mailman/listinfo/coreboot</a><br>
</blockquote>