DRAM support reverse engineering thread: history and current status

[CX gamer]

The discussion can be found here:

https://gitlab.com/CalcProgrammer1/K...izer/issues/85

Chronological highlights:

• The poor CalcProgrammer1 bricked his board for us while researching..
• Aura Sync uses the I2C protocol, and it's possible to set the LEDs through it (here from linux).
• The Aura Service is doing the actual work, the .exe just calls the service to do the work for it.
• The Aura utility has an XML file which can be edited, after the service is restarted, the colors are applied.
• Apparently there already is an ASUS WMI Linux driver.
• CalcProgrammer1 created a custom Linux Kernel to make its I2C protocol more responsive.
• Codes of all modes
• Turns out the protocol for G.Skill RAM is the same as the Aura controller, this was the result.
• Since Windows doesn't have I2C drivers, ASUS made userspace drivers. This is what complicates the cross-platform-ness.
• Full DRAM control sample
  At this point the Aura Sync SDK is released.
• Asus said they were looking into DRAM support (1 year ago).

This leaves us with a partial working branch working on specific chipset, board and bios firmware combinations. It's possible to get it working if you identify your I2C controller on Linux. They're almost there, but it still needs some more work to generalize it for any system.

[crashniels]

The discussion can be found here:

https://gitlab.com/CalcProgrammer1/K...izer/issues/85

Chronological highlights:

• The poor CalcProgrammer1 bricked his board for us while researching..
• Aura Sync uses the I2C protocol, and it's possible to set the LEDs through it (here from linux).
• The Aura Service is doing the actual work, the .exe just calls the service to do the work for it.
• The Aura utility has an XML file which can be edited, after the service is restarted, the colors are applied.
• Apparently there already is an ASUS WMI Linux driver.
• CalcProgrammer1 created a custom Linux Kernel to make its I2C protocol more responsive.
• Codes of all modes
• Turns out the protocol for G.Skill RAM is the same as the Aura controller, this was the result.
• Since Windows doesn't have I2C drivers, ASUS made userspace drivers. This is what complicates the cross-platform-ness.
• Full DRAM control sample
  At this point the Aura Sync SDK is released.
• Asus said they were looking into DRAM support (1 year ago).

This leaves us with a partial working branch working on specific chipset, board and bios firmware combinations. It's possible to get it working if you identify your I2C controller on Linux. They're almost there, but it still needs some more work to generalize it for any system.

i don't know anything about reverse engineering but i think it is a bit easier now since it looks like the dram and even everything is separated from aura. they are in form of dlls and come installed with aura. maybe that will help a bit with all of this

[asder98]

Well, After days of tumbling around to figure out a way to control the DRAM, I thought that the RAM control is vendor cross compatible,. So you know Gigabyte has a properly working SDK that controls RAM, so i though I could give RGB fusion a try... IT JUST works... I installed RGB fusion on my x299 Rampage and it detects the RAM flawlessly and works like a charm. I 'll take a look at the SDK and I'll share a demo with you

[CalcProgrammer1]

I've started a new project and, with the help of some great contributions and research by other GitLab members, have a foundation in place for a fully open-source Aura control application. You can check it out here:

https://gitlab.com/CalcProgrammer1/OpenAuraSDK/

The project wiki has some information we've discovered about the register map of the Aura controller, which appears to be an I2C device. It seems at least a few RGB RAM kits use the same (or very similar) lighting controller and have the same register map. We also needed a way to talk to I2C (SMBUS) on Windows which isn't an easy thing to do, so I've ported the Linux drivers to Windows userspace for the PIIX4 (used by AMD) and i801 (used by Intel) SMBus controllers. This gives us a way to talk to the Aura controllers on Windows without using closed source Asus DLL's.

This is only for I2C/SMBus Aura devices at the moment, so no keyboards/mice/GPUs. A GitLab user mentioned that newer boards with the addressable strip header may be using USB for that particular header and looks to be doing his own investigation into that piece of hardware.

I think we have a reliable way of detecting the SMBus controller for any given motherboard now, so next step is to write code to detect the Aura devices themselves.