[coreboot] [PATCH] v3: convert fake SPD to struct spd_entry

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Thu Feb 28 00:00:20 CET 2008

On 27.02.2008 17:55, Marc Jones wrote:
> ron minnich wrote:
>> On Wed, Feb 27, 2008 at 3:28 AM, Carl-Daniel Hailfinger wrote:
>>>  The "multiple SPD" patch is next on my list once I know whether you want

>>>  to simulate multiple independent SPD EEPROMS (for multiple RAM chips) or
>>>  multiple related SPD EEPROMS.
>> Good question!
>> I think both. One board I at least has soldered-on and DIMMs. So the
>> array might be:
>> struct dimarray { u8 dimm_address; struct spd_entry *table; int tablesize};
>> struct valid_spd_devices spd_table = { {0xa0, spd_table_onboard,
>> nelem(spd_table_onboard)}, {0xa1, NULL,}, {0,0}};
>> Note that if we go to a generic function we need to have the size in
>> the struct.
>> This starts to raise the question: is the generic function more
>> trouble that it is worth? I am now beginning to think so. What if the
>> second DIMM is an spd device?
>> There are lots of variations possible, and it may just be simpler not
>> to get too fancy.
> There are platforms with soldered-on and a dimm slot. That and the smbus 
> addressing switching in k8 is why it is in mainboard.
> As for the SPD in the dts (which I assume means in the statictree), I 
> don't think so but for very minor reasons. It would take up a bunch of 
> space in the statictree when it is only needed by initram. It would also 
> be more convoluted to access it in the statictree. If someone has a good 
> reason, I could be convinced that it should go in the dts.

Indeed, keep the SPD outside the dts if at all possible. initram is a 
piece of code which does not care about the device tree and that's good.

I'd still try to keep the functions as similar as possible between 
mainboards, but the benefit of keeping them inside 
mainboard/$vendor/$model/initram.c is huge.

By the way, the fake SPD stuff also has another rather big benefit: You 
can read out the SPD under factory BIOS and supply the values as fake 
SPD to facilitate early board bringup, especially if SMBUS is acting up.



More information about the coreboot mailing list