Do you have the protocol portions for writing reverse engineered? I just picked up an X299 system (ASUS TUF X299 Mark 2, i7 7800X). I've added this driver to OpenRGB as X299 support has been a hole in our hardware support since the beginning but I didn't have the hardware to test it. Just received my CPU today and got it set up. The driver does detect the bus and it shows in OpenRGB's list of buses, but none of the commands I try (basically equivalents to i2cdetect/i2cdump) using quick or read operations detect any devices. I'm using the released version but I want to try compiling and testing this against some RGB RAM devices.

Do you have the protocol portions for writing reverse engineered?

Unfortunately no, but I can take a look into my old sources again and pass you all information I have after I've tried myself. You'll have to test writes yourself though.
Is there a way to contact you for all the data ?

I just picked up an X299 system (ASUS TUF X299 Mark 2, i7 7800X). I've added this driver to OpenRGB as X299 support has been a hole in our hardware support since the beginning but I didn't have the hardware to test it. Just received my CPU today and got it set up. The driver does detect the bus and it shows in OpenRGB's list of buses, but none of the commands I try (basically equivalents to i2cdetect/i2cdump) using quick or read operations detect any devices.

As far as I remember that i2cdetect is not going to work.

The read operations should work fine though, I have no issues on my MSI X299 RAIDER and one of my testers has ASUS Pro WS X299 SAGE II also without issues.

The usage is a bit different than the other SMBuses. That'll not work out of the box.
I'll look into adjusting it a little bit more towards the others and try to get rid of the encode/decode stuff which is currently in place.

Ping me in a week if nothing has changed.

Trying to compile your branch and I'm getting some errors, looks like something's changed in the core since the last time I've built from source. Do you know how to solve the following issues:

PS C:\git\PawnIO.Modules> & 'C:\Program Files (x86)\Pawn\bin\pawncc.exe' .\SmbusIntelSkylakeIMC.p -C64 -iinclude               
Pawn compiler 4.1.7487                  Copyright (c) 1997-2025, CompuPhase

include\core.inc(20) : error 021: symbol already defined: "tolower"
include\core.inc(21) : error 010: invalid function or declaration
include\core.inc(24) : error 021: symbol already defined: "toupper"
include\core.inc(25) : error 010: invalid function or declaration
include\core.inc(28) : error 021: symbol already defined: "swapchars"
include\core.inc(30) : error 010: invalid function or declaration
include\core.inc(33) : error 010: invalid function or declaration
include\core.inc(36) : error 010: invalid function or declaration
include\core.inc(39) : error 021: symbol already defined: "min"
include\core.inc(40) : error 010: invalid function or declaration
include\core.inc(43) : error 021: symbol already defined: "max"
include\core.inc(44) : error 010: invalid function or declaration
include\core.inc(47) : error 021: symbol already defined: "clamp"
include\core.inc(48) : error 010: invalid function or declaration
include\pawnio.inc(40) : warning 218: old style forward declarations of functions are deprecated
include\core.inc(32) : warning 203: symbol is never used: "high"
include\core.inc(31) : warning 203: symbol is never used: "low"

Also, you can email me the documentation if you want or on Discord. My username @ gmail.

I decided to try asking Google's AI to see if it had any information on this. I found some other code for an Intel IMC I2C interface that seemed to point to unrelated registers. From what I gathered through Google, the interface you're using is a high level mailbox interface while there are other PCI devices for the bare metal I2C controllers for IMC0 and IMC1. The Google AI documentation seemed to know how to send read and write commands to this interface. It was referencing Intel datasheets (and the datasheet referenced called out the i7 7800X by name) but I'm taking everything it said with a huge grain of salt. Just putting it out there that this seems to be at least partially documented in an Intel datasheet and has made it into AI data sets.

x299 pci device 1e function 5 - Google Search.pdf

Edit: It might just be hallucinating based on the code, the datasheet does have the IMC SMBus interfaces but I am not seeing this mailbox interface explicitly called out in the same document. Maybe it's pulling from a different series or maybe not, but I'm not sure the info about how to interact with this mailbox interface is trustworthy.

Trying to compile your branch and I'm getting some errors, looks like something's changed in the core since the last time I've built from source. Do you know how to solve the following issues:

I've checked the github build to adjust mine, I think you're just missing -p:

I decided to try asking Google's AI to see if it had any information on this.

Oh hell no. I've tried asking countless AIs asking on this but they all just delivered crap as they don't have access to the proper documents.

Edit: It might just be hallucinating based on the code, the datasheet does have the IMC SMBus interfaces but I am not seeing this mailbox interface explicitly called out in the same document.

I can send you the correct PDFs when I'm back on my machine.
The most valuable was quite hard to find (probably because it should have not been publicly available).

@CalcProgrammer1 I've sent you an email this morning.

I pushed some changes for write support, you can check and/or test that if you like.

Edit: SMBus should now work exactly like the others, so no more magic for the arguments which are being passed in.

For some reason this setup does not want to load self-compiled modules. I've tried building and test signing the module and copying it into my OpenRGB folder, but OpenRGB logs show the module is not initializing properly. I also tried with PawnIOUtil.exe test SmbusIntelSkylakeIMC.amx and it says "failed loading PawnIO module: 80070057". To sanity check, I built LpcIO.p and tried loading that .amx as well, and got the same error. I've uninstalled and reinstalled PawnIO multiple times, choosing the unrestricted edition each time. Windows is in test signing mode and shows the watermark (Windows 10 Pro Build 19041). I never had these issues running on my other machine. This is using a really old install of Windows that I hadn't touched in years and was installed without UEFI so I'm not sure if that matters. I can try pulling the drive from my other PawnIO development machine and booting it on this one later. Also, I noticed the version of the Pawn compiler is newer than the one mentioned in the wiki, not sure if that matters. I got some build errors trying to build SmbusNCT6793 and SMBusI801 that I know weren't there previously.

Please note that you need to use an older PawnIO unrestricted version as the current 2.2.0 does not work.

#1 (comment)

I am able to load this now after downgrading PawnIO but it does not seem to be working for me. OpenRGB loads it but trying to use the i2cdetect functionality with either quick or read operations returns no detected devices. I installed RWEverything to look at the PCI devices and looking at Bus 16, Device 1E, Function 05 I am not seeing any data change when issuing commands with this PawnIO driver. I am not doing anything special when initializing this driver, do I need to set index?

Also, the PCI ID that OpenRGB sees for this is 8086:2085/8086:0000, is that normal?

I am able to load this now after downgrading PawnIO but it does not seem to be working for me. OpenRGB loads it but trying to use the i2cdetect functionality with either quick or read operations returns no detected devices. I installed RWEverything to look at the PCI devices and looking at Bus 16, Device 1E, Function 05 I am not seeing any data change when issuing commands with this PawnIO driver. I am not doing anything special when initializing this driver, do I need to set index?

As far as I remember that i2cdetect is not going to work.

Please see my e-mail. Test / Debug it with RAMSPDToolkit and see if that works for you.
Then compare what you are doing vs. what it is doing.
I'll add the new signed binaries to it in a bit, so you can just start it.

Also, the PCI ID that OpenRGB sees for this is 8086:2085/8086:0000, is that normal?

Intel device & 0x2085 seems to be correct, yes.

I just added a bunch of debug_print statements and also added initializing the index to OpenRGB. I now create two instances, one at index 0 and one at index 1. I am able to i2cdetect using the READ_DATA method and i2cdump SPD addresses.

I2C Detect on Index 0:

I2C Detect on Index 1:

I2C Dump of 0x50 on Index 0:

So it looks like I can access SPD. However, QUICK and BYTE (not BYTE_DATA) operations don't seem to work. I believe OpenRGB requires BYTE operations in many places but can operate without QUICK. Also, it did not detect anything outside of the SPD range and I know address 0x27 should show up because I have a single HyperX Predator DDR4 stick on each side of the CPU. I also have some ENE DRAM which I believe should be at 0x77 in its default state (these get remapped by software during detection normally).

Looking at SPD_OPCODE and TSOD_OPCODE these look like they might just be bit shifted from the upper bits of the address?

I'm definitely on to something with that observation.

In PrepareImcTransfer:

        offset = command & 0xFF;
        opcode = (addr & 0xF0) >> 3;
        slot = addr & 0x0F;

        return STATUS_SUCCESS;

Now I get this for Index 0 when doing a detect:

Also it detected two ENE DRAM but they are broken due to the lack of proper transfer ops. It saw them at addresses 0x77 on both buses.

Edit:

Dumping 0x77 shows the incrementing pattern we expect from ENE chips when detecting them with standard 1-byte register access. We check I believe 0xA0-0xAF to see that they are incrementing to determine a given address is ENE.

QUICK and BYTE (not BYTE_DATA) operations don't seem to work.

They are not implemented yet.

It looks like your SetBankCore function is just using the same command pipeline to issue the 1 or 0 write to 0x36? I'm not sure why this needs special case handling, none of the other SMBus modules do this. I would think the standard program flow that allows for any registers to be written would be sufficient. It seems like you've added a lot of SPD-specific code paths in this code that could be omitted by allowing full access to any address.

Edit:
I took out the custom handling for bank switching and just use the normal pipeline with my address modification. If I dump 0x36 (to trigger an access, switching bank), dump 0x50, then dump 0x37 to switch bank again, and then dump 0x50 again, I do see the two different SPD banks.

Please feel free to adjust it. I've only tested it for what I require.

I'll continue this investigation in my MR #62