Identifying i2c devices on Asus P8P67 sandybridge motherboard
I recently got a new Asus P8P67 Pro motherboard with a sandybridge core i5 2500K. After checking the Intel chipset docs, I found that it has an i2c controller and it was enumerated on the pci bus, but no driver was loaded for it. I found the i2c-i801 module and the comments in the source say it supports the Cougar Point (PCH) and matches the PCI ID. I'm not sure why it wasn't auto loaded, but after loading it, it seemed to work.
At that point I ran sensors-detect, which failed to recognize any known controllers on the bus, but i2c-detect found several addresses that responded. How can I proceed with identifying what these devices are, so that I can hopefully find or write a driver to communicate with them?
A message that is not in the archive (sent off-list or not yet received): [email protected]
Hi Phillip,
Quoted 7 lines · Phillip Susi
I recently got a new Asus P8P67 Pro motherboard with a sandybridge core i5 2500K. After checking the Intel chipset docs, I found that it has an i2c controller and it was enumerated on the pci bus, but no driver was loaded for it. I found the i2c-i801 module and the comments in the source say it supports the Cougar Point (PCH) and matches the PCI ID. I'm not sure why it wasn't auto loaded, but after loading it, it seemed to work.
Probably because you run a distribution where someone stupidly blacklisted i2c-i801 because it caused trouble on one single machine once. And you should report this as a bug.
Quoted 4 lines
At that point I ran sensors-detect, which failed to recognize any known controllers on the bus, but i2c-detect found several addresses that responded. How can I proceed with identifying what these devices are, so that I can hopefully find or write a driver to communicate with them?
All recent desktop boards from Asus implement an ACPI device named ATK0110 for hardware monitoring, which is supported by the asus_atk0110 driver. So if all you are interested in is hardware monitoring, that's the way to go.
If you really want a complete analysis of what may be on your SMBus, please share the output of i2cdetect with us. You can get register dumps from most devices using i2cdump, however I would NOT recommend doing this on all addresses randomly, as some devices are known to misbehave when accessed in a way they do not expect.
Signature · 1 line
Jean Delvare
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 3 lines · Jean Delvare
Probably because you run a distribution where someone stupidly blacklisted i2c-i801 because it caused trouble on one single machine once. And you should report this as a bug.
Good call.
Quoted 4 lines
All recent desktop boards from Asus implement an ACPI device named ATK0110 for hardware monitoring, which is supported by the
asus_atk0110driver. So if all you are interested in is hardware monitoring, that's the way to go.
That would show up in /sys/bus/acpi/ATK0110 right? I don't seem to have it, nor any mention of "ATK" in the DSDT. It also looks like the DSDT does not define the smbus interface.
Quoted 5 lines
If you really want a complete analysis of what may be on your SMBus, please share the output of i2cdetect with us. You can get register dumps from most devices using i2cdump, however I would NOT recommend doing this on all addresses randomly, as some devices are known to misbehave when accessed in a way they do not expect.
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- 08 -- -- -- -- -- -- --
10: -- -- -- -- -- 15 -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- 44 -- -- -- -- -- -- -- -- -- -- -- 50: 50 -- 52 -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 6e -- 70: -- -- -- -- -- -- -- --
I am guessing that 50 and 52 are the SPD eeproms on my dimms, but what could the others be? Also sensors-detect did not identify them as SPD eeproms. I loaded the eeprom module and looked at the data it pulled out of them and it does appear to contain an ascii string that is the part number of the dimms, but decode-dimms does not seem to like it.
A message that is not in the archive (sent off-list or not yet received): [email protected]
Philip,
Quoted 7 lines · Phillip Susi
Quoted 3 lines · Jean Delvare
Probably because you run a distribution where someone stupidly blacklisted i2c-i801 because it caused trouble on one single machine once. And you should report this as a bug.
Good call.
Quoted 8 lines
Quoted 4 lines
All recent desktop boards from Asus implement an ACPI device named ATK0110 for hardware monitoring, which is supported by the
asus_atk0110driver. So if all you are interested in is hardware monitoring, that's the way to go.That would show up in
/sys/bus/acpi/ATK0110right? I don't seem to have it, nor any mention of "ATK" in the DSDT. It also looks like the DSDT does not define the smbus interface.
It would show up as:
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:03/ATK0110:00 /sys/bus/acpi/devices/ATK0110:00
or similar.
BTW, what kind of hardware monitoring and/or fan control features does your BIOS offer?
Quoted 16 lines
Quoted 5 lines
If you really want a complete analysis of what may be on your SMBus, please share the output of i2cdetect with us. You can get register dumps from most devices using i2cdump, however I would NOT recommend doing this on all addresses randomly, as some devices are known to misbehave when accessed in a way they do not expect.
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- 08 -- -- -- -- -- -- --
10: -- -- -- -- -- 15 -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- 44 -- -- -- -- -- -- -- -- -- -- -- 50: 50 -- 52 -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 6e -- 70: -- -- -- -- -- -- -- --
Quoted 1 line
I am guessing that 50 and 52 are the SPD eeproms on my dimms,
Correct.
Quoted 1 line
but what could the others be?
08 and 44 are SMBus internal addresses, i.e. not real chips. This leaves 15 and 6e, which do not correspond to anything I know. Sensors-detect does not even scan them.
Quoted 4 lines
Also sensors-detect did not identify them as SPD
eeproms. I loaded the eeprom module and looked at the data it pulled out of them and it does appear to contain an ascii string that is the part number of the dimms, but decode-dimms does not seem to like it.
This is strange. Can you please send me a dump of these SPD EEPROMs?
# modprobe i2c-dev # rmmod eeprom # i2cdump <bus_nr> 0x50 b > /tmp/eeprom-0x50.dump # i2cdump <bus_nr> 0x52 b > /tmp/eeprom-0x52.dump
where <bus_nr> is the I2C bus number of your Intel SMBus.
Back to your hardware monitoring issue, Asus tends to use the integrated sensors in the Super-I/O on desktop boards. So odds are that you have a very recent Super-I/O chip sensors-detect doesn't know. From pictures found on the web, it seems to be a Nuvoton NCT6776F, for which we indeed have no support yet.
Signature · 2 lines
Jean Delvare http://khali.linux-fr.org/wishlist.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 4 lines · Jean Delvare
It would show up as:
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:03/ATK0110:00
/sys/bus/acpi/devices/ATK0110:00
That's what I thought. Don't have it.
Quoted 2 lines
BTW, what kind of hardware monitoring and/or fan control features does your BIOS offer?
Asus calls it Q-fan. It does seem to automatically throttle the fan speed in response to temperature. It has two 4 pin PWM headers and two 3 pin headers on the board, and the bios config has options to enable fan speed control on either of the 4 pin headers.
Quoted 1 line
This is strange. Can you please send me a dump of these SPD EEPROMs?
Will get it to you when I get back home tonight.
Quoted 5 lines
Back to your hardware monitoring issue, Asus tends to use the integrated sensors in the Super-I/O on desktop boards. So odds are that you have a very recent Super-I/O chip sensors-detect doesn't know. From pictures found on the web, it seems to be a Nuvoton NCT6776F, for which we indeed have no support yet.
I began to suspect as much. Do you know if anyone is working on a driver for it, or if the data sheet is available so I could take a crack at it?
Then again, I wonder if it might be better to come up with an SSDT I can dynamically load to define the ACPI FAN and TZ objects and let the regular acpi driver manage it.
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 9 lines · Phillip Susi
Quoted 5 lines
Back to your hardware monitoring issue, Asus tends to use the integrated sensors in the Super-I/O on desktop boards. So odds are that you have a very recent Super-I/O chip sensors-detect doesn't know. From pictures found on the web, it seems to be a Nuvoton NCT6776F, for which we indeed have no support yet.
I began to suspect as much. Do you know if anyone is working on a driver for it, or if the data sheet is available so I could take a crack at it?
I have gotten ahold of the data sheet for the chip so hopefully will be able to write a driver for it, but maybe we should move this conversation to the lm-sensors mailing list?
Before we do though, I sill have one more question about the i2c bus. My understanding is that simple i2c devices use fixed addresses, like the SPD EEPROMs, but SMBus devices initially respond to a broadcast address where they can be detected and dynamically assigned an address.
Is there a tool that can perform such a reset and enumeration that
could give better identification of those two unknown devices, should they be smbus compatible and not just i2c? When I tried reading them with i2c-dump I just got a bunch of XXs.
A message that is not in the archive (sent off-list or not yet received): [email protected]
Hi Phillip,
Quoted 3 lines · Phillip Susi
I have gotten ahold of the data sheet for the chip so hopefully will be able to write a driver for it, but maybe we should move this conversation to the lm-sensors mailing list?
Yes, definitely.
Quoted 4 lines
Before we do though, I sill have one more question about the i2c bus. My understanding is that simple i2c devices use fixed addresses, like the SPD EEPROMs, but SMBus devices initially respond to a broadcast address where they can be detected and dynamically assigned an address.
Things aren't that simple. SMBus devices _can_, optionally, reply to the SMBus ARP address (0x61) for identification and/or dynamic address allocation. They don't have to, and I've never seen any hardware monitoring ASIC requiring this (all I've seen start with a suitable static address.)
Quoted 2 lines
Is there a tool that can perform such a reset and enumeration that
could give better identification of those two unknown devices, should
No, there is no such tool. Proper SMBus ARP support would be done by the kernel, but it is not yet implemented on Linux.
Quoted 2 lines
they be smbus compatible and not just i2c? When I tried reading them with i2c-dump I just got a bunch of XXs.
Even for the EEPROMs? This would be strange. OTOH this would explain why decode-dimms did not work. But OTOH it would be strange that i2cdetect would have worked if the SMBus isn't properly supported...
Could you please try i2cdetect again? It is possible that the detection somehow confused your SMBus (at an address >= 0x6e), in which case i2cdetect will no longer work. This is usually fixed by a cold boot of the system. You can also look for i2c-i801 related error messages in your kernel logs.
Signature · 1 line
Jean Delvare
Quoted 10 lines · Phillip Susi
Quoted 5 lines · Jean Delvare
Back to your hardware monitoring issue, Asus tends to use the integrated sensors in the Super-I/O on desktop boards. So odds are that you have a very recent Super-I/O chip sensors-detect doesn't know. From pictures found on the web, it seems to be a Nuvoton NCT6776F, for which we indeed have no support yet.
I began to suspect as much. Do you know if anyone is working on a driver for it, or if the data sheet is available so I could take a crack at it?
No, the device isn't even listed on lm-sensors.org's wiki, I am not aware of anyone working on it.
The datasheet isn't available for download from Nuvoton, but can probably be requested from them.
Quoted 3 lines
Then again, I wonder if it might be better to come up with an SSDT I can dynamically load to define the ACPI FAN and TZ objects and let the regular acpi driver manage it.
What an horrid idea. The ACPI FAN and TZ interfaces are very limited. If the ACPI BIOS doesn't block access to the NCT6776F's I/O ports, you'll be much better with a native driver.
OTOH I admit I am surprised to see Asus move away from the ATK0110.
Signature · 1 line
Jean Delvare