[U-Boot-Users] 83xx SPD_EEPROM DDR2 Issues

[Russell McGuire]

All,

Correct, I did some math and they almost work out for DDR1 values
However into DDR2 clocks speeds it gets increasingly bad.

Going through the SPD tables I have found, it looks like there is not a
mathematical way to convert those values, as they are in nanoseconds but
only some are actually linear. Some values like 0x3D for spd->clk_cycle
can't be converted using a formula, easy enough to put into a case
statement. 0x3D is intended to be 3.75ns and 0x30 is 3.00ns. So 0x0D would
be 0.75ns? Doesn't work in my book. However 0x25 is a nice easy clear 2.5ns.
Whomever put Hex values to represent decimal numbers probably chose a poor
idea. I am just hoping that most RAM isn't putting 'exact' values in SPD
tables, but rather an industry standard value that is going to work with the
intended SODIMM / DIMM, our code should be using lookup tables if so, not
math formulas. 

I have already written a flat case statement with correct values. Easy to
see now why it was breaking, as the CAS latencies were all hosed over for
the faster memory.

-Russ

-----Original Message-----
From: Bruce_Leonard at selinc.com [mailto:Bruce_Leonard at selinc.com] 
Sent: Tuesday, June 03, 2008 5:34 PM
To: rmcguire at videopresence.com
Cc: 'David Hawkins'; 'Steve Hensley'; u-boot-users at lists.sourceforge.net
Subject: RE: [U-Boot-Users] 83xx SPD_EEPROM DDR2 Issues

"Russell McGuire" <rmcguire at videopresence.com> wrote on 06/03/2008 
04:15:55 PM:

> 
> I haven't gone through the rest yet, but most likely if we want to keep 
SPD
> working for DDR2, we'll have to add the DDR2 definitions SPD into the 
code,
> as it looks like the DDR2 port is only partially complete.
> 
> -Russ
> 

Russ,

That's pretty much jives with my recollection.  One other thing that leaps 
to mind was the calculation for max_bus_clk.  I hand cranked through that 
with a high clock rate as input and due to rounding errors got a bogus 
value.  I don't remember the details right off the top of my head but it 
seems to me that the net result was I started with a bus clock that should 
have landed max_data_rate in one of those if-if-else-if cases, but it 
didn't.  So I think that whole function (and especially the max_bus_clk 
calculation) needs to be gone through.  Good luck.  I'd help but I have my 
own issues with MTD :(.

Bruce