|Version 3 (modified by khali, 5 years ago)|
I2C and ISA Tools Documentation
These tools can be invaluable for hardware monitoring device identification and troubleshooting.
The ISA tools are included in the lm_sensors package in the directory prog/dump. The I2C tools used to be included the lm_sensors package as well, but how live in their own separate package named i2c-tools. They are low-level tools that should be used only after you have run our high-level user tool, sensors-detect. The latest sensors-detect script in our repository can always be found here.
Here is a summary of the tools:
|I2C bus||ISA bus|
|Device register dumping||i2cdump||isadump|
|Device register reading||i2cget||--|
|Device register setting||i2cset||isaset|
All i2c tools operate on a specific i2c bus which is identified by number. The applicable i2c bus driver must be installed first. The bus numbers are assigned in the order the i2c bus drivers are installed.
The i2c bus number assignments can be listed by i2cdetect -l.
Using I2C tools for device identification
This is a small step-by-step example that is intended to give you an idea on how these tools can be used. Before you go on, please note that it is possible to break your hardware with these tools. Therefore you should be very careful when using them, you should know what you are doing and why you are doing it. If you don't really know what you are doing and you can't afford losing part of your hardware, please stop now.
Step 1: Identify the I2C buses
Here is an example of using i2cdetect to query an i2c bus.
# i2cdetect -l i2c-0 smbus SMBus ALI15X3 adapter at e800 Non-I2C SMBus adapter i2c-1 i2c I2C Voodoo3/Banshee adapter Bit-shift algorithm i2c-2 i2c DDC Voodoo3/Banshee adapter Bit-shift algorithm
See also: i2cdetect(8) man page
Step 2: Query the I2C bus
It is apparent that bus 0 is the motherboard's SMBus. Use the bus number 0 as the argument to i2cdetect:
# i2cdetect 0 WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-0. I will probe address range 0x03-0x77. Continue? [Y/n] 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- 2d -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- 48 49 -- -- -- -- -- -- 50: 50 51 52 -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- 69 -- -- -- -- -- -- 70: -- -- -- -- -- -- -- --
See also: i2cdetect(8) man page
Step 3: Identify the likely sensors device
The i2cdetect output above shows devices at addresses 0x2d, 0x48, 0x49, 0x50-52, and 0x69.
From consulting the chart below we can attempt to figure out what chips are likely to be sensors. I2C devices generally appear at standard bus addresses as shown below. This chart may prove helpful in device identification. Beware that this is only a hint though, virtually any type of device can live at any I2C address.
So, back to our example above: the devices at 0x2d, 0x48, and 0x49 are probably sensors (actually a single Winbond hardware monitoring chip responding at three addresses). The devices at 0x50 - 0x52 are most certainly EEPROMs on the three SDRAM DIMMs installed on the motherboard. And the device at 0x69 would be a clock chip.
Step 4: Dump the I2C device registers
Here is an example of using i2cdump to view the registers of an i2c device. This is useful to developers debugging the driver for the device. Warning: it is strongly advised that you do not run i2cdump on a device unless you have a preliminary idea of what this device could be. If you are looking for a sensor chip, you only want to try the addresses in the ranges 0x18-0x1a, 0x2c-0x2f and 0x48-0x4f, as documented in the chart above (and, for Fujitsu-Siemens computers, 0x73). Other addresses are very unlikely to be sensor chips, and attempting to dump them could harm your system.
Use the bus number as the first argument and the chip address as the second argument:
# i2cdump 0 0x2d No size specified (using byte-data access) WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-0, address 0x2d, mode byte Continue? [Y/n] 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 20: 8a 8b de bb c9 d8 d0 1d ff ff aa c1 9e c1 9e e3 30: ba cc a8 d8 b2 ed c2 e4 bb 3c 32 e1 e1 e1 00 00 40: 01 c3 00 00 00 00 40 50 2d 01 01 40 01 95 00 a3 50: 10 01 80 ff ff ff 00 00 11 ff ff ff ff ff ff ff 60: 8a 8b de bb c9 d6 d1 1d ff ff aa c1 9e c1 9e e3 70: ba cc a8 d8 b2 ed c2 e4 bb 3c 32 e1 e1 e1 00 00 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff a0: 8b 8b de bb c8 d9 d1 1d ff ff ab c1 9e c1 9e e3 b0: ba cc a8 d8 b2 ed c2 e4 bb 3c 32 e1 e1 e1 00 00 c0: 01 c3 00 00 00 00 40 50 2d 01 01 40 01 95 00 a3 d0: 10 01 80 ff ff ff 00 00 11 ff ff ff ff ff ff ff e0: 8a 8a de bb c9 d8 d1 1d ff ff aa c1 9e c1 9e e3 f0: ba cc a8 d8 b2 ed c2 e4 bb 3c 32 e1 e1 e1 00 00
See also: i2cdump(8) man page
Step 5: Identify the device
From looking at the bottom of this document of supported devices, we can see that the value 0xA3 at location 0x4F identifies this device as likely manufactured by Winbond. From here we could go to the Winbond web site and attempt to identify the device by scanning datasheets. Another approach is to look on the motherboard for devices with a Winbond logo.
For devices on the ISA bus, use isadump instead of i2cdump. isadump takes two arguments, the address and data port addresses.
For the typical device which is located at a base address of 0x290, use the command line isadump 0x295 0x296. For a device using a 'flat' address space instead of address and data ports, use the command line isadump -f 0xbase where base is the base address in hex.
See also: isadump(8) man page
i2cget and i2cset
For advanced debugging you can use the i2cget and i2cset commands to read from, respectively write to, an I2C device. As for i2cdump, you should be very careful when using these commands, if you don't know what you're doing, chances are that you'll break something. The general usage is:
i2cget <bus> <chip> <register> i2cset <bus> <chip> <register> <value>
For example, the following writes the value 0x22 to register 0x10 of device 0x2d on i2c bus 0:
# i2cset 0 0x2d 0x10 0x22
For advanced debugging you can use the isaset command to write to an ISA device. It is the ISA equivalent of i2cset. Again, you better know what you are doing when using this command. The usage is:
isaset <addrreg> <datareg> <register> <value>
For example, the following writes the value 0x22 to register 0x10 of an ISA device present at address 0x290:
# isaset 0x295 0x296 0x10 0x22
See also: isaset(8) man page