EPIA-M SPD progress

[Eric W. Biederman]

Dave Ashley <linuxbios at xdr.com> writes:

> I used the freebios/util/scanspd code as a starting point and found out
> the DDR ram is at slot 0x50 and can be accessed through standard SMBus reads
> at io ports 0x500+. A dump of my working eeprom is this:
> 
> 128 8 7 12 10 1 64 0 4 117 117 0 128 8 0 1
> 14 4 12 1 2 32 0 160 117 0 0 80 60 80 45 32
> 144 144 80 80 0 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 156
> Then 0's.
> 
> These are read using
> int i;
> unsigned char val;
> smbus_wait_until_ready();
> 	for(i=0;i<64;++i)
> 	{
> 		smbus_read_byte(0x50,i,&val);
> 		printf("%d%c",val, (i&15)==15 ? '\n' : ' ');
> 	}
> 
> The southbridge vt8235 code sets 1106:3177 RxD1 + RxD2 in its misc_setup.inc.
> So standard smbus reads should be available at dram init time.
> 
> Probe vs SPD discussion: I think the question is which produces a better
> result, regardless of complexity. Probing seems to have disadvantages in
> that it can't know how to set timing amounts, signal levels, or clock delays.
> It would only allow you to figure out the right column bit size I expect.
> What disadvantages does SPD have other than it is more complex? Wouldn't it
> let you then be able to correctly use any DDR module you want?

SPD is required for DDR SDRAM because there are no universally safe timings,
that will work with all DIMMS.  Universally safe timings existed with SDRAM.

As for SPD information being buggy.  Yes vendors can put the wrong labels on
their products.  If someone cares you can usually write the SPD just as easily
as you can read from it, so you can fix the bad SPD data.

Since SPD usage is mandatory for DDR SDRAM it is usually supported.

Eric