Memory module identification

Hi,

I regularly have to sort through a fair number of memory
modules (DIMMs, SO-DIMMs, etc.).  All (?) of these have
serial ROMs that indicate applicable parameters for the
module.  Most are cryptically marked -- at best.  And,
reading part numbers off components is tedious (easier
to just discard the little beasts!)

Is it possible to design a little <something> to query
these devices and extract the parameters -- mapping them
to a human readable form (i.e., as a peripheral to a PC)?
Is this "ID" circuitry powered independent of the rest
of the module?  Or, do you, in fact, have to be able to
support every possible memory module (pinout, voltage, etc.)
*just* to gain access to this data?

Or, are they sufficiently non-standardized (e.g., across
DIMM types) to make that effort worthless?  (i.e., would
you already have had to narrow down the range of choices
sufficiently so the "software" could know how to interpret
the data that it extracts)

On Sun, 31 Aug 2014 13:54:27 -0700, Don Y <this@is.not.me.com> wrote:

>Hi,
>
>I regularly have to sort through a fair number of memory
>modules (DIMMs, SO-DIMMs, etc.).  All (?) of these have
>serial ROMs that indicate applicable parameters for the
>module.  Most are cryptically marked -- at best.  And,
>reading part numbers off components is tedious (easier
>to just discard the little beasts!)
>
>Is it possible to design a little <something> to query
>these devices and extract the parameters -- mapping them
>to a human readable form (i.e., as a peripheral to a PC)?
>Is this "ID" circuitry powered independent of the rest
>of the module?  Or, do you, in fact, have to be able to
>support every possible memory module (pinout, voltage, etc.)
>*just* to gain access to this data?
>
>Or, are they sufficiently non-standardized (e.g., across
>DIMM types) to make that effort worthless?  (i.e., would
>you already have had to narrow down the range of choices
>sufficiently so the "software" could know how to interpret
>the data that it extracts)

Look up serial presense detect.
<http://en.wikipedia.org/wiki/Serial_presence_detect>

Cheers

In sci.electronics.design Don Y <this@is.not.me.com> wrote:
> I regularly have to sort through a fair number of memory modules
> (DIMMs, SO-DIMMs, etc.).  All (?) of these have serial ROMs that
> indicate applicable parameters for the module.

Really old ones (before maybe about 2000) don't have the little serial
EEPROM, but everything that's still big enough to care about seems to.

> Most are cryptically marked -- at best.

I have gotten in the habit of writing the size of the module on it, in
Sharpie permanent marker, either when I buy the module, or when I pull
one from a running computer.  This doesn't help with new-to-you
computers, or ones that don't run, etc.

> Is this "ID" circuitry powered independent of the rest of the module?

I think it shares power and ground with the main RAM chips on the
module.  There is a separate pin or two for I2C to talk to the little
serial EEPROM.

I *think* the content of the EEPROM is fairly standardized.  On Linux,
you can install the i2c-tools package, insert the eeprom module, and
run decode-dimms to print the EEPROM contents in human-readable format.
By default, decode-dimms talks via I2C to the modules that are installed
in the PC it's running on, but it can also accept a hex dump of the
EEPROM contents that was obtained by other means.

I know people have gone the other way - they wanted to hook some I2C
peripheral (like an accelerometer) to their PC, so they took an old
memory module, unsoldered all the chips, tacked I2C and ground wires to
the right spots, and then plugged the module into a free slot.  I think
Analog Devices may have even shipped a "dummy" DIMM with one of their
dev kits for this purpose.

You might be able to do something like that, but since you are
connecting directly to the motherboard, some kind of buffer chip might
be in order.  Or, use an old PC that you don't care about.  :)

> Or, do you, in fact, have to be able to support every possible memory
> module (pinout, voltage, etc.) *just* to gain access to this data?

You have to at least be able to give the EEPROM power, ground, and I2C.
The little 8-pin serial EEPROMs seem to be kind of standard; if somebody
makes a "chip clip" that fits them, that might be easier than trying to
collect RAM sockets and wire up just a few pins.

Real official PC shops have dedicated hardware to test modules.  It
looks kind of like an old EPROM burner, with a bunch of sockets on it
(or one socket and some adapter sockets) and an LCD.  Put in module,
press button, get ID; press button again and it tests the RAM.

Matt Roberds

On 8/31/14, 4:54 PM, Don Y wrote:
> Hi,
>
> I regularly have to sort through a fair number of memory
> modules (DIMMs, SO-DIMMs, etc.).  All (?) of these have
> serial ROMs that indicate applicable parameters for the
> module.  Most are cryptically marked -- at best.  And,
> reading part numbers off components is tedious (easier
> to just discard the little beasts!)
>
> Is it possible to design a little <something> to query
> these devices and extract the parameters -- mapping them
> to a human readable form (i.e., as a peripheral to a PC)?
> Is this "ID" circuitry powered independent of the rest
> of the module?  Or, do you, in fact, have to be able to
> support every possible memory module (pinout, voltage, etc.)
> *just* to gain access to this data?
>
> Or, are they sufficiently non-standardized (e.g., across
> DIMM types) to make that effort worthless?  (i.e., would
> you already have had to narrow down the range of choices
> sufficiently so the "software" could know how to interpret
> the data that it extracts)

The shape of the board (including notches) gives you enough information 
to know how to readout the serial rom (assuming the board was built to 
the standards).

Generally the base connector will determine the base signals used, and 
the notch may define a voltage levels and sometimes some variations on 
the basic memory.

Generally, for a given mechanical configuration, there is a defined 
organization of the data in the serial rom.

Given a standard need, and thus a board shape, it is fairly quick to go 
though a stack of modules into a reader designed for that shape and tell 
you what you have.

If you just want to know what they all are, and are of varying shapes, 
it would be more difficult, as you would need to look up the specs for 
all the shapes to build up the test system.

Hi Matt,

On 8/31/2014 3:43 PM, mroberds@att.net wrote:
> In sci.electronics.design Don Y<this@is.not.me.com>  wrote:
>> I regularly have to sort through a fair number of memory modules
>> (DIMMs, SO-DIMMs, etc.).  All (?) of these have serial ROMs that
>> indicate applicable parameters for the module.
>
> Really old ones (before maybe about 2000) don't have the little serial
> EEPROM, but everything that's still big enough to care about seems to.

Yeah, I have 72pin SIMMs that use the "four jumper" solution.
Virtually impossible to verify that you have the right "flavor"
device installed -- without an elaborate tester (or, "try it and see")

>> Most are cryptically marked -- at best.
>
> I have gotten in the habit of writing the size of the module on it, in
> Sharpie permanent marker, either when I buy the module, or when I pull
> one from a running computer.  This doesn't help with new-to-you
> computers, or ones that don't run, etc.

Exactly.  I use a white "paint pen" (easily visible ON the black
plastic of the component IC's).  And, store them segregated by
type/speed (in plastic "freezer bags").

>> Is this "ID" circuitry powered independent of the rest of the module?
>
> I think it shares power and ground with the main RAM chips on the
> module.  There is a separate pin or two for I2C to talk to the little
> serial EEPROM.
>
> I *think* the content of the EEPROM is fairly standardized.  On Linux,

Yes, but only within a particular type of device, IIRC.  I.e., RAMBUS
vs. SDRAM vs.  ...

> you can install the i2c-tools package, insert the eeprom module, and
> run decode-dimms to print the EEPROM contents in human-readable format.
> By default, decode-dimms talks via I2C to the modules that are installed
> in the PC it's running on, but it can also accept a hex dump of the
> EEPROM contents that was obtained by other means.

Decoding the content(s) would be relatively easy -- *knowing*
what sort of device it is to begin with!

What I would like (ideally) is a device with instructions similar to:
- find the memory slot into which the DUT fits
- press the TEST button
- remove the DUT and place it in the "bin" indicated

(Printing a label to be affixed to the device would be problematic
as I have found many labels don't adhere well -- depending on the
arrangement of the devices on the DUT.  Asking someone to scribble
<whatever> on the DUT prior to "storing it" would be a nightmare.)

> I know people have gone the other way - they wanted to hook some I2C
> peripheral (like an accelerometer) to their PC, so they took an old
> memory module, unsoldered all the chips, tacked I2C and ground wires to
> the right spots, and then plugged the module into a free slot.  I think
> Analog Devices may have even shipped a "dummy" DIMM with one of their
> dev kits for this purpose.
>
> You might be able to do something like that, but since you are
> connecting directly to the motherboard, some kind of buffer chip might
> be in order.  Or, use an old PC that you don't care about.  :)

I was thinking of just harvesting one of each type of module connector
(or, some *other* scheme that could mate with a variety of different
devices -- module connectors tend not to have high insertion ratings!)
and installing them on a piece of phenolic with *just* the SPD pins
wired up (no desire to test the actual memory; just classify it!).

Then, connect that to a PC/laptop that drives the interface (I think
just a serial port with level translators would suffice) and presents
results on the screen -- or, illuminates individual lights above the
intended "bins".

[Think:  trained monkey]

>> Or, do you, in fact, have to be able to support every possible memory
>> module (pinout, voltage, etc.) *just* to gain access to this data?
>
> You have to at least be able to give the EEPROM power, ground, and I2C.
> The little 8-pin serial EEPROMs seem to be kind of standard; if somebody
> makes a "chip clip" that fits them, that might be easier than trying to
> collect RAM sockets and wire up just a few pins.

I'd be nervous about "poorly motivated" folks being charged with
"probing" a device *on* the memory module -- by anything other than
a clean "connector interface".

> Real official PC shops have dedicated hardware to test modules.  It
> looks kind of like an old EPROM burner, with a bunch of sockets on it
> (or one socket and some adapter sockets) and an LCD.  Put in module,
> press button, get ID; press button again and it tests the RAM.

I'm not as worried about testing the memory as I am trying to
get devices sorted *correctly* and efficiently -- by trained monkeys.
So, someone can just take a pile of DIMMs and *accurately* sort them
so that someone pulling "sorted" parts from those bins won't be
wondering why this memory module has the wrong number of pins; is NOT
ECC; is only 128MB; etc.

Hi Richard,

On 8/31/2014 6:02 PM, Richard Damon wrote:
> On 8/31/14, 4:54 PM, Don Y wrote:

>> I regularly have to sort through a fair number of memory
>> modules (DIMMs, SO-DIMMs, etc.). All (?) of these have
>> serial ROMs that indicate applicable parameters for the
>> module. Most are cryptically marked -- at best. And,
>> reading part numbers off components is tedious (easier
>> to just discard the little beasts!)

> The shape of the board (including notches) gives you enough information
> to know how to readout the serial rom (assuming the board was built to
> the standards).

Yes, but is it *always* unique?  E.g., 72pin EDO & FPM SIMMs had
the same physical shape.  Without probing the actual MEMORY
devices, you couldn't tell whether you had an EDO or FPM device.

I.e., does the size of board, number of pins and placement of keys
TOGETHER WITH THE SPD DATA *uniquely* identify EVERY type of memory
module?  (think about the variety of different memory types that
have been available in "recent years"!)

> Generally the base connector will determine the base signals used, and
> the notch may define a voltage levels and sometimes some variations on
> the basic memory.
>
> Generally, for a given mechanical configuration, there is a defined
> organization of the data in the serial rom.
>
> Given a standard need, and thus a board shape, it is fairly quick to go
> though a stack of modules into a reader designed for that shape and tell
> you what you have.
>
> If you just want to know what they all are, and are of varying shapes,
> it would be more difficult, as you would need to look up the specs for
> all the shapes to build up the test system.

My goal is to let a human make the "shape selection" choice (i.e.,
which socket does it fit into).  Then, by noting which (of many
different) socket is occupied, query the SPD data and UNIQUELY
know everything about the device that matters from a system's
standpoint.

Hi Martin,

On 8/31/2014 2:34 PM, Martin Riddle wrote:
> On Sun, 31 Aug 2014 13:54:27 -0700, Don Y<this@is.not.me.com>  wrote:
>> Or, are they sufficiently non-standardized (e.g., across
>> DIMM types) to make that effort worthless?  (i.e., would
>> you already have had to narrow down the range of choices
>> sufficiently so the "software" could know how to interpret
>> the data that it extracts)
>
> Look up serial presense detect.
> <http://en.wikipedia.org/wiki/Serial_presence_detect>

Yeah, but the type of module isn't really encoded in the data
anywhere.  I.e., you need to be able to physically examine it
in order to understand how to interpret the data.

I.e., I will have to present different "sockets" (and rely on the
user/operator to install the DUT in the proper socket) in order
to ascertain the *type* of module.

On 08/31/2014 10:54 PM, Don Y wrote:
> Hi,
>
> I regularly have to sort through a fair number of memory
> modules (DIMMs, SO-DIMMs, etc.).  All (?) of these have
> serial ROMs that indicate applicable parameters for the
> module.  Most are cryptically marked -- at best.  And,
> reading part numbers off components is tedious (easier
> to just discard the little beasts!)
>
> Is it possible to design a little <something> to query
> these devices and extract the parameters -- mapping them
> to a human readable form (i.e., as a peripheral to a PC)?
> Is this "ID" circuitry powered independent of the rest
> of the module?  Or, do you, in fact, have to be able to
> support every possible memory module (pinout, voltage, etc.)
> *just* to gain access to this data?

I tried it with i2c-parport. Botched the circuit(transistors instead of 
diodes? ...not sure, something was inverted), so had to use userspace 
ppdev access <http://members.aon.at/~aklamme4/scratch/main.c>, but it 
worked. The power pin for the eeprom is separate, so could be powered 
from a linreg... 3V, I think..
decode-dimms can be used to decode the contents...
I only tried on an old DDR ram that had died... If you have some really 
old/exotic modules it may not work...
If you happen to have the DIMM installed in your box, you can directly 
read it out somewhere at
/sys/module/eeprom/drivers/i2c:eeprom

Oh, all on LINUX...
>
> Or, are they sufficiently non-standardized (e.g., across
> DIMM types) to make that effort worthless?  (i.e., would
> you already have had to narrow down the range of choices
> sufficiently so the "software" could know how to interpret
> the data that it extracts)

Hi Johann,

On 9/1/2014 3:56 AM, Johann Klammer wrote:
> On 08/31/2014 10:54 PM, Don Y wrote:

>> Is it possible to design a little <something> to query
>> these devices and extract the parameters -- mapping them
>> to a human readable form (i.e., as a peripheral to a PC)?
>> Is this "ID" circuitry powered independent of the rest
>> of the module? Or, do you, in fact, have to be able to
>> support every possible memory module (pinout, voltage, etc.)
>> *just* to gain access to this data?
>
> I tried it with i2c-parport. Botched the circuit(transistors instead of
> diodes? ...not sure, something was inverted), so had to use userspace
> ppdev access <http://members.aon.at/~aklamme4/scratch/main.c>, but it
> worked. The power pin for the eeprom is separate, so could be powered
> from a linreg... 3V, I think..

OK.  So, no need for a real power supply (as the memory, itself, is
not powered up).

> decode-dimms can be used to decode the contents...
> I only tried on an old DDR ram that had died... If you have some really
> old/exotic modules it may not work...
> If you happen to have the DIMM installed in your box, you can directly
> read it out somewhere at
> /sys/module/eeprom/drivers/i2c:eeprom
>
> Oh, all on LINUX...

(sigh)  Yes, it looks like its possible to electrically design
such a device -- and, make it reasonably fool proof.  The *real*
problem seems to lie in the module connectors:  most are only
rated at a handful of mating cycles (e.g., 5-25).

While this may be plenty for a "typical application" (and, I
suspect often *exceeded* by folks!), I can't imagine hundreds
and thousands of cycles *weekly* would leave the connector's
reliability unaltered.  <frown>

I will have to find another way of interfacing to the modules...

On 8/31/14, 9:25 PM, Don Y wrote:
> Hi Richard,
>
> On 8/31/2014 6:02 PM, Richard Damon wrote:
>> On 8/31/14, 4:54 PM, Don Y wrote:
>
>>> I regularly have to sort through a fair number of memory
>>> modules (DIMMs, SO-DIMMs, etc.). All (?) of these have
>>> serial ROMs that indicate applicable parameters for the
>>> module. Most are cryptically marked -- at best. And,
>>> reading part numbers off components is tedious (easier
>>> to just discard the little beasts!)
>
>> The shape of the board (including notches) gives you enough information
>> to know how to readout the serial rom (assuming the board was built to
>> the standards).
>
> Yes, but is it *always* unique?  E.g., 72pin EDO & FPM SIMMs had
> the same physical shape.  Without probing the actual MEMORY
> devices, you couldn't tell whether you had an EDO or FPM device.
>
> I.e., does the size of board, number of pins and placement of keys
> TOGETHER WITH THE SPD DATA *uniquely* identify EVERY type of memory
> module?  (think about the variety of different memory types that
> have been available in "recent years"!)
>

I do believe that was the intent of the standards, that the physical 
interlocks were to keep dangerously incompatible parts separated (as 
well as some just not working variations) and the serial rom provided 
details to allow the system to configure itself (or reject if not 
compatible).

>> Generally the base connector will determine the base signals used, and
>> the notch may define a voltage levels and sometimes some variations on
>> the basic memory.
>>
>> Generally, for a given mechanical configuration, there is a defined
>> organization of the data in the serial rom.
>>
>> Given a standard need, and thus a board shape, it is fairly quick to go
>> though a stack of modules into a reader designed for that shape and tell
>> you what you have.
>>
>> If you just want to know what they all are, and are of varying shapes,
>> it would be more difficult, as you would need to look up the specs for
>> all the shapes to build up the test system.
>
> My goal is to let a human make the "shape selection" choice (i.e.,
> which socket does it fit into).  Then, by noting which (of many
> different) socket is occupied, query the SPD data and UNIQUELY
> know everything about the device that matters from a system's
> standpoint.

Since to build such a device, you are going to need to obtain standards 
documentation of all of the sockets and serial data formats, you will 
have an opportunity to verify that the information is sufficient and 
unique.

This of course will only help you with parts made to the standards. It 
wouldn't surprise me that someone made a proprietary memory module that 
went into their proprietary socket (that uses a regular connector, just 
not by the standard), and such a module could confuse your system (or 
even be damaged). I know I have a CPU module on my desk that uses a 
standard memory connector and whose pin out is nothing like the standard 
memory module. At least it is significantly longer than a standard 
memory module so unlikely to fit into the memory connector of a real system.