On Fri, Oct 2, 2009 at 12:53 PM, ron minnich rminnich@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:
- get_spd
- 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@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