On Fri, Oct 2, 2009 at 12:53 PM, ron minnich <rminn...@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: [tsy...@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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot