SPD sanity check

[ron minnich]

This looks to me like I'm mostly reading garbage from SPD -- comments anyone?

dimm 50
00: bad device: 01

dimm 51
00: bad device: 01

dimm 52
00: bad device: 01

dimm 53
00: bad device: 01

dimm 54
00: ad db de c0 01 00 00 00 01 f0 fa fa 00 00 00 d9
10: 00 00 00 00 00 00 6c 01 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

dimm 55
00: bad device: 01

dimm 56
00: bad device: 01

dimm 57
00: 80 08 08 0d 0a 60 48 00 05 50 60 02 02 08 08 00
10: 0c 04 38 00 01 00 01 50 60 50 60 3c 1e 3c 28 40
20: 35 47 15 27 3c 28 1e 00 00 37 4b 80 23 2d 0f 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 10 6b
40: ce 00 00 00 00 00 00 00 01 4d 33 20 39 33 54 33
50: 32 35 33 46 5a 30 2d 43 43 43 20 30 46 05 17 46
60: 04 cb 50 00 59 42 43 35 36 30 50 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 49 d6 06 71 16 23 33 80 30 45 52 00 07 05 ff
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
f0: 01 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

[Joseph Smith]

On 10/01/2009 08:04 PM, ron minnich wrote:
> This looks to me like I'm mostly reading garbage from SPD -- comments anyone?
>
> dimm 50
> 00: bad device: 01
>
> dimm 51
> 00: bad device: 01
>
> dimm 52
> 00: bad device: 01
>
> dimm 53
> 00: bad device: 01
>
> dimm 54
> 00: ad db de c0 01 00 00 00 01 f0 fa fa 00 00 00 d9
> 10: 00 00 00 00 00 00 6c 01 00 00 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00
> 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
> dimm 55
> 00: bad device: 01
>
> dimm 56
> 00: bad device: 01
>
> dimm 57
> 00: 80 08 08 0d 0a 60 48 00 05 50 60 02 02 08 08 00
> 10: 0c 04 38 00 01 00 01 50 60 50 60 3c 1e 3c 28 40
> 20: 35 47 15 27 3c 28 1e 00 00 37 4b 80 23 2d 0f 00
> 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 10 6b
> 40: ce 00 00 00 00 00 00 00 01 4d 33 20 39 33 54 33
> 50: 32 35 33 46 5a 30 2d 43 43 43 20 30 46 05 17 46
> 60: 04 cb 50 00 59 42 43 35 36 30 50 00 00 00 00 00
> 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 80: 00 49 d6 06 71 16 23 33 80 30 45 52 00 07 05 ff
> 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> f0: 01 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

That doesn't look right at all! Shouldn't your dimms be at smbus 0x50 
and 0x51? What SuperIO is this?

[ron minnich]

On Thu, Oct 1, 2009 at 6:21 PM, Joseph Smith  wrote:
> That doesn't look right at all! Shouldn't your dimms be at smbus 0x50 and
> 0x51? What SuperIO is this?

not at all, DIMMS can run from 50-57.

I think one of those SPD dumps is good, one bad, but I want to see
what anyone else thinks.

ron

[Joseph Smith]

On Thu, 1 Oct 2009 20:39:40 -0700, ron minnich  wrote:
> On Thu, Oct 1, 2009 at 6:21 PM, Joseph Smith  wrote:
> > That doesn't look right at all! Shouldn't your dimms be at smbus 0x50

and
> > 0x51? What SuperIO is this?
>
> not at all, DIMMS can run from 50-57.
>
> I think one of those SPD dumps is good, one bad, but I want to see
> what anyone else thinks.

Ok but I have never seen one that didn't start at 0x50. Unless you have
dimms in sockets 5(0x54) and 8(0x57)???

[Carl-Daniel Hailfinger]

On 02.10.2009 13:29, Joseph Smith wrote:
> On Thu, 1 Oct 2009 20:39:40 -0700, ron minnich  wrote:
> > On Thu, Oct 1, 2009 at 6:21 PM, Joseph Smith  wrote:
> > > That doesn't look right at all! Shouldn't your dimms be at smbus 0x50
> > > and 0x51? What SuperIO is this?
> >
> > not at all, DIMMS can run from 50-57
>
> Ok but I have never seen one that didn't start at 0x50. Unless you have
> dimms in sockets 5(0x54) and 8(0x57)???

I think I once saw DIMMS at 0x50-0x53 and 0x58-0x5b on a dualprocessor
board with 8 DIMM slots per processor (4 of them populated per
processor), but I could be mistaken.

Regards,
Carl-Daniel

[Joseph Smith]

On Thu, 1 Oct 2009 20:39:40 -0700, ron minnich  wrote:
> On Thu, Oct 1, 2009 at 6:21 PM, Joseph Smith  wrote:
> > That doesn't look right at all! Shouldn't your dimms be at smbus 0x50

and
> > 0x51? What SuperIO is this?
>
> not at all, DIMMS can run from 50-57.
>
> I think one of those SPD dumps is good, one bad, but I want to see
> what anyone else thinks.

You know Ron you could always compare the JEDEC registers with the dimms
manufacturers specifications to find out if the register values are good or
not.

[Carl-Daniel Hailfinger]

On 02.10.2009 13:46, Joseph Smith wrote:
> On Thu, 1 Oct 2009 20:39:40 -0700, ron minnich  wrote:
> > I think one of those SPD dumps is good, one bad, but I want to see
> > what anyone else thinks.
>
> You know Ron you could always compare the JEDEC registers with the dimms
> manufacturers specifications to find out if the register values are good or
> not.

decode-dimms (or decode-dimms.pl) from lm-sensors is extremely useful
for this. Run it on a working system and it will dump the content of all
SPDs and show the meaning of the values stored there.

If you want, you can compare these results with the output of the
coreboot SPD dump.

Regards,
Carl-Daniel

[Joseph Smith]

On Fri, 02 Oct 2009 13:53:43 +0200, Carl-Daniel Hailfinger
 wrote:
> On 02.10.2009 13:46, Joseph Smith wrote:
> > On Thu, 1 Oct 2009 20:39:40 -0700, ron minnich
>
> wrote:
> > > I think one of those SPD dumps is good, one bad, but I want to see
> > > what anyone else thinks.
> >
> > You know Ron you could always compare the JEDEC registers with the dimms
> > manufacturers specifications to find out if the register values are good
>
> or
> > not.
>
> decode-dimms (or decode-dimms.pl) from lm-sensors is extremely useful
> for this. Run it on a working system and it will dump the content of all
> SPDs and show the meaning of the values stored there.
>
> If you want, you can compare these results with the output of the
> coreboot SPD dump.

Good idea C-D :-)

[ron minnich]

On Fri, Oct 2, 2009 at 4:53 AM, Carl-Daniel Hailfinger
 wrote:
> decode-dimms (or decode-dimms.pl) from lm-sensors is extremely useful
> for this. Run it on a working system and it will dump the content of all
> SPDs and show the meaning of the values stored there.

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 can run this on the dell, and the decode-dimms will gladly tell me
there is no memory. Bummer! :-)

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

which would make part 2 independent of part 1. Then, I could easily
feed my output from serialice into decode_spd and have it say "WOW!
That's bogus!".

Maybe as part of this I can bust decode-dimms into two pieces as well ...

thanks, though, my goal is to have decode-dimms work well on the dell.
Hopefully won't take too long ...

ron

[Tom Sylla]

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

[ron minnich]

On Fri, Oct 2, 2009 at 11:41 AM, Tom Sylla  wrote:
> 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 :)

Maybe it is a difference in view. The address is 7 bits in all the
docs. How it is laid out in the register and on the bits on the wire
is really a different concern.

I can see an argument for either side ...

ron

[Tom Sylla]

On Fri, Oct 2, 2009 at 4:07 PM, ron minnich  wrote:
> Maybe it is a difference in view. The address is 7 bits in all the
> docs. How it is laid out in the register and on the bits on the wire
> is really a different concern.

Sorry for the dead horse revival, but I was just looking at an SMBus
spec today, and it reminded me that the specs I look at always seem to
show the address left justified; 8 bits big.

See page 10 of this doc:
http://www.atmel.com/dyn/resources/prod_documents/doc5226.pdf

or page 6 of this one:
http://www.nxp.com/acrobat_download/datasheets/PCA9555_8.pdf

the documents show the register pictures like 0xAX, not 0x5X+1bit :)

[ron minnich]

On Mon, Oct 26, 2009 at 2:05 PM, Tom Sylla  wrote:
> On Fri, Oct 2, 2009 at 4:07 PM, ron minnich  wrote:
> > Maybe it is a difference in view. The address is 7 bits in all the
> > docs. How it is laid out in the register and on the bits on the wire
> > is really a different concern.
>
> Sorry for the dead horse revival, but I was just looking at an SMBus
> spec today, and it reminded me that the specs I look at always seem to
> show the address left justified; 8 bits big.
>
> See page 10 of this doc:
> http://www.atmel.com/dyn/resources/prod_documents/doc5226.pdf
>
> or page 6 of this one:
> http://www.nxp.com/acrobat_download/datasheets/PCA9555_8.pdf
>
> the documents show the register pictures like 0xAX, not 0x5X+1bit :)

ah. well. Quick somebody, fix coreboot :-)

ron

[ron minnich]

BTW, THANKS for the note. I was hoping for a note from an expert :-)

That leading bytes sure looked like SPD but my obsolete JDEC docs threw me off.

Now I wonder why I only see one SPD ... but that's grist for another
note in little bit.

Thanks

ron

[Joseph Smith]

On 10/02/2009 04:09 PM, ron minnich wrote:
> BTW, THANKS for the note. I was hoping for a note from an expert :-)

:-(

[ron minnich]

On Fri, Oct 2, 2009 at 6:31 PM, Joseph Smith  wrote:
> On 10/02/2009 04:09 PM, ron minnich wrote:
> > BTW, THANKS for the note. I was hoping for a note from an expert :-)

Joseph, don't feel bad; I clearly don't know much about this stuff either :-)

That's why I'm glad we have such a broad range of experts here.
Everyone knows a lot about something :-)

ron

[Stefan Reinauer]

ron minnich wrote:
> BTW, THANKS for the note. I was hoping for a note from an expert :-)
>
> That leading bytes sure looked like SPD but my obsolete JDEC docs threw me off.
>
> Now I wonder why I only see one SPD ... but that's grist for another
> note in little bit.
>
> Thanks
>
> ron

What other devices do you see on that smbus? Some systems have smbus
switches, and you won't see the SPD devices unless you configure the
switch to the correct position.

Stefan

[ron minnich]

I'll poll the whole smbus monday. One problem is it doesn't seem to
work at all under factory bios -- Linux can't get to it. I expect the
BMC is, once again, getting in the way.

ron

[ron minnich]

OK, well, I did not quite get the answers I hoped for. So here go my comments:

On Thu, Oct 1, 2009 at 5:04 PM, ron minnich  wrote:
> dimm 50
> 00: bad device: 01
>
> dimm 51
> 00: bad device: 01
>
> dimm 52
> 00: bad device: 01
>
> dimm 53
> 00: bad device: 01

obviously bad.
> dimm 54
> 00: ad db de c0 01 00 00 00 01 f0 fa fa 00 00 00 d9

Bogus, because the first byte is "how many bytes written". I went to
http://en.wikipedia.org/wiki/Serial_presence_detect#On_older_equipment
and is is clear that 0xad doesn't match what's written:
> 10: 00 00 00 00 00 00 6c 01 00 00 00 00 00 00 00 00
> etc.
> f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

So this is bogus.
> dimm 55
> 00: bad device: 01
>
> dimm 56
> 00: bad device: 01

bad.
> dimm 57
> 00: 80 08 08 0d 0a 60 48 00 05 50 60 02 02 08 08 00
> 10: 0c 04 38 00 01 00 01 50 60 50 60 3c 1e 3c 28 40
> 20: 35 47 15 27 3c 28 1e 00 00 37 4b 80 23 2d 0f 00
> 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 10 6b
> 40: ce 00 00 00 00 00 00 00 01 4d 33 20 39 33 54 33
> 50: 32 35 33 46 5a 30 2d 43 43 43 20 30 46 05 17 46
> 60: 04 cb 50 00 59 42 43 35 36 30 50 00 00 00 00 00
> 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 80: 00 49 d6 06 71 16 23 33 80 30 45 52 00 07 05 ff
> 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> f0: 01 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

This looks closer to real. 0x80 is a common first byte. It also
matches (almost) the # bytes written since the last 112
bytes of this one are pretty clearly unwritten. Let's dig deeper.

Byte ordering for the first several bytes:

Defines # bytes written into serial memory at module mfgr
Total # bytes of SPD memory device
Fundamental memory type (FPM, EDO, SDRAM...) from appendix A
# Row Addresses on this assembly
# Column Addresses on this assembly
# Module Banks on this Assembly
Data Width of this assembly...
...Data Width continuation
Voltage interface standard of this assembly

next bytes are 08 and 08. Oops. Byte 2 is the type and 8 doesn't match
any type. Disappointing as some of the other
bytes almost look plausible, but 0x60 module banks? Doubtful ...

Time to break out the lm sensors tools ... and do the gpio dance again.

thanks

ron