cancel
Showing results for 
Search instead for 
Did you mean: 

DRAM support reverse engineering thread: history and current status

CX_gamer
Level 7
The discussion can be found here:

https://gitlab.com/CalcProgrammer1/KeyboardVisualizer/issues/85

Chronological highlights:


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.
478 Views
3 REPLIES 3

crashniels
Level 7
CX gamer wrote:
The discussion can be found here:

https://gitlab.com/CalcProgrammer1/KeyboardVisualizer/issues/85

Chronological highlights:


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
Level 7
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
I am an electrical engineer to save time let's assume I am always right!

CalcProgrammer1
Level 8
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.