MSI Z270 Gaming Pro Carbon fun facts and discoveries

[habovh]

I just got my new mobo and GPUs, and wanted to try msi-rgb on a freshly installed Debian 9 'Stretch'.

Disclaimer: msi-rgb won't work (for the most part) with this motherboard.

However, I was able to control the RAM slot LED blinking and pulsing effect. I cannot change the color, nor turn it off, I can just make it blink or pulse, with any color value (even 0). Too bad it's only effecting the RAM slot LED when there are so much more LED's on this mobo 😬

Then I thought myself:

Well, I can print the output of various base ports, so I might as well go through them all and check if I can find a FF FF FF FF 00 00 00 00 00 00 00 00 pattern somewhere, and try to update it!

As it turns out, launching the program on base port 64 crashes. I got disconnected from SSH, but I'm not sure if I accidentally crashed the ethernet controller or something else, this was totally try-and-die technique.

Is there any easy way to explore the motherboard memory banks (I don't know how they're called, but I'm referring to the registers where the LED values are stored) without trying to change their values, and then change them "on the fly" to see what happens?

I'm just being curious right now! It would be great to make msi-rgb multi-motherboard compatible, maybe with a configuration file or so! The potential is here, I think we just need to be able to identify which banks are safe to update for any given motherboard 😊

I'd be glad to help and provide support for mine if you ever want to implement such a config file!

[nagisa]

Dumping the base ports won’t help you. In fact, it is very likely to cause real problems.

The process of “dumping” data from the SIO chip involves writing a request to a specific port to which the SIO chip is attached. Writing to another port would send the data to entirely different chip. Some of those could interpret the request as some command of their own. At best you’ll just crash (as you did), at worst you might break your system and/or its components.

Too bad it's only effecting the RAM slot LED when there are so much more LED's on this mobo 😬

It seems plausible that there could be a register which selects a specific set of LEDs to control -- and the RAM LEDs are selected by default.

The best way to help is to trace the execution of the MSI app on windows (and send the annotated traces to me), but it is not an easy thing to do.

[habovh]

Oh well, thanks for the clarification! I had no idea that just querying to read values from the SIO could cause problems, you may want to add a warning in the readme to prevent unexperienced users (like me) from doing nasty things.

Now I understand the process of how you eventually found on which ports to read and write from. I do not have Windows installed on my desktop, so it's unlikely I could get traces from MSI app. It would be even more unlikely as I have no idea on how to record such trace at all.

Anyway, nice piece of software and nice initiative! Too bad MSI just doesn't provide a documentation regarding this...

[ayufan]

@nagisa

Can you provide a document that outlines how to get a track from MSI app?

On your blogpost you had nice writeup https://kazlauskas.me/entries/i-reverse-engineered-a-motherboard.html here :) How to get this trace?

[nagisa]

There are two methods to do this:

1. using a debugger and a log breakpoint;
2. replacing a dll with another crafted in a very certain way.

I used (1) and I doubt it is something an average enthusiast can easily do without being overwhelmed. I considered making a replacement dll for a method (2), but that’s way down my list. Having a dll for (2) would greatly simplify development of support for other/new boards though.

[ayufan]

This dll is used by driver, or dll is for interacting with driver?

[ayufan]

It seems that we can use http://www.rohitab.com/apimonitor for easy monitor of DeviceIoControl. The question would be how to decipher the driver :)

[ayufan]

I moved this thread to https://github.com/nagisa/msi-rgb/issues/54