coreboot October 2015

coreboot@coreboot.org

44 participants
137 discussions

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

23 Oct '15

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 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 specific assembler or romcc. Would you distribute that as a binary too? Nico

3 2

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

23 Oct '15

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 can just put the data in a struct and never use binaries. 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! And if we're going to write a tool, it should work the other way around: deserializing an SPD binary, generating the code to fill the struct. Nico

2 1

Re: [coreboot] SPD binaries in coreboot
by Patrick Georgi 23 Oct '15

23 Oct '15

2015-10-23 18:32 GMT+02:00 Martin Roth <gaumless(a)gmail.com>: > 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 fields to a text file > where they can then be edited. Then it could read the text file and > generate a new SPD. > > At that point, it doesn't much matter what language it's written in - > it's not in the critical build path. Sounds good to me. I wonder if a daring soul (with java experience) could extend the gerrit diff viewer, too ;-) > Or we could store both binary and text and just use the binary at > build time. This allows for ease of review and ease of use. That's quickly misleading because people look at one file while the code uses another. 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

1 0

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

23 Oct '15

> 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 them every time. They change, but infrequently. Then we need a better tool. It would be really nice to have a tool to update the binaries in a reasonable way. Using a hex editor on the binary or updating hex values in a table are just as bad as far as I'm concerned. The hex value text file is just easier to review, but you still have to go to the JEDEC specs to know what the heck just changed. 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 fields to a text file where they can then be edited. Then it could read the text file and generate a new SPD. At that point, it doesn't much matter what language it's written in - it's not in the critical build path. I think Ron volunteered to write it if we use go. :) Alternatively, the text files could be stored as text and generated every time, but this puts the tool back in the build path and forces constraints on the language. Back to writing it in c? Or we could store both binary and text and just use the binary at build time. This allows for ease of review and ease of use. Martin

1 0

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

23 Oct '15

Patrick Georgi wrote: > 2015-10-23 17:48 GMT+02:00 Peter Stuge <peter(a)stuge.se>: > > 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 that. RAM is just as much the mainboard as the CPU/SOC is. (Not at all.) We have cpu and soc directories for good reason. //Peter

2 1

SPD binaries in coreboot
by Duncan Laurie 23 Oct '15

23 Oct '15

On Friday, October 23, 2015, Aaron Durbin <adurbin(a)google.com <javascript:_e(%7B%7D,'cvml','adurbin(a)google.com');>> wrote: > On Fri, Oct 23, 2015 at 10:33 AM, Peter Stuge <peter(a)stuge.se> 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 create a tool for this process I think we can find a better > > "source" format than hex files. Someone needs to take a look at the > > JEDEC standard and think of what might be suitable. > > > > > >> or we could ship SPD data as binary from the start > > > > I am actually strongly in favor of this approach. Converting SPD data > > from human readable to machine readable is an orthogonal problem to > > fixing the structure of our codebase, and there is no reason not to > > solve the structural problem without first having to invent a new > > data format. > > > > > >> 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?) > > > > 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 from the > memory manufacturers. > > There is a format but it's kind of a mess. On the one hand it would be nice to be able to define the memory by human readable geometry and timing for when we only get a datasheet and have to craft the DPS, but this is hopefully a rare case. > > > >> 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. > > The issue is that spds are for dimms while soldered down dram aren't > dimms. The spds provide the illusion of an actual dimm to the memory > training code which needs specific values. And because of this those > files need to be edited at times because of errors. > > This is why we went from binary firms to hex in the first place, it is important to be able to easily edit and review changes. -duncan > FWIW, LPDDR has the ability to be queried on the command bus so these > constructs should go away over time. > > > > > > > Unblobing SPD files is an excellent entry-level project which we > > could keep on shelf. Maybe for next GSoC.. > > > > Fixing structure is more important IMO and shouldn't need to block on > that. > > What's the specific structural gripe you have? The snippet of > duplicated Makefile code? > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot >

1 0

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

23 Oct '15

We'll agree to disagree :-) ron On Fri, Oct 23, 2015 at 8:55 AM Patrick Georgi <pgeorgi(a)google.com> wrote: > 2015-10-23 17:53 GMT+02:00 ron minnich <rminnich(a)gmail.com>: > > 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. 19, 20354 Hamburg > Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: > Hamburg > Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle >

1 0

Re: [coreboot] SPD binaries in coreboot
by Patrick Georgi 23 Oct '15

23 Oct '15

2015-10-23 17:53 GMT+02:00 ron minnich <rminnich(a)gmail.com>: > 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. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

1 0

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

23 Oct '15

On Fri, Oct 23, 2015 at 8:39 AM Patrick Georgi <pgeorgi(a)google.com> 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 they can't run go) > > Sorry, but no. > > Actually the idea crossed my mind because I just saw a different tool hit the tree yesterday that was written in ... guess what language? I would have accepted the 'go is not supported' argument a year ago. Now? It's everywhere. But, ok, ship binaries. I guess we'll grow the blobs. ron

1 0

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

23 Oct '15

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 from the > memory manufacturers. Nod, then we would be creating the format. > The issue is that spds are for dimms while soldered down dram aren't > dimms. The spds provide the illusion of an actual dimm to the memory > training code which needs specific values. And because of this those > files need to be edited at times because of errors. Right, "accidental review" as these data sets pass by humans in the review process is a good reason for a text-based format. Editing, well, whether I edit a hex dump or use hexedit to edit a binary really doesn't make a big difference - in which case I strongly favor requiring developers who make edits to have more tooling, over requiring new tooling at build time. > FWIW, LPDDR has the ability to be queried on the command bus so > these constructs should go away over time. Old boards stay in the tree. > > Fixing structure is more important IMO and shouldn't need to block on that. > > What's the specific structural gripe you have? The snippet of > duplicated Makefile code? Code and data in mainboard directories for components which are not the mainboard. //Peter

2 1

← Newer
1
...
4
5
6
7
8
9
10
...
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