From: Kamil Aronowski <kamil.aronowski@3mdeb.com>
To: s.horvath@outlook.com.au, linux-i2c@vger.kernel.org
Cc: Jean Delvare <jdelvare@suse.de>, Guenter Roeck <linux@roeck-us.net>
Subject: Re: [PATCH 0/6] decode-dimms: Implement DDR5 decoding
Date: Wed, 5 Nov 2025 14:31:43 +0100 [thread overview]
Message-ID: <cdb56a48-8754-4d9d-9309-8a694c6f148d@3mdeb.com> (raw)
In-Reply-To: <20241114-decode-ddr5-v1-0-0ed2db8ef30f@outlook.com.au>
[-- Attachment #1.1.1: Type: text/plain, Size: 4116 bytes --]
On 11/14/24 07:37, Stephen Horvath via B4 Relay wrote:
> Hi, this series of patches adds DDR5 support to decode-dimms.
>
> I'm not too experienced with perl or the JEDEC specs, so there's probably
> going to be some questionable choices here, but I'd love to hear
> feedback.
The patchset doesn't seem to work out-of-the-box. When running the patched
`decode-dimms`, an error is thrown:
```
$ sudo ./eeprom/decode-dimms
Cannot read /sys/bus/i2c/drivers/spd5118/16-0050/eeprom at ./eeprom/decode-dimms line 2940.
```
I've checked with more than one machine to confirm, that it's not an individual
case.
Modifying the patched script, so that it reads one byte in a loop does seem to
fix some things, though, at least for the first 128 iterations:
```diff
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) {
```
Nevertheless, it still doesn't work as expected. A (trimmed) listing shows only
the following, except all the trimmed warnings:
```
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
```
> The first 4 patches (1, 2, 3, 4) add the essential information to
> decode-dimms.
>
> The next 2 patches (5, 6) haven't really been tested on hardware
> implementations so I'm happy for them to be dropped if they're not
> useful.
Was the patchset tested on any hardware or some other intended environment
outside of my use case? The latter is about the most recent revision of Fedora
Rawhide with the spd5118 module on various DDR5-equipped laptops.
--
Kamil Aronowski
Junior Embedded Firmware Engineer
GPG: 3510148A5CD67908
https://3mdeb.com | @3mdeb_com
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 5529 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
next prev parent reply other threads:[~2025-11-05 14:09 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-14 6:37 [PATCH 0/6] decode-dimms: Implement DDR5 decoding Stephen Horvath via B4 Relay
2024-11-14 6:37 ` [PATCH 1/6] decode-dimms: Implement DDR5 checksum parsing Stephen Horvath via B4 Relay
2024-11-14 6:37 ` [PATCH 2/6] decode-dimms: Decode DDR5 Manufacturer Data Stephen Horvath via B4 Relay
2024-11-14 6:37 ` [PATCH 3/6] decode-dimms: Decode timings and other data for DDR5 Stephen Horvath via B4 Relay
2024-11-14 6:37 ` [PATCH 4/6] decode-dimms: Decode DDR5 common module information Stephen Horvath via B4 Relay
2024-11-14 6:37 ` [PATCH 5/6] decode-dimms: Add basic decoding of type specific information for DDR5 Stephen Horvath via B4 Relay
2024-11-14 6:37 ` [PATCH 6/6] decode-dimms: Decode DDR5 error log Stephen Horvath via B4 Relay
2025-11-05 13:31 ` Kamil Aronowski [this message]
2025-11-06 1:26 ` [PATCH 0/6] decode-dimms: Implement DDR5 decoding Stephen Horvath
2025-11-06 13:55 ` Kamil Aronowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cdb56a48-8754-4d9d-9309-8a694c6f148d@3mdeb.com \
--to=kamil.aronowski@3mdeb.com \
--cc=jdelvare@suse.de \
--cc=linux-i2c@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=s.horvath@outlook.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox