[coreboot] SPD sanity check

[Tom Sylla]

On Fri, Oct 2, 2009 at 12:53 PM, ron minnich <rminnich at gmail.com> wrote:
> On Fri, Oct 2, 2009 at 4:53 AM, Carl-Daniel Hailfinger
> The lm_sensors tools are handy when everything is working fine.
> They're not when things are not. In my case, things are not and,
> sadly, the tools are largely useless -- I'm going to have to write my
> own.

I have a collection of DIMMs I use for testing platforms, and I keep
SPD dumps for each DIMM handy. Then I can look in my list of eeprom
dumps to find the aprticualr specs I need to test easily. I don't
really use any tools, Appendix A and hexdump are all you need.

> A further problem is the lm_sensors guys don't always understand Unix
> (a common problem nowadays :-) or decode-dimms would be two tools:
> 1. get_spd
> 2. decode_spd

"get_spd" is 'modprobe eeprom; cp /sys/bus/i2c/devices/0-0054/eeprom ./eeprom'


Regarding your other mail, I think you did not decode it carefully
enough. It looks ok to me, I even see this string:

4D 33 20 39 33 54 33 32 35 33 46 5A 30 2D 43 43  M3 93T3253FZ0-CC

and google says 93T3253FZ0 is a Samsung DDR2, registered, ECC DIMM

You said offset 2 is fundamental memory type, which is true. '08' is
certainly valid though, I see 08 as "DDR II SDRAM" in appendix A (is
yours the latest?)

Here are the first lines of the dumps of some of the DIMMs in my collection:

[tsylla at x DDR2]$ for i in `ls`; do hexdump -C $i/eeprom|grep 00000000; done
00000000  80 08 08 0e 0a 60 48 00  05 25 40 06 82 08 08 00  |.....`H..%@.....|
00000000  80 08 08 0d 0b 60 48 00  05 3d 50 02 82 04 04 00  |.....`H..=P.....|
00000000  80 08 08 0e 0a 61 48 00  05 25 40 06 82 08 08 00  |.....aH..%@.....|


They are pretty consistent with yours.

Please get the latest JEDEC specs and decode your dump more carefully;
I think you will find it makes sense. (I checked for you that the
checksum at 3f is correct)



As a side rant, why does do Linux and coreboot insist on referring to
SMBus addresses shifted right byte one bit? They are 7 bits long, and
should be *left* justified in the byte. Take a look at every SMBus
controller, and you will see that is how the register is laid out,
address is the top 7 bits, and the bottom bit is read/write. Take a
look at the SMBus drivers in coreboot, and you will see the access
function doing something like: dimm_address << 1 | READ_WRITE. It just
seems silly to me :)

Tom