Created attachment 306716 [details] Hexadecimal dump, from the aforereferenced e-mail. Per https://github.com/hardinfo2/hardinfo2/discussions/63#discussioncomment-10322689, there has been talk in the mailing list of this (https://lore.kernel.org/lkml/cf9d752e-0137-4a6d-85d3-fbe69293a43e@t-8ch.de/) but I don't see it tracked anywhere. I'd like it tracked, if possible, so that projects dependent upon this support can implement it when it's merged.
Created attachment 306718 [details] Hexadecimal dump, from the aforereferenced e-mail. Probably better in Markdown format, since it prevents the IDE wrapping the lines (per [this SuperUser comment](https://superuser.com/questions/1852166/what-is-the-file-extension-for-a-base-16-dump#comment2934827_1852166)).
(In reply to Beedell, Roke, Julian Lockhart from comment #1) > comment](https://superuser.com/questions/1852166/what-is-the-file-extension- > for-a-base-16-dump#comment2934827_1852166)). ...apologies about that formatting. I did enable Markdown when posting it.
Created attachment 306719 [details] Hexadecimal dump, from the aforereferenced e-mail. Couldn't obsolete the old attachment without uploading a new one. Sorry for the mail spam. This Bugzilla instance is rather unusual.
Relevant corroboration at https://access.redhat.com/solutions/7053692
https://lore.kernel.org/all/20241114-decode-ddr5-v1-5-0ed2db8ef30f@outlook.com.au/T/ contains a set of six patches by Stephen Horvath, implementing basic DDR5 SPD decoding support to decode-dimms.
(In reply to Matti Kurkela from comment #5) Have those been merged? I'll close this if they have. Thanks for the update!
Not yet, it seems. I just wanted to mention it here in case someone needs them quicker than a new release of i2c-tools can happen. I've just cloned the i2c-tools git repository and applied the patches to the master branch: they applied cleanly and seem to work, for what it's worth. Now to download the appropriate JEDEC specifications, and then I'll have to find time to do some light reading and cross-checking...
BTW, the other implementations are MSI Dragon Ball and Intel XTU and AIDA64. All on windows. MSI Dragon Ball is broken, it reads wrong XMP timings, while the other two agree with each other and agree with online videos of my RAM. I compiled it but it appears /sys/bus/i2c/drivers/spd5118/0-0053/eeprom is empty, so I think it is using I3C. When I3C in spd5118?