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 <pgeorgi@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
--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot