BTW this is what found on the smbus by the script 'sensors-detect'
after loading all that up. Not sure it helps anything. Still same
error code from the driver afterwards. -6
Next adapter: SMBus I801 adapter at f000 (i2c-2)
Do you want to scan it? (YES/no/selectively): yes
Client found at address 0x18
Handled by driver `jc42' (already loaded), chip type `jc42'
Client found at address 0x1a
Handled by driver `jc42' (already loaded), chip type `jc42'
Client found at address 0x50
Handled by driver `ee1004' (already loaded), chip type `ee1004'
(note: this is probably NOT a sensor chip!)
Client found at address 0x52
Handled by driver `ee1004' (already loaded), chip type `ee1004'
(note: this is probably NOT a sensor chip!)
Now follows a summary of the probes I have just done.
Just press ENTER to continue:
Driver `nct6775':
* ISA bus, address 0x290
Chip `Nuvoton NCT6793D Super IO Sensors' (confidence: 9)
Driver `jc42':
* Bus `SMBus I801 adapter at f000'
Busdriver `i2c_i801', I2C address 0x18
Chip `jc42' (confidence: 6)
* Bus `SMBus I801 adapter at f000'
Busdriver `i2c_i801', I2C address 0x1a
Chip `jc42' (confidence: 6)
Driver `coretemp':
* Chip `Intel digital thermal sensor' (confidence: 9)
Do you want to overwrite /etc/sysconfig/lm_sensors? (YES/no): yes
Unloading cpuid... OK
[id:/] $
On Tue, Apr 16, 2019 at 8:58 PM Dreamcat4 <dreamcat4@xxxxxxxxx> wrote:
>
> 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.
