分享

i2cToolsDocumentation – lm

 WUCANADA 2015-04-24

I2C and ISA Tools Documentation ?

This page documents our I2C and ISA debugging tools i2cdetect, i2cdump, isadump, i2cget, i2cset and isaset.

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.

Here is a summary of the tools:

I2C bus ISA bus
Bus scanning i2cdetect --
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.

0 1 2 3 4 5 6 7 8 9 a b c d e f
00 battery
charger
battery
manager
smart
battery
10 sensor sensor sensor
20 sensor sensor sensor sensor
30 eeprom eeprom eeprom eeprom eeprom eeprom eeprom eeprom
40 sensor sensor sensor sensor sensor sensor sensor sensor
50 eeprom eeprom eeprom eeprom eeprom eeprom eeprom eeprom
60 clock
70 FSC
sensor

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.

isadump ?

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

See also: i2cget(8) man page, i2cset(8) man page

isaset ?

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

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。
    转藏 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多