SPD XMP sections gets corrupted after saving an unedited dump, or even edit ones

[H43TO]

Hello, recently I started to tinker around with DDR5 sticks and therefore with the program again, and noticed that when I export a modified or unmodified SODIMM SPD, the XMP and maybe EXPO sections get kind of corrupted. One extreme example is when I dump and open my 6000MT/s 16GBx2 kit's spd, the voltages and profiles are as-expected(except my VMEMCTRL(MC) voltage it at 2.0V, thaiphoon reports it as N/A???), but when I save(even the unedited) SPD, and open it back again, everything is normal except the XMP profiles's voltage settings(VDD becomes 2V for all 3 main profiles), and when I open it with Thaiphoon burner the 4th XMP profile(User profile 1?) is corrupted.
I'll attach the 2 reports from Thaiphoon!

dump.xlsx
edit.xlsx

[H43TO]

Also, the two bin files:

dump.bin.txt
modif.bin.txt

[edlf]

There are 2 bugs, vmemcontroller voltage was ending up in VDD and the vmemcontroller voltage parsing seems broken for your sticks. I will try to figure out whats wrong with that later on, meanwhile I've pushed the fix for the 1st bug.

The other behavior you are seeing with the user profile 1 is because that one has a valid checksum but is empty, so the tool assumes theres something there. Both your user profile 1 and 2 have some data in it. I just need to figure out if 0x60 on vmem controller means no value defined or not.

[H43TO]

After dumping my SPD (the same stick as mentioned before) using the OCTool developed by Asus(?), the produced dump is bigger than the expected size for a DDR5 stick, and I have figured out that it is due to the extra header(?, its a 80byte block, 00 - 4F, no idea what it's for) added by the tool, but it's funcionally the same as the one dumped by the SPDrw made by 1a2m3, albeit, without a correct checksum(due to removing the affore mentioned header section), and it also contains slightly different data, like for example:

The Vmemctrl, in OCTool reffered to as MC - Memory Controller(?), is different between the two dumps. The dump made by the SPDrw has 0x60 in the byte position, like you mentioned too, which translates to 3.0V!? and that can't be(ig)! But the dump made by OCTool has the, assumed, correct voltage - 0x20, which is a much more reasonable 1.0V, also confirmed by the built-in SPD editor present in the tool(see attached picture, also whats the diff between the JEDEC and OC PMIC?). Also! Thaiphoon can read the dump(after removing the unnecessary header), and it also displays the correct voltages. But there are some issues with OCTool aswell, because when saving a dump, the 3rd XMP profile's timings and freq gets corrupted, eventho they are correctly displayed in the built-in SPD editor. So, It's better and not at the same time? lol

Asside from this I've notice some other variations between the dumps, but I cant remember them right now.

Also I was able to find some manufacturer bytes, like:

(all assume a regular DDR5 1k SPD and JEDEC ID for manufacturers and part numbers, sorry I never actually worked with hex too much, I'm not that good at it, hope you can see it trough)

• SPD Manufacturer Hex ID & Model+Revision: is at 0xC2-0xC3h, in my case its 0x8632 -> Montage Technology; 0xC4-0xC5, mine: 0x8015 -> M88SPD5118A5-T Rev: A5
• PMIC0 Mf ID & M+R: 0xC6-0xC7h, mine: 0x8A8C -> Richtek; 0xC8-0xC9h, mine: 0x8213 -> RTQ5132GQWF Rev: 13h
• PMIC1 Mf ID & M+R: 0xCA-0xCDh, mine: N/U;
• PMIC2 Mf ID & M+R: 0xCE-0xD1h, mine: N/U;
• Thermal Sensor Mf ID & M+R: 0xD2-0xD5h, mine: N/U;
• Module Mf & Mf Date and location: 0x200-201h, 0x202h, 0x203-204h, mine: 0x0198, 0x08, 0x2324 -> Kingston, Taiwan, 24th week of 2023
• Module Serial Num & Part Num and Module Rev: 0x205-208h, 0x209-226h, 0x207h, mine: 0x1B5CB81C, 0x4B463536305333382D313620202020202020202020202020202020202020, 0x00 ->Ser: 1B5CB81Ch, Part: KF560S38-16, Module Rev: 00h
• DRAM Mf ID & Stepping: **0x228-229h, 0x22Ah**, mine: 0x80AD, 0x41 -> Hynix, A-Die

Sorry I didn't have time for more, but hope this still helps!
One more thing, there are a few things I would like to talk about related to this project and SPD modding, but it would be so much more convenient talking them over at Discord (or somewhere else), if you would like to, please add me under @H43TO, no pressure ofcourse! 😅

Dumps and TBurner summaries:

OCTool_dump.bin.txt
OC_tool_dump.xlsx

SPDrw_smbus.bin.txt
SPDrw_dump.xlsx

Love the project, and kudos for caring for it!

[edlf]

To be honest I never had issues with SPDrw, I use it with an Arduino to read/write DDR5 spds without any issue. I never used the ASUS OCTool, I guess its only for really high end boards with the magic jumper that allows you to remove the read/write protection. I had MSI boards corrupt SPDs just by booting the uefi.... so I wouldn't trust the values OCTool is giving you. The reason why you don't see 3.00v is because I capped the interface at 2.00v.

Theres quite a bit of potential for corruption since EXPO takes the XMP Profile 3 and User Profile 1 location in the eeprom.

I guess the difference between PMICs is that one allows you to go control voltages? Some PMICs are also locked at 1.4 volts max. I also don't know why that is reported in the XMP tab.

A lot of the hex values you wrote down are already in the SPD data structure internally, but I don't expose them via the GUI since its quite a bit of a pain and I dont have all the IDs to properly report the data in an intuitive way. (You can check it in the ddr5spd_structs.h file)

I'll add you via Discord, I just haven't put that much work into this project since it mostly does what I needed it to do and the UI layer is a pain to maintain.