Re: [coreboot] about Ivy Bridge CPU with QM67 PCH

Hi, On Sun, Oct 18, 2015 at 06:44:09PM +0200, Peter Stuge wrote: > Hi, > > Iru Cai wrote: > > I've been testing the Lenovo T420 port recently, and now I can > > install an Ivy Bridge processor and run fine on Linux(except some > > thermal issues). > > That's pretty nice I think. > > > >

[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

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

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:

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

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

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

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

[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

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

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

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

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

Re: [coreboot] Broadwell IGD (on Auron_Paine)

On 10/19/2015 09:15 PM, Stefan Reinauer wrote: > it seems that the refcode binary was not running. Can you verify that > it was part of the image and gets executed? Of course, good find. The reference code blob was actually in the CBFS but unfortunately the code to run it was disabled if no such

Re: [coreboot] Broadwell IGD (on Auron_Paine)

On 10/23/2015 02:44 PM, Georg Wicherski wrote: > There is one remaining issue, when using GRUB2 as payload and using the > at_keyboard terminal_input, the machine resets. The last debug print I > can see from GRUB2 is from term/at_keyboard.c:367 with current_set=0, so > I suppose the crasher is

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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),

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

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.

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

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