On Fri, Oct 23, 2015 at 2:43 PM, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2...@gmx.net> wrote: > On 23.10.2015 21:15, Martin Roth wrote: >> I like what I understand Nico's proposal to be: Store the SPD data as >> a c struct with all of the different JEDEC fields broken out. it >> would relatively trivial to compile this into an SPD binary, or it can >> be used in whatever other fashion is desired. A tool to convert from >> a binary SPD to the structure file would be desirable to help the >> transition, but it's out of the build path. >> >> I believe this satisfies all the requirements: >> - It's easy to review differences. >> - It can be be built with no new tools. >> - The fields are broken out, so you can actually tell what you're doing. > > Now that would be a nice way to combine the benefits of diffable source > and no-tool builds. > > Ron, is that solution is acceptable to you? > > Side note: There is a tool called decode-dimms which can be fed with > binary SPD dumps. It decodes everything in the SPD and could serve as a > nice way to verify the output of Ron's magic SPD tool.
Do people realize these binaries sit in cbfs? Are we going to compile random c files into object files then objcopy them? Then add to cbfs? Also, the SPD format is quite silly as it is w.r.t. values crossing multiple fields in a byte, etc. There's not really a good way to encode that in a C struct. > > > Regards, > Carl-Daniel > >> On Fri, Oct 23, 2015 at 12:44 PM, ron minnich <rminn...@gmail.com> wrote: >>> Aaron is my hero :-) >>> >>> ron >>> >>> On Fri, Oct 23, 2015 at 11:35 AM Aaron Durbin <adur...@google.com> wrote: >>>> This one's for Ron. >>>> >>>> On Fri, Oct 23, 2015 at 10:32 AM, ron minnich <rminn...@gmail.com> wrote: >>>>> Build the tool in go. It's trivial. If you have an idea how it ought to >>>>> work >>>>> I can set it up in the playground in a few minutes. >>>>> >>>>> ron >>>>> >>>>> On Fri, Oct 23, 2015 at 8:24 AM Patrick Georgi <pgeo...@google.com> >>>>> wrote: >>>>>> Hi, >>>>>> >>>>>> Some mainboards come with soldered-on memory without SPD ROM. For >>>>>> these, we carry the SPD data in coreboot. >>>>>> >>>>>> Currently, they're stored in a hexdump format that is then converted >>>>>> to binary at build time. The various mechanisms of doing so fail on >>>>>> some platform or another: >>>>>> - "echo -e -n $stuff" isn't well-liked by some shells (emits "e -n >>>>>> $stuff") >>>>>> - "printf '\x42'" isn't well-liked by some shells (or /usr/bin/printf >>>>>> tools) that don't support hexadecimal formats >>>>>> - "printf '\0377'" isn't well-liked by some non-conforming, but >>>>>> existing >>>>>> shells >>>>>> - xxd -rg1 $file > $file.bin requires xxd, which comes with vim and >>>>>> may just not exist >>>>>> >>>>>> I see essentially two ways out of this, before we can start reducing >>>>>> duplication across the tree in that area: >>>>>> We could build our own tool to parse hex files and dump binary, or we >>>>>> could ship SPD data as binary from the start (and only have to >>>>>> concatenate them). >>>>>> >>>>>> 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?), but looks icky at a glance because it's binary (but it's >>>>>> really just as impenetrable as the equivalent hexdump). >>>>>> >>>>>> So what do these files contain? Parameters (as in: facts) about the >>>>>> hardware's size, layout, and timing, and a bunch of vendor/model >>>>>> identifier strings. >>>>>> >>>>>> >>>>>> So, is there a third option that I'm missing? Other opinions? >>>>>> Patrick >>>>>> > -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
