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.
Regards, Carl-Daniel