liquidctl / liquidctl

Cross-platform CLI and Python drivers for AIO liquid coolers and other devices
GNU General Public License v3.0
2.23k stars 222 forks source link

HyperX Predator RAM Support #291

Closed uxigene closed 3 years ago

uxigene commented 3 years ago

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:

$ 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

Finally, I can help with:¹

¹ Assuming documentation and/or assistance will be provided.

uxigene commented 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.

jonasmalacofilho commented 3 years ago

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.

uxigene commented 3 years ago

@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.

jonasmalacofilho commented 3 years ago

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 Xs.

uxigene commented 3 years ago

@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
jonasmalacofilho commented 3 years ago

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.

uxigene commented 3 years ago

Ok, I'll try to do that. Not sure how I can do that on Mac OS.

jonasmalacofilho commented 3 years ago

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.

uxigene commented 3 years ago

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=
jonasmalacofilho commented 3 years ago

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.

jonasmalacofilho commented 3 years ago

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.

uxigene commented 3 years ago

@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.

jonasmalacofilho commented 3 years ago

Thank you. What motherboard do you have?

uxigene commented 3 years ago

It's Gigabyte Z390 Aorus Pro

jonasmalacofilho commented 3 years ago

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.

20201209_184259

I can give more specific recommendations if this is something you're interested in trying.

uxigene commented 3 years ago

Thanks for the reply. I'll try to find this analyser.

jonasmalacofilho commented 3 years ago

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.

jonasmalacofilho commented 3 years ago

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.