Re: [coreboot] SPD binaries in coreboot

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 e

Re: [coreboot] SPD binaries in coreboot

On 10/23/2015 04:22 PM, Nico Huber wrote: > What I care about is that we shouldn't serialize in the first place if > we can avoid it. That makes sense, assuming we have access to internal data representation of the raminit code. For FSP and MRC (the biggest consumers of on-board SPD-less DRAM), w

Re: [coreboot] SPD binaries in coreboot

On 24.10.2015 00:37, Alex G. wrote: > On 10/23/2015 01:59 PM, Nico Huber wrote: >> Thanks for the support. One remark: I would really prefer serializing >> during runtime > > Why waste runtime cycles (and code space) doing something you can > already do at build time? I don't see a requirement fo

Re: [coreboot] SPD binaries in coreboot

On 10/23/2015 01:59 PM, Nico Huber wrote: > Thanks for the support. One remark: I would really prefer serializing > during runtime Why waste runtime cycles (and code space) doing something you can already do at build time? > over compiling a C struct to a binary. We're not doing that either. Al

Re: [coreboot] SPD binaries in coreboot

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'

Re: [coreboot] SPD binaries in coreboot

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

Re: [coreboot] SPD binaries in coreboot

On 23.10.2015 21:54, Aaron Durbin wrote: > On Fri, Oct 23, 2015 at 2:43 PM, Carl-Daniel Hailfinger > 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 >>>

Re: [coreboot] SPD binaries in coreboot

On Fri, Oct 23, 2015 at 2:43 PM, Carl-Daniel Hailfinger 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

Re: [coreboot] SPD binaries in coreboot

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 -- coreboo

Re: [coreboot] SPD binaries in coreboot

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

Re: [coreboot] SPD binaries in coreboot

Aaron Durbin wrote: > This one's for Ron. En guard! $ wc -c -l spd.* 81 1462 spd.c 100 1629 spd.go $ //Peter #include #include #include static unsigned char spd[256]; int readhex(const char *filename) { int pos = 0, i, end; unsigned int n; char buf[128], *hex;

Re: [coreboot] SPD binaries in coreboot

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 st

Re: [coreboot] SPD binaries in coreboot

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

Re: [coreboot] SPD binaries in coreboot

This one's for Ron. On Fri, Oct 23, 2015 at 10:32 AM, ron minnich 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 wrote: >> >> Hi, >> >> Some mai

Re: [coreboot] SPD binaries in coreboot

Hi all, On 23.10.2015 17:23, Patrick Georgi wrote: > I see essentially two ways out of this, before we can start reducing > duplication across the tree in that area: > [...] Neither of your options tackles the real problem. That is: We have interfaces that use binary SPD data. It's just stupid. We

Re: [coreboot] SPD binaries in coreboot

I don't think it's really very similar at all. The bootblock output can change drastically based on Kconfig settings. Am I missing something? On Fri, Oct 23, 2015 at 10:59 AM, Nico Huber wrote: > On 23.10.2015 18:32, Martin Roth wrote: >>> So, is there a third option that I'm missing? Other opi

Re: [coreboot] SPD binaries in coreboot

2015-10-23 18:59 GMT+02:00 Nico Huber : >> I'd say that we should store the SPDs as binaries - these are easy to >> use at build time, and there's no reason to build them every time. >> They change, but infrequently. Then we need a better tool. > That would also apply to a bootblock that needs a s

Re: [coreboot] SPD binaries in coreboot

2015-10-23 18:59 GMT+02:00 Nico Huber : > Well, we have raminit code that we can not fix, i.e. the BLOBs. So, if > anything we should write serialization that takes a struct and generates > the binary during runtime. Yeah, more BLOB wrapping code! Even source AGESA (SourcePI?) uses spd.bin, see src

Re: [coreboot] SPD binaries in coreboot

On 23.10.2015 18:32, Martin Roth wrote: >> 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. > > I'd say that we should store the SPDs as binaries - these are easy to > use at

Re: [coreboot] SPD binaries in coreboot

2015-10-23 18:32 GMT+02:00 Martin Roth : > It would be really handy to have a tool that would read in a binary > SPD, and allow you to edit the JEDEC values. It should understand all > of the different JEDEC SPD specs. The easiest way would be to > interpret the binary SPD and output all the fie

Re: [coreboot] SPD binaries in coreboot

> 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. I'd say that we should store the SPDs as binaries - these are easy to use at build time, and there's no reason to build the

Re: [coreboot] SPD binaries in coreboot

On Fri, Oct 23, 2015 at 10:57 AM, Peter Stuge wrote: > Patrick Georgi wrote: >> 2015-10-23 17:48 GMT+02:00 Peter Stuge : >> > Code and data in mainboard directories for components which are not >> > the mainboard. >> In this case, they _are_ "the mainboard" just like magic numbers for >> USB trace

[coreboot] SPD binaries in coreboot

On Friday, October 23, 2015, Aaron Durbin > wrote: > On Fri, Oct 23, 2015 at 10:33 AM, Peter Stuge 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 c

Re: [coreboot] SPD binaries in coreboot

Patrick Georgi wrote: > 2015-10-23 17:48 GMT+02:00 Peter Stuge : > > Code and data in mainboard directories for components which are not > > the mainboard. > In this case, they _are_ "the mainboard" just like magic numbers for > USB trace lengths are. > That stuff describes soldered-on components,

Re: [coreboot] SPD binaries in coreboot

We'll agree to disagree :-) ron On Fri, Oct 23, 2015 at 8:55 AM Patrick Georgi wrote: > 2015-10-23 17:53 GMT+02:00 ron minnich : > > Actually the idea crossed my mind because I just saw a different tool hit > > the tree yesterday that was written in ... guess what language? > That tool (just li

Re: [coreboot] SPD binaries in coreboot

2015-10-23 17:53 GMT+02:00 ron minnich : > Actually the idea crossed my mind because I just saw a different tool hit > the tree yesterday that was written in ... guess what language? That tool (just like autoport before it) isn't part of the build system. Patrick -- Google Germany GmbH, ABC-Str.

Re: [coreboot] SPD binaries in coreboot

On Fri, Oct 23, 2015 at 8:39 AM Patrick Georgi wrote: > It's more trivial not to have a tool in the first place. > It's also more trivial not to add a new dependency to our build process. > Especially a dependency that is lacking in portability (ie. users > can't build coreboot anymore because th

Re: [coreboot] SPD binaries in coreboot

2015-10-23 17:48 GMT+02:00 Peter Stuge : > Code and data in mainboard directories for components which are not > the mainboard. In this case, they _are_ "the mainboard" just like magic numbers for USB trace lengths are. That stuff describes soldered-on components, it can't be more "mainboard" than

Re: [coreboot] SPD binaries in coreboot

Aaron Durbin wrote: > > 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

Re: [coreboot] SPD binaries in coreboot

ron minnich wrote: > Build the tool in go. I have to disagree with that. We want to keep dependencies few and small, neither of which is really true for Go. Hammer and nail.. > It's trivial. I think that's true regardless of which tool we use. //Peter -- coreboot mailing list: coreboot@cor

Re: [coreboot] SPD binaries in coreboot

It's more trivial not to have a tool in the first place. It's also more trivial not to add a new dependency to our build process. Especially a dependency that is lacking in portability (ie. users can't build coreboot anymore because they can't run go) Sorry, but no. 2015-10-23 17:32 GMT+02:00 ron

Re: [coreboot] SPD binaries in coreboot

On Fri, Oct 23, 2015 at 10:33 AM, Peter Stuge 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

Re: [coreboot] SPD binaries in coreboot

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"

Re: [coreboot] SPD binaries in coreboot

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 wrote: > Hi, > > Some mainboards come with soldered-on memory without SPD ROM. For > these, we carry the SPD data i

[coreboot] SPD binaries in coreboot

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"