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