Posts tagged with i2c

DDR4 memory information in Linux

Background

If you’ve built a PC desktop in the last few years you’ve probably been exposed to the confusing array of DDR4 information when it comes to buying RAM.

A shot of G-Skill Trident Z RGB memory modules glowing in my PC

What it comes down to is not all RAM is created equal. Once you get past pin size and memory capacity you’ll have to filter down by speed. Speed isn’t measured in a simple way - you may see a rated speed like 2400MHz but you’ll also see another bunch of numbers 16-16-16-39 that indicate the necessary clock cycles to perform certain types of memory operations.

While JEDEC - the people behind the DDR4 standard - ratify the well known speeds like 2400 they’ve been quite behind the desires of consumers and manufacturers and so Intel created Extreme Memory Profile (XMP) which lets the RAM tell the PC a faster set of timings and clock speed it can support and what voltage it needs to do that. Things get a little more complicated as really these memory modules tend to only be qualified for certain speeds on certain motherboards and processors and XMP knows nothing about that - head to the RAM’s Qualified Vendor List (QVL) for that.

While all of this used to be really only of interest to people wishing to “overclock” their systems the latest Ryzen Zen 2 CPUs like the 3900X really benefit from increasing the memory speeds as the “Infinity Fabric” interconnect between the chiplets and the outside world runs at the speed of the memory controller - at least initially - and so it’s quite important to any Zen 2 owner wanting to take full advantage of the CPU they have purchased.

Thankfully memory modules for some time have a little bit of persistent memory called Serial Presence Detect (SPD) on them which is accessed over the “I2C/SMBus” device bus in your machine so your BIOS or other tools can find out exactly what the manufacturer has rated them for as well as who manufactured the actual memory chips themselves, when, where and using what kind of die/process.

Reading the Serial Presence Detect

So given all that what do you do to take a look at this info?

Well, on Windows you can just fire up a tool like Thaiphoon Burner, click EEPROM in the menu and then Read SPD on SMBus… which gives you something like this:

MEMORY MODULE
Manufacturer
Crucial Technology
Series
Ballistix Sport LT Red
Part Number
BLS16G4D240FSE.16FBD
Serial Number
3982077Bh
JEDEC DIMM Label
16GB 2Rx8 PC4-2400R-UB0-11
Architecture
DDR4 SDRAM UDIMM
Speed Grade
DDR4-2400R
Capacity
16 GB (16 components)
Organization
2048M x64 (2 ranks)
Register Model
N/A
Manufacturing Date
Undefined
Manufacturing Location
Boise, USA (SIG)
Revision / Raw Card
0000h / B0 (8 layers)
DRAM COMPONENTS
Manufacturer
Micron Technology
Part Number
D9TBH (MT40A1G8WE-083E:B)
Package
Standard Monolithic 78-ball FBGA
Die Density / Count
8 Gb B-die (Z01A / 20 nm) / 1 die
Composition
1024Mb x8 (64Mb x8 x 16 banks)
Clock Frequency
1200 MHz (0.833 ns)
Minimum Timing Delays
16-16-16-39-55
Read Latencies Supported
20T, 18T, 16T, 15T, 14T, 13T, 12T...
Supply Voltage
1.20 V
XMP Certified
1200 MHz / 16-16-16-39-55 / 1.20 V
XMP Extreme
Not programmed
SPD Revision
1.1 / September 2015
XMP Revision
2.0 / December 2013

You can then feed these values into something like DRAM Calculator for Ryzen to figure out good fast timings to enter into your BIOS.

What about Linux?

If you Google around you’ll find guides that tell you to run various modprobe, i2cdetect commands and probably decode-dimms however…

DDR4 use different type of SPD memory chips. Linux support is new and incomplete.

Previously these chips were a type known as eeprom - electronically-erasable programmable read-only-memory (the previous tech was just known as eprom as you needed an ultraviolet box to wipe them through a little window on the top).

DDR4 however has switched from the very dated eeprom technology to the incredibly popular flash memory.

So if you actually run those commands you’ll likely find decode-dimms doesn’t tell you much at all. In fact there are two possible scenarios:

  1. It tells you no eeprom found. This means the existing eeprom driver can’t find your SPD and you’re most likely going to need to obtain and load an alternative i2c driver.
  2. It shows you some generic RAM information but says SPD is invalid. This means your i2c is communicating fine with the SPD but Linux doesn’t understand the DDR4 flash eeprom. You just need to setup the ee1004 driver.

Identifying the right I2C bus

Either way you’re going to need to get the i2c device number your SPD is connected to by way of i2cdetect so run:

i2cdetect -l

Which will give you some output like this:

i2c-3   i2c         i915 gmbus dpd                          I2C adapter
i2c-1   i2c         i915 gmbus dpc                          I2C adapter
i2c-4   i2c         DPDDC-E                                 I2C adapter
i2c-2   i2c         i915 gmbus dpb                          I2C adapter
i2c-0   smbus       SMBus I801 adapter at f040              SMBus adapter

The results are system dependent but you need to deduce which one your SPD is on. The Intel Z370 chipset my Linux box runs uses the SMBus I801 interface so I need to make a note of i2c-0.

If you’re not sure then it may be a process of elimination based on the names. i915 is the Intel on-board CPU graphic support so it wouldn’t be that and a quick Google also associated the DPDDC-E with that too. I’d probably also give some preference to SMBus adapter ones rather than I2C but I couldn’t find any confirmation that this is always the case.

Now, if you’re not sure which one you can try dumping information from each to see if you can find the right-looking data using this command but changing 0 to the likely candidates to the i2c device number from the first column in i2cdetect -l.

i2cdetect -y 0

With any luck it should look something like this. If all you see are -- then try another.

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- 08 -- -- -- -- -- -- --
10: -- -- -- -- 14 15 -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: 30 31 -- -- 34 35 -- -- -- -- -- -- -- -- -- --
40: 40 -- -- -- 44 -- -- -- -- -- -- -- -- -- -- --
50: 50 51 52 53 -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- 6a -- -- -- -- --
70: -- -- -- -- -- -- -- --

Now there’s a chance - especially if decode-dimms told you no eeprom found that you don’t actually have the i2c driver loaded. The i801 driver is compatible with many Intel chipsets. To load that you can use:

modprobe i2c-i801

If you’re running AMD you might get away with:

modprobe i2c-amd-mp2-pci

if your Linux is really up to date. If not check out the i2c-amd-mp2 repo for manual installation instructions.

You can also try running decode-dimms again and hopefully now you should see some generic memory information.

Introducing ee1004

Now that you have i2c working and identified we can move on to the ee1004 flash driver for DDR4.

If so then just typing:

modprobe ee1004

Should get you up and running and you can skip the next section and go straight to registering the SPD devices.

If you don’t have the kernel module (Ubuntu 18 doesn’t have it) you will see an error like this one:

modprobe: FATAL: Module ee1004 not found in directory /lib/modules/...

and so you’ll need to install it…

Installing latest ee1004 driver

So either you don’t have ee1004 or you need the latest. Lets CURL it down from the maintainers site. I wouldn’t normally recommend building kernel drivers from untrusted sources but…

curl -O http://jdelvare.nerim.net/devel/lm-sensors/drivers/ee1004/Makefile
curl -O http://jdelvare.nerim.net/devel/lm-sensors/drivers/ee1004/ee1004.c
sudo make install

(If make doesn’t work you’re going to need install things like build-essentials etc. via apt or your package manager of choice).

Now that is compiled and copied into /lib/modules/.../kernel/drivers/misc/eeprom/ee1004.ko we need to load it. Now there’s a small chance your system already has the older eeprom driver loaded so we’ll unload that as well so it doesn’t interfere:

modprobe -r eeprom
modprobe ee1004

Registering the SPD devices

Okay, so you now have the ee1004 driver installed, you can see the bus your SPD devices are on there’s just a few more steps to make sure ee1004 knows which SPD devices it’s supposed to be looking at.

Run the following command replacing 0 with the number after i2c- you identified as the bus your SPD devices are located on:

i2cdetect -y 0

Now this will dump out that basic I2C information we saw earlier. On my system it looks like this:

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- 08 -- -- -- -- -- -- --
10: -- -- -- -- 14 15 -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: 30 31 -- -- 34 35 -- -- -- -- -- -- -- -- -- --
40: 40 -- -- -- 44 -- -- -- -- -- -- -- -- -- -- --
50: 50 51 52 53 -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- 6a -- -- -- -- --
70: -- -- -- -- -- -- -- --

You see those 50 51 52 53 bytes? Those are my four DDR4 DIMM sticks and we need to register those numbers with the ee1004 driver.

Note: I couldn’t find out if it’s always those numbers or always that location. YMMV.

You can start by just registering one to see if it works (replace i2c-0 with your i2c device from the previous section and 0x50 with the bank number of your memory module you figured out in the chart above:

echo ee1004 0x50 > /sys/bus/i2c/devices/i2c-0/new_device

now run decode-dimms and with any luck you will see output like this:

Memory Serial Presence Detect Decoder
By Philip Edelbrock, Christian Zuckschwerdt, Burkart Lingner,
Jean Delvare, Trent Piepho and others


Decoding EEPROM: /sys/bus/i2c/drivers/ee1004/0-0050
Guessing DIMM is in                              bank 1

---=== SPD EEPROM Information ===---
EEPROM CRC of bytes 0-125                        OK (0x05EA)
# of bytes written to SDRAM EEPROM               384
Total number of bytes in EEPROM                  512
Fundamental Memory type                          DDR4 SDRAM
SPD Revision                                     1.1
Module Type                                      UDIMM
EEPROM CRC of bytes 128-253                      OK (0x27DE)

If it did not register correctly you should de-register the bank with the command:

echo 0x51 /sys/bus/i2c/devices/i2c-0/delete_device

If it worked however go ahead and register the rest of your modules depending on what banks you have memory sticks in. For example on my system the complete registration is:

echo ee1004 0x50 > /sys/bus/i2c/devices/i2c-0/new_device
echo ee1004 0x51 > /sys/bus/i2c/devices/i2c-0/new_device
echo ee1004 0x52 > /sys/bus/i2c/devices/i2c-0/new_device
echo ee1004 0x53 > /sys/bus/i2c/devices/i2c-0/new_device

Now you can finally run

decode-dimms --side-by-side

And get to see the useful timings, manufacturer etc.

Decoding EEPROM                                  0-0050                0-0051                0-0052                0-0053
Guessing DIMM is in                              bank 1                bank 2                bank 3                bank 4

---=== SPD EEPROM Information ===---
EEPROM CRC of bytes 0-125                        OK (0x05EA)           OK (0x699E)           OK (0x05EA)           OK (0x699E)
# of bytes written to SDRAM EEPROM               384
Total number of bytes in EEPROM                  512
Fundamental Memory type                          DDR4 SDRAM
SPD Revision                                     1.1                   1.0                   1.1                   1.0
Module Type                                      UDIMM
EEPROM CRC of bytes 128-253                      OK (0x27DE)

---=== Memory Characteristics ===---
Maximum module speed                             2400 MHz (PC4-19200)
Size                                             16384 MB
Banks x Rows x Columns x Bits                    16 x 16 x 10 x 64
SDRAM Device Width                               8 bits
Ranks                                            2
Rank Mix                                         Symmetrical
AA-RCD-RP-RAS (cycles)                           16-16-16-39
Supported CAS Latencies                          20T, 18T, 16T, 15T, 14T, 13T, 12T, 11T, 10T, 9T

---=== Timings at Standard Speeds ===---
AA-RCD-RP-RAS (cycles) as DDR4-2400              16-16-16-39
AA-RCD-RP-RAS (cycles) as DDR4-2133              15-15-15-35
AA-RCD-RP-RAS (cycles) as DDR4-1866              13-13-13-30
AA-RCD-RP-RAS (cycles) as DDR4-1600              11-11-11-26

---=== Timing Parameters ===---
Minimum Cycle Time (tCKmin)                      0.833 ns
Maximum Cycle Time (tCKmax)                      1.600 ns              1.500 ns              1.600 ns              1.500 ns
Minimum CAS Latency Time (tAA)                   13.320 ns
Minimum RAS to CAS Delay (tRCD)                  13.320 ns
Minimum Row Precharge Delay (tRP)                13.320 ns
Minimum Active to Precharge Delay (tRAS)         32.000 ns
Minimum Active to Auto-Refresh Delay (tRC)       45.320 ns
Minimum Recovery Delay (tRFC1)                   350.000 ns
Minimum Recovery Delay (tRFC2)                   260.000 ns
Minimum Recovery Delay (tRFC4)                   160.000 ns
Minimum Four Activate Window Delay (tFAW)        21.000 ns
Minimum Row Active to Row Active Delay (tRRD_S)  3.299 ns
Minimum Row Active to Row Active Delay (tRRD_L)  4.900 ns
Minimum CAS to CAS Delay (tCCD_L)                5.000 ns
Minimum Write Recovery Time (tWR)                15.000 ns             N/A                   15.000 ns             N/A
Minimum Write to Read Time (tWTR_S)              2.500 ns              N/A                   2.500 ns              N/A
Minimum Write to Read Time (tWTR_L)              7.500 ns              N/A                   7.500 ns              N/A

---=== Other Information ===---
Package Type                                     Monolithic
Maximum Activate Count                           Unlimited
Post Package Repair                              Not supported
Module Nominal Voltage                           1.2 V
Thermal Sensor                                   No

---=== Physical Characteristics ===---
Module Height                                    32 mm
Module Thickness                                 2 mm front, 2 mm back
Module Reference Card                            B revision 0

---=== Manufacturer Data ===---
Module Manufacturer                              Crucial Technology
DRAM Manufacturer                                Micron Technology
Assembly Serial Number                           0x3982077B            0xA02071FC            0x3982077D            0xA02071AC
Part Number                                      BLS16G4D240FSE.16FBD  BLS16G4D240FSE.16FAD  BLS16G4D240FSE.16FBD  BLS16G4D240FSE.16FAD

How to see die version?

One of the things you don’t see here is the die version. If you’re overclocking that is very important to figure out what timings and tweaks you can get at (right now Micron E-die is the newest hotness after Samsung B-die had a good run).

Die is not part of the specification and it seems from playing with Thaiphoon it’s a bunch of matching bytes. I’m looking into putting together a small Linux script/binary that will identify them but in the mean-time you have two options if you need this extra info:

Either way you’ll need to make a Thaiphoon-compatible hex dump (replacing 0-0050 with the i2c bus number followed by a dash then the memory bank number)

od -Ax -t x1 -v /sys/bus/i2c/drivers/ee1004/0-0050/eeprom

You’ll see some output like this which you should copy to the clipboard:

000000 23 11 0c 02 85 21 00 08 00 00 00 03 09 03 00 00
000010 00 00 07 0d fc 2b 00 00 6b 6b 6b 11 00 6b f0 0a
000020 20 08 00 05 00 a8 1b 28 28 00 78 00 14 3c 00 00
000030 00 00 00 00 00 00 00 00 00 00 00 00 16 36 16 36
000040 16 36 16 36 00 20 2b 0c 2b 0c 2b 0c 2b 0c 00 00
000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000070 00 00 00 00 00 00 9c b4 c9 c9 c9 c9 e7 d6 ea 05
000080 11 11 01 01 00 00 00 00 00 00 00 00 00 00 00 00
000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 de 27
000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000140 85 9b 00 00 00 39 82 07 7b 42 4c 53 31 36 47 34
000150 44 32 34 30 46 53 45 2e 31 36 46 42 44 00 80 2c
000160 00 44 50 41 47 48 34 47 30 30 31 ff 00 00 00 00
000170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000180 0c 4a 05 20 00 00 00 00 00 94 00 00 07 ff 3f 00
000190 00 6a 6a 6a 11 00 6b f0 0a 20 08 00 05 00 a8 1b
0001a0 28 00 00 00 00 00 00 00 00 cf b5 ca ca ca ca d6
0001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0001c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000200

Now either:

  1. Send it to a Windows-using friend who can run Thaiphoon
  2. Run Thaiphoon via WINE (which should now work as it won’t need low-level hardware access to the SMBus)

Inside Thaiphoon in the File menu you’ll see Import from Clipboard which should reveal a lot of information including the DRAM Die Revision / Process Node you’re after.

If for some reason you want to read somebody else’s hex dumps on your Linux box decode-dimms can do that too:

decode-dimms -x myspd1.hex

Enjoy!

[)amien