ruedigergad

While Nemo/Mer runs reasonably well on N9/N950 there is a little annoying issue: the battery status is not correctly displayed. Reason for this is that there is currently no driver for querying the required information from the battery gauge chip yet.

With the command “upower -d” information about the battery status as “seen” by the system can be queried. By default, in the current stage, this will show output that is not much helpful as we are missing the required drivers.

The battery gauge chip can be accessed via the i2c bus number 2 at address 0x55. At least this seems to be the right chip.

For gathering data from the i2c bus and for interacting with the chip the programs from the “i2c-tools” package can be used. Via, e.g., “i2cdump -y 2 0x55 b” the current “state” of this chip can be dumped to console.

Furthermore, “commands” can be sent to the chip by writing words to the first address of the chip. “Return” values can then be read from the same address. E.g., writing 0x0001 returns 0x0521:

[root@localhost ~]# i2cset -y 2 0x55 0x00 0x0001 w
[root@localhost ~]# i2cget -y 2 0x55 0x00 w
0x0521

From experiences with the N900, the battery gauge chip could be a chip manufactured by Texas Instruments. Assuming this, the above command could indicate the device type being a bq27521. This would at least match what is defined in the specification for a similar chip, the bq27520. Looking at the file system seems to verify that we are dealing, in fact, with a bq27521:

[root@localhost ~]# find /usr/ -name "bq*"
/usr/lib/hwi/ic/bq24153.so
/usr/lib/hwi/ic/bq24156.so
/usr/lib/hwi/ic/bq27521.so

However, the data that can be queried with i2cdump looks highly differing from what is defined in this specification and so far I could not find a specification of an bq27521 yet.

So the first try is to identify the meanings of the different fields of the chip. In order to do so I queried data over a longer period using the following script:

#!/bin/sh

while : ;
do
date >> i2c_data.out
i2cdump -y 2 0x55 b | head -n 5 >> i2c_data.out
echo "" >> i2c_data.out
sleep 30s ;
done

The raw results, notes, and some observations can be found in form of text files at github. So far I came up with the following guesses:

Note that the data seems to be organized in words of 2 bytes. The byte order or endianess seems to be little endian; i.e., the least significant byte is stored at the lower address. The following is an excerpt of the observations that can be found on github.

The following shows a summary of the findings.
"C" indicates the fields used for command I/O including the "display" of "returned" values.
"k" indicates fields that had so far observed containing constant values.
"v" indicates fields with variable values.
"B" is used to indicate the fields for which so far only two different "states" could be observed.

0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00: CC CC kk kk kk kk kk kk kk kk vv vv vv vv vv vv
10: vv vv vv vv vv vv kk kk kk kk kk kk kk kk kk kk
20: kk kk kk kk kk kk BB BB BB kk kk kk kk kk kk kk
30: kk kk kk kk kk kk kk kk kk kk kk kk XX XX XX XX

Wild Guesses:
0x0a+0x0b -> Voltage [mV]?
0x0c+0x0d -> Available Energy [mWh], Remaining Capacity [mAh]?
(This seems to have a much higher resolution than 0x12+0x13.)
0x0e+0x0f -> Time To Full [Minutes]?
0x10+0x11 -> Similar to 0x0e+0x0f?
They show very similar data.
0x12+0x13 -> State of Charge [%]?
0x14+0x15 -> AtRate [mA], Average Current [mA]?
Can be used to calculate a difference between subsequent measurements.
Else, this would be pretty useless.

Finally, the battery gauge chip in the N9 seems to be the same as in the N950. At least the output of i2cdump looks similar and using the 0x0001 command returns the same value.

Please see also the following thread on the MeeGo forum that contains very useful information: http://forum.meego.com/showthread.php?t=4610