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

Marc Jones marc.jones at amd.com
Wed Feb 27 17:55:54 CET 2008



ron minnich wrote:
> On Wed, Feb 27, 2008 at 3:28 AM, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006 at gmx.net> 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.
> 
> ron
> 

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.


Marc










-- 
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:Marc.Jones at amd.com
http://www.amd.com/embeddedprocessors





More information about the coreboot mailing list