Closed uxigene closed 3 years ago
I don't know how "RGB Fusion Ready" device works but it would be great to have those devices work with liquidctl.
I checked the OpenRGB implementation and these memory modules use (as expected) a simple protocol over SMBus for LED control. Do they also support temperature monitoring?
It is probably fairly easy to write a driver to support them on Linux. This would initially be limited to Intel x86 boards, due to current limitations in how we read SPD data (which we use to match compatible devices), but supporting AMD boards is already something we are interested in: we just need some help from folks with these boards.
To work on SMBus drivers we usually insist in having SMBus traffic captures. On AMD boards that (apparently) can be done just with software, but on Intel boards I've had to resort to hardware sniffing; luckily the required hardware tools and skills set is minimal, and doing that turns out to be a fun one-day project.
Anyway, as the OpenRGB implementation suggests that protocol is fairly simple, and assuming it already works well, we could also try to implement our driver based on sole on our understanding of the OpenRGB codebase. But that has some risks, as SMBus devices don't always tolerate mistakes, and it would be easier for us to miss something... Edited out: proposing to relax our policy was a bad idea.
(All of) that said, it seems that you're a Mac user, and getting the driver to work on Mac or Windows would requires us to first implement basic SMBus access on those platforms, that lack standardized and accessible APIs for that.
P. S. Please do not ignore or remove checklists in our issue template.
@jonasmalacofilho Hello. Updated the issue with all information that I have. Regarding your question as far as I know there is no temperature monitoring, but I could be wrong. And yes I'm Mac/Windows user.
Thanks!
Can you try to get a dump of the SPD data for one of the modules?
Note: this may contain the module's serial number, feel free to replace all chars/digits with X
s.
@jonasmalacofilho It is in the issue description.
$ system_profiler SPMemoryDataType
Memory:
Memory Slots:
ECC: Disabled
Upgradeable Memory: Yes
BANK 0/ChannelA-DIMM0:
Size: 16 GB
Type: DDR4
Speed: 3200 MHz
Status: OK
Manufacturer: Kingston
Part Number: KHX3200C16D4/16GX
Serial Number: xxxxxx
I saw that, but the full SPD dump contains a bit more than that. Even though we don't use most of it, or that some fields I can safely infer, one particular thing I was interested in was whether the SPD reports the presence of a temperature sensor.
Ok, I'll try to do that. Not sure how I can do that on Mac OS.
I actually don't know how to get a dump of SPD data in Mac OS. In fact, knowing which software does that on Mac could help (since liquidctl will also need to access the SPD), so please let us know which tools you ended up using.
Did that under Windows. Hope it helps.
$ wmic memorychip get /format:LIST
Attributes=2
BankLabel=BANK 0
Capacity=17179869184
Caption=Physical Memory
ConfiguredClockSpeed=3200
ConfiguredVoltage=1200
CreationClassName=Win32_PhysicalMemory
DataWidth=64
Description=Physical Memory
DeviceLocator=ChannelA-DIMM0
FormFactor=8
HotSwappable=
InstallDate=
InterleaveDataDepth=2
InterleavePosition=1
Manufacturer=Kingston
MaxVoltage=1200
MemoryType=0
MinVoltage=1200
Model=
Name=Physical Memory
OtherIdentifyingInfo=
PartNumber=KHX3200C16D4/16GX
PositionInRow=
PoweredOn=
Removable=
Replaceable=
SerialNumber=XXXXXXXX
SKU=
SMBIOSMemoryType=26
Speed=3200
Status=
Tag=Physical Memory 0
TotalWidth=64
TypeDetail=128
Version=
Thanks. I also found some Thaiphoon screenshots online that complement that.
For future reference, these modules don't appear to support temperature monitoring, according to the SPD data.
We have a policy of requiring substantially higher confidence for I²C/SMBus drivers, when compared with USB/USB HID ones.
Because of this we (the maintainers) can only help with the implementation, but it's essential that there's someone with actual access to the device working with us.
Additionally, even though we can use OpenRGB as a reference, I prefer to have access to raw/recent traffic captures, especially since it will be on us (not OpenRGB) to maintain any new code that we decide to include in liquidctl.
Thus, we'll need help with implementing the liquidctl driver, as well as with (for it to be useful for @evghenix) adding support for Mac OS to our underlying SMBus infrastructure. I encourage everyone interested and/or able to contribute.
@jonasmalacofilho please let me know how I can help. As I have the device I could try to sniff the traffic (but have no clue how) if necessary and do other useful things for you.
Thank you. What motherboard do you have?
It's Gigabyte Z390 Aorus Pro
There are couple of things you should try first, in software.
First, capturing the I²C traffic with i801 sniffer (executable built by Adam @ OpenRGB, source code). As far as I remember, just start the sniffer and then the program of interest, and monitor and copy/paste the output from the sniffer. That said, I haven't had luck using it on Z370 with either Corsair or ASUS programs; they apparently acquire an exclusive lock on the device.
You can also try dumping the SMBus registers from the memory modules, using either SIV or OpenRGB ("run with --i2c-tools
and the SMBus tools tab will be under Information"). But be careful, it's not safe to try to dump (and thus read) arbitrary devices (=addresses) on the SMBus. It also seems that not all HyperX modules use the same address ranges, so consider checking if OpenRGB can detect yours, and if so, on which addresses. And, again, RGB Fusion could block these tools too.
Alternatively, capturing this traffic in hardware is not actually that difficult.
It does require a cheap logic analyzer (~10 USD) and, preferably, a unpopulated DIMM (cheap but not always available) or DIMM adapter (~10 USD, but easy to find), so you can hook the analyzer to it, instead of directly to the motherboard. You will also need a multimeter, some jumper wires and a soldering iron.
Then you plug this "analyzer DIMM" contraption to the motherboard, just like with any other DIMM, and you're able to capture all traffic on the SMBus, without any restrictions.
This contraption looks something like bellow, and basically just (indirectly, in this case) connects some jumpers to the SMBus pins on the module, which are there for Serial Presence Detect (SPD) and the RGB controller. Then you just need to connect the logic analyzer to those leads.
I can give more specific recommendations if this is something you're interested in trying.
Thanks for the reply. I'll try to find this analyser.
For the logic analyzer, something like this should work, which is probably a Saleae Logic clone. It's hard to tell if it's a good or bad clone, but SMBus is a farily low frequency protocol, so even one of the worse clones will probably be more than enough.
(And sometimes you can get lucky: the one I got locally uses the same main chip as the real one, so it actually reaches the advertised sampling rate).
As the picture shows, I also used a DDR4 DIMM to SODIMM adapter because I couldn't find a blank DDR4 DIMM at the time, and also because the adapter has convenient pads for a replacement SPD EEPROM, which means I can solder my jumpers to those pads, instead of directly to the smaller DIMM connector pins.
Finally, software-wise I used PulseView, which is a GUI for sigrok. And you can also use Saleae software with the clones.
Regardless of whether you solder to some EEPROM pads or directly to the connector pins, double check with the DDR4 spec that you're going to connect the logic analyzer to the correct pins, and that there are no shorts.
Let me know (here or on Discord) if you want me to go over this with you before actually plugging your contraption into the motherboard.
Triage: close without fixing (due to the platforms mentioned in this issue)
At this time, the maintainers don't plan to pursue SMBus/I²C support for platforms other than Linux, and Mac/Windows are the only platforms of interest for this issue's author. Contributions in the area of SMBus/I²C support for Windows, Mac and/or BSDs would be most welcome.1
And if there are users interested in HyperX Predator DDR4 support on Linux, please open a new issue for it and let us know.
1 We also need some help on Linux with SPD decoding on AMD boards, due to differences between the i801_smbus
(Intel) and piix4_smbus
(AMD) SMBus kernel drivers.
HyperX Predator RAM.
HyperX is RGB fusion ready. This means that it can be controlled using RGB fusion software but it does not work with liquidctl.
The device appears to support the following features:
The device is connected to the host system using:
The device communicates with the host system using:
Additional information:
Finally, I can help with:¹
¹ Assuming documentation and/or assistance will be provided.