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
2015-10-23 18:59 GMT+02:00 Nico Huber nico.h@gmx.de:
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/northbridge/amd/agesa/common/common.c
It's the go-to workaround when you have code that expects an SPD ROM to be around and you don't have it.
Patrick