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