[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