coreboot October 2015

coreboot@coreboot.org

44 participants
137 discussions

Re: [coreboot] SPD binaries in coreboot
by Nico Huber 24 Oct '15

24 Oct '15

On 23.10.2015 21:54, Aaron Durbin wrote: > On Fri, Oct 23, 2015 at 2:43 PM, Carl-Daniel Hailfinger > <c-d.hailfinger.devel.2006(a)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. Thanks for the support. One remark: I would really prefer serializing during runtime over compiling a C struct to a binary. The latter could cause much bit-field headache given the SPD format. >>> >>> 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? Yes, they do _currently_. We don't have to keep it that way. > Are we going to compile > random c files into object files then objcopy them? Then add to cbfs? I wouldn't like that either. > 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. We don't have to encode the binary SPD format in the C struct. We can just use a C struct to store the SPD information. Like we used C structs before we knew bit fields (wasn't that a good time?). If we encounter a not so beautiful, unchangeable interface that needs the information as binary SPD, well, we could decide to be gracious and serialize the in- formation. Nico

2 3

Re: [coreboot] SPD binaries in coreboot
by Alex G. 24 Oct '15

24 Oct '15

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 <rminnich(a)gmail.com> wrote: >>>> Aaron is my hero :-) >>>> >>>> ron >>>> >>>> On Fri, Oct 23, 2015 at 11:35 AM Aaron Durbin <adurbin(a)google.com> wrote: >>>>> This one's for Ron. >>>>> >>>>> On Fri, Oct 23, 2015 at 10:32 AM, ron minnich <rminnich(a)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 <pgeorgi(a)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 >>>>>>> >> >

1 0

Re: [coreboot] SPD binaries in coreboot
by Alex G. 24 Oct '15

24 Oct '15

On 10/23/2015 08:32 AM, ron minnich wrote: > Build the tool in go. Not everybody knows or wants to learn 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(a)google.com > <mailto: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(a)coreboot.org > <mailto:coreboot@coreboot.org> > http://www.coreboot.org/mailman/listinfo/coreboot > > >

1 0

Re: [coreboot] SPD binaries in coreboot
by Carl-Daniel Hailfinger 23 Oct '15

23 Oct '15

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. Regards, Carl-Daniel > On Fri, Oct 23, 2015 at 12:44 PM, ron minnich <rminnich(a)gmail.com> wrote: >> Aaron is my hero :-) >> >> ron >> >> On Fri, Oct 23, 2015 at 11:35 AM Aaron Durbin <adurbin(a)google.com> wrote: >>> This one's for Ron. >>> >>> On Fri, Oct 23, 2015 at 10:32 AM, ron minnich <rminnich(a)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 <pgeorgi(a)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 >>>>>

2 1

Re: [coreboot] SPD binaries in coreboot
by Peter Stuge 23 Oct '15

23 Oct '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. Yes, fun and games aside, this is definitely the way to go. Thanks Nico for showing us the forest behind all the trees. //Peter

1 0

Re: [coreboot] SPD binaries in coreboot
by Peter Stuge 23 Oct '15

23 Oct '15

Aaron Durbin wrote: > This one's for Ron. En guard! $ wc -c -l spd.* 81 1462 spd.c 100 1629 spd.go $ //Peter

1 0

Re: [coreboot] SPD binaries in coreboot
by Martin Roth 23 Oct '15

23 Oct '15

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. On Fri, Oct 23, 2015 at 12:44 PM, ron minnich <rminnich(a)gmail.com> wrote: > Aaron is my hero :-) > > ron > > On Fri, Oct 23, 2015 at 11:35 AM Aaron Durbin <adurbin(a)google.com> wrote: >> >> This one's for Ron. >> >> On Fri, Oct 23, 2015 at 10:32 AM, ron minnich <rminnich(a)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 <pgeorgi(a)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(a)coreboot.org >> >> http://www.coreboot.org/mailman/listinfo/coreboot >> > >> > >> > -- >> > coreboot mailing list: coreboot(a)coreboot.org >> > http://www.coreboot.org/mailman/listinfo/coreboot > > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] SPD binaries in coreboot
by Sheng-Liang Song 23 Oct '15

23 Oct '15

FYI: I used put spd data in a stand alone C source code so that I can edit with vi directly. unsigned char global_spd_data[256] = __attribute__ ((section("spd_data"))) { 0x??, 0x??, ... }; Note: I also put spd_data in the spd data section that is the end of my binary xloader code. I can easily edit with bvi editor too. https://en.wikipedia.org/wiki/Serial_presence_detect On Fri, Oct 23, 2015 at 11:35 AM, Aaron Durbin <adurbin(a)google.com> wrote: > This one's for Ron. > > On Fri, Oct 23, 2015 at 10:32 AM, ron minnich <rminnich(a)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 <pgeorgi(a)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(a)coreboot.org > >> http://www.coreboot.org/mailman/listinfo/coreboot > > > > > > -- > > coreboot mailing list: coreboot(a)coreboot.org > > http://www.coreboot.org/mailman/listinfo/coreboot > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > -- Sheng-Liang Song | Software Engineer | ssl(a)google.com | 650-537-5017

1 0

Re: [coreboot] SPD binaries in coreboot
by ron minnich 23 Oct '15

23 Oct '15

Aaron is my hero :-) ron On Fri, Oct 23, 2015 at 11:35 AM Aaron Durbin <adurbin(a)google.com> wrote: > This one's for Ron. > > On Fri, Oct 23, 2015 at 10:32 AM, ron minnich <rminnich(a)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 <pgeorgi(a)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(a)coreboot.org > >> http://www.coreboot.org/mailman/listinfo/coreboot > > > > > > -- > > coreboot mailing list: coreboot(a)coreboot.org > > http://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] SPD binaries in coreboot
by Aaron Durbin 23 Oct '15

23 Oct '15

This one's for Ron. On Fri, Oct 23, 2015 at 10:32 AM, ron minnich <rminnich(a)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 <pgeorgi(a)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(a)coreboot.org >> http://www.coreboot.org/mailman/listinfo/coreboot > > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
14
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot October 2015