On Tue, Apr 16, 2019 at 8:45 PM Peter Rosin <peda@xxxxxxxxxx> wrote: > > On 2019-04-16 20:34, Jean Delvare wrote: > > On Tue, 16 Apr 2019 18:13:00 +0100, Dreamcat4 wrote: > >> [root:/sys/bus/i2c/devices] # i2cdetect 2 > >> WARNING! This program can confuse your I2C bus, cause data loss and worse! > >> I will probe file /dev/i2c-2. > >> I will probe address range 0x03-0x77. > >> Continue? [Y/n] y > >> 0 1 2 3 4 5 6 7 8 9 a b c d e f > >> 00: -- -- -- -- -- 08 -- -- -- -- -- -- -- > >> 10: -- -- -- -- -- -- -- -- 18 -- 1a -- -- -- -- -- > >> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > >> 30: 30 31 -- -- 34 35 UU UU -- -- -- -- -- -- -- -- > >> 40: -- -- -- -- 44 -- -- -- -- -- -- -- -- -- -- -- > >> 50: UU -- UU -- -- -- -- -- -- -- -- -- -- -- -- -- > >> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > >> 70: -- -- -- -- -- -- -- -- > >> [root:/sys/bus/i2c/devices] # > >> [root:/sys/bus/i2c/devices] # cd ~ > >> [root:~] # ./decode-dimms.new > >> Cannot read /sys/bus/i2c/drivers/ee1004/2-0050/eeprom at > >> ./decode-dimms.new line 2358. > >> [root:~] 6 # > >> > >> > >> See that? The UU was not there before I ran those 2 commands. So it is > >> almost definately not something else blocking the port. Those UU are > >> our driver. That is the only new information here. Everything else was > >> same as before. > > > > This is correct, all UUs above are from the ee1004 driver. However it > > doesn't mean that there isn't another device on the SMBus also > > responding to I2C address 0x36. As long as it doesn't have a Linux > > driver bound to it, it won't show as UU (busy) in the output of > > i2cdetect. > > If there is some other device responding to 0x36/0x37, then it didn't > respond in the first (elided) dump with no ee1004 driver bound. So, that > seems unlikely. No? That was also my assumption. All i really know is that these ASUS rog boards have a lot of closed / proprietary custom outboard chips on them for overclocking, controlling a lot of things in hardware. And that there are a wealth of options in the BIOS. The main ones are labelled TPU, and iROG 1,2,3 etc. > > For reference the elided dump I referred to was: > > > [root:/sys/bus/i2c/devices] # i2cdetect 2 > > WARNING! This program can confuse your I2C bus, cause data loss and worse! > > I will probe file /dev/i2c-2. > > I will probe address range 0x03-0x77. > > Continue? [Y/n] y > > 0 1 2 3 4 5 6 7 8 9 a b c d e f > > 00: -- -- -- -- -- 08 -- -- -- -- -- -- -- > > 10: -- -- -- -- -- -- -- -- 18 -- 1a -- -- -- -- -- > > 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > 30: 30 31 -- -- 34 35 -- -- -- -- -- -- -- -- -- -- > > 40: -- -- -- -- 44 -- -- -- -- -- -- -- -- -- -- -- > > 50: 50 -- 52 -- -- -- -- -- -- -- -- -- -- -- -- -- > > 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > 70: -- -- -- -- -- -- -- -- > > But why is there no response for those addresses when there is no > driver bound? Will they only ack writes or something? I don't know > anything about these DDR4 SPDs... > > Cheers, > Peter > > > That would be stupid hardware design though, and would require extra > > engineering effort because the BIOS *needs* to be able to access page 0 > > of the SPDs. So I'm not saying it's what is happening. But as we have > > no other explanation at this point, all bets are off. > > > > BTW you have temperature sensors on these memory modules (I2C addresses > > 0x18 and 0x1a). I don't know if the DDR4 module sensors are compatible > > with DDR3 but if they are then maybe you can use the jc42 driver to get > > the readings. Thank you for this tip about the DDR4 temperature sensor Jean. I can confirm that: After doing these manual steps # ====== # try to get ddr4 ram timimngs info / read spd sudo bash -l modprobe ee1004 cd /sys/bus/i2c/devices ls modprobe i2c-dev modprobe i2c-i801 ls i2cdetect 2 echo ee1004 0x50 > /sys/bus/i2c/devices/i2c-2/new_device echo ee1004 0x52 > /sys/bus/i2c/devices/i2c-2/new_device cd ~ ./decode-dimms.new # for tridentz memory sensors # BTW you have temperature sensors on these memory modules (I2C addresses # 0x18 and 0x1a). I don't know if the DDR4 module sensors are compatible # with DDR3 but if they are then maybe you can use the jc42 driver to get the readings modprobe jc42 # then relaunch psensor Then psensor will show 2 new sensors, both labelled 'temp1' and 'temp1'. It might be better recognized after another run of 'sensors-detect'. Anyhow the essential commands were: modprobe ee1004 modprobe i2c-i801 echo ee1004 0x50 > /sys/bus/i2c/devices/i2c-2/new_device echo ee1004 0x52 > /sys/bus/i2c/devices/i2c-2/new_device modprobe jc42 # then relaunch psensor And indeed the 2 new sensors readings values seem to be 'real' for ram. updating independently of each other at about 39c or 40c. So it does works for this Tridentz kit of DDR4, the full SKU of that on is: F4-3200C15D-32GTZ (red stripe / accent color, no RGB) After we swapped it out, it is not the same initial kit of Crucial Ballistix one mentioned in the Subject line of this email thread. Maybe it helps others.
