On 10/23/2015 12:54 PM, Aaron Durbin wrote: > 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.
Nobody said "encode" that in a C struct. The proposal, AFAIU is to have dynamic code that serializes/deserializes from struct to SPD. Last time someone tried to compile a C struct into a binary SPD, it didn't turn out too well (and it's probably why we don't do it). Not that I agree with the proposal, but we already have deserialization code in the tree. It's not a stretch to write the inverse operation. Alex > >> >> >> 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
