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@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
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.
Alex
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 for a binary other than feeding a blob. And don't like the idea to add another blob to cbfs just to feed another blob. But actually I don't care much about the blob case.
What I care about is that we shouldn't serialize in the first place if we can avoid it. Even if we don't serialize at runtime but use a binary, we'd still waste runtime cycles deserializing later.
Nico
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), we don't.
Even if we don't serialize at runtime but use a binary, we'd still waste runtime cycles deserializing later.
Alex
-
Alex G. -
Nico Huber