SPD reading/writing under Linux and/or Windows

[keepread]

Hi all,
Where can I find the mysterious 'eeprom' kernel module that some use under Linux to read/write SPD?
I installed 'i2c-tools' and got 'decode-dimms' tool under Debian but not under Fedora, but both of them are missing the 'eeprom' module.
Also tried the SPD.exe tool from EVGA, which correctly lists all of the DIMM slots but reads zeroes from all of them.
Basically I need to dump SPD from some modules that were sold to me as DDR-1866 but are made of DDR-1600 chips, and they do not work. There is no access to RAM clock rate in the BIOS, so I am SOL unless I can rebin the SPD to the stock 1600.

[keepread]

Tried Slackware as well and it has 'eeprom' module that modprobes successfully, but then Slackware does not have I2C tools. I got them from Slackbiulds UK, but then 'i2cdetect' does not work because it cannot load libi2c.so which the package installed according to its output. Also, there is no 'detect-dimms' in the I2C package.
So I still have not found a working Linux distribution that has all of the 'eeprom' module and I2C tools with 'detect-dimms'. Any tips?
Perhaps it would be easier to just buy series 34 eeproms, burn them, and solder onto the DIMMs? I have USBAsp and Postal but am not sure they will burn series 34.

[stj]

if you know the module name then you can dynamically load it with the "modprobe" command
are dimms i²c? not SPI?

[keepread]

Of course! The only issue is that the module in question (eeprom) is absent from most kernels. I was able to build a custom kernel for Slackware where it can be enabled in XConfig (search for I2C, check off all variants, make modules and install)
But then I hit a snag when the I2C tools for Slack did not have the right programs.

I honestly don't know what kind of SPD chip it is. The marking on it does not google, and they are already in the running server so this will remain a mystery. I was told that in all likelihood it should be series 34 I2C eeprom.

Having said it, in the mean time I found a workaround. Turns out that it is much easier to patch the BIOS to lock the DDR frequency by flipping 'Auto' to '1600' in AMIBCP under Chipset/North Bridge.
So far so good, all modules work together, whereas previously only one module worked or the PC hung at various stages of boot-up. As there is 0% probability that I will have to sell this rig, it being long-obsolete, this is perfectly fine.

[stj]

oh - you have miss-matched ram
there is/was a program to edit the eeprom on the dimm.

[piernov]

ArchLinux, i2c-tools package, `decode-dimms` works fine. Using at24 driver for DDR3 (24-series I²C EEPROM) and ee1004 driver for DDR4 (34-series I²C EEPROM with JEDEC EE1004 spec) apparently.
24-series EEPROMs on DIMM sticks are often write-protected by pulling the WP pin high permanently on the PCB, so the IC may have to be desoldered anyway.

[keepread]

oh - you have miss-matched ram

No. Where did I indicate that? I don't believe I did. All of the DIMMs are the same.

ArchLinux, i2c-tools package, `decode-dimms` works fine. Using at24 driver for DDR3 (24-series I²C EEPROM) and ee1004 driver for DDR4 (34-series I²C EEPROM with JEDEC EE1004 spec) apparently.
24-series EEPROMs on DIMM sticks are often write-protected by pulling the WP pin high permanently on the PCB, so the IC may have to be desoldered anyway.

Thanks for the tip! I never used Arch so had no idea.