dasharo-issues decode-dimms: RAM info is not available

Component

Dasharo Tools Suite

Device

MSI Pro Z690-A

Dasharo version

v1.1.3

Dasharo Tools Suite version

2.6.0

Test case ID

No response

Brief summary

decode-dimms utility fails to provide valid RAM modules info.

How reproducible

--

How to reproduce

Boot DTS.
Ener shell.
Run decode-dimms command.
Run dts-boot.
Perform hcl report generation.

Expected behavior

decode-dimms provides reasonable output containing memoryu info.

Actual behavior

By default, in the shell, running the command will return following error:

No EEPROM found, try loading the eeprom, at24 or ee1004 module

After loading the modules it gives the following:

root@DasharoToolsSuite:~# modprobe ee1004
root@DasharoToolsSuite:~# modprobe at24
root@DasharoToolsSuite:~# modprobe eeprom
modprobe: FATAL: Module eeprom not found in directory /lib/modules/6.6.21-yocto-standard
root@DasharoToolsSuite:~# decode-dimms 
# decode-dimms version 4.3

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


Number of SDRAM DIMMs detected and decoded: 0
root@DasharoToolsSuite:~#

HCL report will state ERROR in "DIMMs information" (tested prior to loading modules manually).

Screenshots

No response

Additional context

The issue is related to: https://github.com/Dasharo/dts-hw-conf-gen/issues/5 All logs for Z790 for dimms are empty, thus cannot be parsed by dts-hw-conf-gen scripts.

The decode-dimms is 3rd party tool that's built into DTS.

dmidecode works though...

bash-5.2# dmidecode -t memory
# dmidecode 3.5
Getting SMBIOS data from sysfs.
SMBIOS 3.3.0 present.

Handle 0x0009, DMI type 16, 23 bytes
Physical Memory Array
	Location: System Board Or Motherboard
	Use: System Memory
	Error Correction Type: None
	Maximum Capacity: 128 GB
	Error Information Handle: Not Provided
	Number Of Devices: 4

Handle 0x000A, DMI type 17, 40 bytes
Memory Device
	Array Handle: 0x0009
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 8 GB
	Form Factor: DIMM
	Set: None
	Locator: Channel-0-DIMM-0
	Bank Locator: BANK 0
	Type: DDR5
	Type Detail: Synchronous Unbuffered (Unregistered)
	Speed: 4800 MT/s
	Manufacturer: Crucial
	Serial Number: e7336740
	Asset Tag: Channel-0-DIMM-0-AssetTag
	Part Number: CT8G48C40U5.M4A1
	Rank: 1
	Configured Memory Speed: 4000 MT/s
	Minimum Voltage: 1.1 V
	Maximum Voltage: 1.1 V
	Configured Voltage: 1.1 V

Handle 0x000B, DMI type 17, 40 bytes
Memory Device
	Array Handle: 0x0009
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 8 GB
	Form Factor: DIMM
	Set: None
	Locator: Channel-0-DIMM-1
	Bank Locator: BANK 0
	Type: DDR5
	Type Detail: Synchronous Unbuffered (Unregistered)
	Speed: 4800 MT/s
	Manufacturer: Crucial
	Serial Number: e7336766
	Asset Tag: Channel-0-DIMM-1-AssetTag
	Part Number: CT8G48C40U5.M4A1
	Rank: 1
	Configured Memory Speed: 4000 MT/s
	Minimum Voltage: 1.1 V
	Maximum Voltage: 1.1 V
	Configured Voltage: 1.1 V

Handle 0x000C, DMI type 17, 40 bytes
Memory Device
	Array Handle: 0x0009
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 8 GB
	Form Factor: DIMM
	Set: None
	Locator: Channel-0-DIMM-0
	Bank Locator: BANK 0
	Type: DDR5
	Type Detail: Synchronous Unbuffered (Unregistered)
	Speed: 4800 MT/s
	Manufacturer: Crucial
	Serial Number: e733674f
	Asset Tag: Channel-0-DIMM-0-AssetTag
	Part Number: CT8G48C40U5.M4A1
	Rank: 1
	Configured Memory Speed: 4000 MT/s
	Minimum Voltage: 1.1 V
	Maximum Voltage: 1.1 V
	Configured Voltage: 1.1 V

Handle 0x000D, DMI type 17, 40 bytes
Memory Device
	Array Handle: 0x0009
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 8 GB
	Form Factor: DIMM
	Set: None
	Locator: Channel-0-DIMM-1
	Bank Locator: BANK 0
	Type: DDR5
	Type Detail: Synchronous Unbuffered (Unregistered)
	Speed: 4800 MT/s
	Manufacturer: Crucial
	Serial Number: e7336765
	Asset Tag: Channel-0-DIMM-1-AssetTag
	Part Number: CT8G48C40U5.M4A1
	Rank: 1
	Configured Memory Speed: 4000 MT/s
	Minimum Voltage: 1.1 V
	Maximum Voltage: 1.1 V
	Configured Voltage: 1.1 V

The theory is that DDR5 uses a different SPD architecture, and the Linux kernel drivers lacks support for it.

dmidecode is supposedly working as it fetches these info from UEFI/BIOS.

There is, however, data on Dasharo docs about RAM modules, thus it might be false. Doesn't look like manual intervention, but I cannot confirm it isn't.

Might be worth seeing if it can be resolved by updating kernel and decode-dimms to "newest versions" as stated here. Current version of decode-dimms in dts is 4.3, the newest is 4.4 I checked changelog and there is no info DDR5 was fixed or anything.

Tested on Z690 with DDR5.

Solutions you've tried

No response

Sep 12 '25 09:09 3mkusiak

@3mkusiak maybe some tricks from https://hackaday.com/2023/04/18/linux-fu-reading-your-memorys-memory/ would help?

Sep 12 '25 12:09 m-iwanicki

Does it work on other OS, e.g. ubuntu?

Sep 17 '25 10:09 macpijan

Might be related to https://github.com/Dasharo/dasharo-issues/issues/158 .

Sep 17 '25 15:09 DaniilKl

Even after updating kernel it might not work. You might need spd5118 driver to read DDR5 SPD NVRAM which is included in upstream kernel since v6.11, so Yocto layer would need to be updated to at least Walnascar: https://downloads.yoctoproject.org/releases/yocto/yocto-5.2/RELEASENOTES

New Features / Enhancements in 5.2

Linux kernel 6.12

but decode-dimms likely still doesn't have support for DDR5. Looking through mailing lists I see some mentions that there needs to be support added for DDR5 to this tool but I couldn't find if anyone is working on it, closest was https://lore.kernel.org/linux-i2c/[email protected]/#t.

On Fedora 42 (kernel 6.16.7-200.fc42.x86_64), with decode-dimms 4.4 I get the same results as you. Linked hackaday post also doesn't help (had to remove spd5118 driver to even try as it was using those devices).

Sep 22 '25 19:09 iwanicki92

but decode-dimms likely still doesn't have support for DDR5. Looking through mailing lists I see some mentions that there needs to be support added for DDR5 to this tool but I couldn't find if anyone is working on it, closest was https://lore.kernel.org/linux-i2c/[email protected]/#t.

We could test this patch series and provide feedback? With this support, we do not need kernel upgrade IIUC.

This does not mean we couldn't use a kernel upgrade anyway in DTS.

Sep 22 '25 19:09 macpijan

This does not mean we couldn't use a kernel upgrade anyway in DTS

It'll be needed if you still want to use decode-dimms as it'll need spd5118 driver. I can dump 128 bytes when reading eeprom file (created by spd5118 driver) so I guess driver works:

dd if=/sys/bus/i2c/drivers/spd5118/11-0051/eeprom count=128 bs=1 | xxd
dd if=/sys/bus/i2c/drivers/spd5118/11-0053/eeprom count=128 bs=1 | xxd

so DTS needs:

kernel update for spd5118 driver
support for decoding DDR5 in decode-dimms

Sep 22 '25 20:09 iwanicki92

Thanks for clarification. I had an impression that we only needed decode-dimms support in this scenario.

Sep 22 '25 20:09 macpijan

Might be related to #158 .

Note that in my case it was a specific model of DDR4 modules that decode-dimms refused to see, they were effectively invisible to that tool and I suspected than CRC32 checksum being wrong based on a Windows tool made them invisible to decode-dimms. So the question here is whenever decode-dimms is supposed to work with DDR5, or it is issues with that particular model. Some vendors are quite bad at correctness.

Sep 23 '25 07:09 zirblazer

but decode-dimms likely still doesn't have support for DDR5. Looking through mailing lists I see some mentions that there needs to be support added for DDR5 to this tool but I couldn't find if anyone is working on it, closest was https://lore.kernel.org/linux-i2c/[email protected]/#t.

The patchset does not work out-of-the-box at all due to the error:

$ sudo ./eeprom/decode-dimms 
Cannot read /sys/bus/i2c/drivers/spd5118/16-0050/eeprom at ./eeprom/decode-dimms line 2940.

Nevertheless, with a custom patch that makes it read 1 byte in a loop, i.e.

diff --git a/eeprom/decode-dimms b/eeprom/decode-dimms
index a6a1669..1ff6741 100755
--- a/eeprom/decode-dimms
+++ b/eeprom/decode-dimms
@@ -2937,13 +2937,18 @@ sub readspd($$$)
 		binmode HANDLE;
 		sysseek(HANDLE, $offset, SEEK_SET)
 			or die "Cannot seek $dimm_i/eeprom";
-		$read = sysread(HANDLE, my $eeprom, $size)
-				or die "Cannot read $dimm_i/eeprom";
+		#$read = sysread(HANDLE, my $eeprom, $size)
+		#		or die "Cannot read $dimm_i/eeprom";
+		my $read = '';
+		my $buffer;
+		while (sysread(HANDLE, $buffer, 1) == 1) {
+			$read .= $buffer;
+		}
 		close HANDLE;
 		if ($read < $size) {
 			print STDERR "WARNING: $dimm_i/eeprom is smaller than expected\n";
 		}
-		@bytes = unpack("C*", $eeprom);
+		@bytes = unpack("C*", $buffer);
 	} else {
 		# Kernel 2.4 with procfs
 		for my $i (0 .. ($size-1)/16) {

there's at least some output - full of warnings, but at least something:

Use of uninitialized value in numeric eq (==) at ./eeprom/decode-dimms line 2945.
Argument "0^P^R^C^D\0 b\0\0\0\0M-^P^B\0\0\0\0\0\0e^A�^Cr�\0\0\0\0,..." isn't numeric in numeric lt (<) at ./eeprom/decode-dimms line 2948.
WARNING: /sys/bus/i2c/drivers/spd5118/20-0050/eeprom is smaller than expected
Use of uninitialized value in addition (+) at ./eeprom/decode-dimms line 2969.
Use of uninitialized value in addition (+) at ./eeprom/decode-dimms line 2969.
[...]
Use of uninitialized value $b in numeric eq (==) at ./eeprom/decode-dimms line 505.
Use of uninitialized value $b in numeric eq (==) at ./eeprom/decode-dimms line 506.
Use of uninitialized value $_[0] in sprintf at ./eeprom/decode-dimms line 2555.
Use of uninitialized value $_[1] in sprintf at ./eeprom/decode-dimms line 2555.
Use of uninitialized value $_[2] in sprintf at ./eeprom/decode-dimms line 2555.
Use of uninitialized value $_[3] in sprintf at ./eeprom/decode-dimms line 2555.
# decode-dimms version 4.4

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


Decoding EEPROM: /sys/bus/i2c/drivers/spd5118/20-0050
Guessing DIMM is in                              bank 1
Kernel driver used                               spd5118

---=== SPD EEPROM Information ===---
EEPROM Checksum of bytes 0-62                    OK (0x00)
SPD Revision                                     Invalid
Fundamental Memory type                          Unknown (0x00)

---=== Manufacturing Information ===---
Manufacturer                                     Undefined
Part Number                                      Undefined


Number of SDRAM DIMMs detected and decoded: 1

It might be worthwhile to determine the cause of the other issues and have them fixed in order for the patchset to be fine for actual usage.

Nov 04 '25 13:11 aronowski

but decode-dimms likely still doesn't have support for DDR5. Looking through mailing lists I see some mentions that there needs to be support added for DDR5 to this tool but I couldn't find if anyone is working on it, closest was https://lore.kernel.org/linux-i2c/[email protected]/#t.

Contrary to the earlier experiments, the linked patchset does work properly, but only on the machines without SPD write protection.

Therefore, using decode-dimms from Fedora Rawhide's i2c-tools-perl package, version 4.4, patched with the linked patchset, can be used to retrieve DDR5 information from the supported machines.

Nov 06 '25 13:11 aronowski

https://github.com/Dasharo/dasharo-issues/issues/1066 issue is connected and will be resolved along with this one (updating kernel to add spd5118 driver)

Dec 11 '25 08:12 m-iwanicki