How to build a custom Linux kernel and install i2c/lm_sensors
If you downloaded the whole CD, you don't need to do this.
If you decide to build from source, you'll need to go through the
full kernel build&install procedure:
cd /usr/src/linux (wherever this symlink points)
make mrproper (careful, erases .config - make a backup first)
make symlinks
make menuconfig
make dep
make
make bzImage
make modules
make modules_install
Escpecially if you leave module versioning on, the build system
generates a new magic number each time you run 'make dep',
that is then used to "stamp" (decorate) all symbols in kernel modules.
In effect, once you run 'make dep' with module versions on,
you'll have to explicitly re-compile and re-install any external
modules, e.g. i2c and lm_sensors. Otherwise, upon insmod
you get error messages such as "undefined symbol function_name_335cxxt434()."
The kernel + lm_sensors configuration & build instructions are different for Linux 2.2
and for Linux 2.4. My proven-to-work testbeds are RedHat Linux 2.2.14 + i2c-2.6.4
and RedHat Linux 2.4.18 + i2c-2.7.0 + lm_sensors-2.7.0. With some of the
details I don't know whether to attribute them to i2c or the kernel, therefore
I list them together, the way they worked for me.
The i2c and lm_sensors packages should be available from www.lm-sensors.nu.
Note: don't turn ON the original i2c drivers that come with the original kernel sources from your distro - it is strongly recommended that you download the fresh i2c package.
There are about three different ways to compile i2c and lm_sensors
- the least disruptive way is perhaps the classic "tar xvzf tarball.tgz",
"make" and "make install". This way the package is compiled as stand-alone
modules that get installed in the correct place. You have yet to run "depmod -a",
which is however typically done automatically by the Linux boot process
(at least it works that way in my RedHat).
Alternatively, you can patch the kernel sources and hard-compile the drivers in
- which is nevertheless completely unnecessary. The stand-alone modular installation
seems safer to the kernel source tree, worked fine for me and the i2c package thus
installed works without a hitch.
To be able to compile i2c/lm_sensors, you'll need the following packages installed:
python, bison, byacc and flex.
Linux 2.2 + i2c-2.6.4
I recommend that you leave the parallel port driver "ON" and turn the printer
driver "OFF". In `make menuconfig', this can be achieved by toggling
"general setup"->"Parallel port support" ON,
"general setup"->"PC-style hardware" ON and
"Character devices"->"Parallel printer support" OFF.
In a standard kernel, the printer driver is ON,
which causes a failure when you try to load the i2c-pport module
("device in use") - sure, that's because the parallel port is occupied
by the printer driver.
You don't need the lmsensors application package - all you need is the bare
i2c support in the kernel, i.e. the i2c tarball.
Once we have a kernel without the printer driver, and the i2c modules
are installed, we can insert the modules:
modprobe i2c-core
modprobe i2c-dev
modprobe i2c-pport
Worked for me within the following environment:
RedHat 6.2 CZ with a more or less original 2.2.14 kernel
and the original GCC compiler (2.91.66).
All of that on a Compaq Presario 1622 notebook :)
Linux 2.4 + i2c-2.7.0
It seems that you have to turn parallel port support OFF
entirely, in the Linux kernel config.
You need to compile both i2c and lm_sensors.
You need to load the following modules:
modprobe i2c-core
modprobe dmi_scan
modprobe i2c-algo-bit
modprobe i2c-dev
modprobe i2c-proc
modprobe i2c-pport
Worked for me within the following environment:
RedHat 8.0 with a custom 2.4.18 kernel (the original 2.4.18-14,
RedHat flavor) and the original GCC compiler (RedHat 3.2-7).
All of that built on a desktop based on VIA KT333 with an Athlon XP 1700+,
but I had to actually run the software on different machines, because
the VIA KT333's parallel port didn't work for i2c-pport.
Device nodes for i2c
The documentation of the i2c package further describes how to create
the "device special files" /dev/i2c* using `mknod', unless you already
have them. If you're familiar with mknod, you only need to know the
major and minor device number. Try 'cat /proc/devices' to get the
major number (and verify that the i2c driver is loaded). The minor
numbers start with a zero in ascending order. You'll probably only
ever need /dev/i2c0. I myself had the devices ready out of
the box which has saved me the hassle with mknod.
The original BQ2092 story
Introduction - of batteries and screwdrivers
This material describes a reasonably simple way to have a nice chat over I2C with "smart" batteries of many notebook brands - which may be a necessary step in a successful battery refurbishment procedure. Is anyone outside of eastern Europe refurbishing notebook batteries, BTW?
Some time ago, I've purchased a second-hand Compaq Presario 1622 - an american model, possibly imported into the Czech Republic already as a pile of trash. It only needed to have its battery refurbished - which seemed to be "no great problem". By the mechanical finish, the battery refurbishment company I've chosen has done a great job - and they've enclosed a neat measurement protocol, certifying perfect condition and capacity. Unfortunately, once inserted back into the notebook, the battery didn't work properly - the notebook would report full charge after five minutes of charging, and full discharge after five minutes of operation on batteries, following up with an immediate shutdown.
As I needed to start to work with the notebook ASAP, I went to a brand service center. "That's the battery. It'll take two days to deliver - your notebook is a U.S. model". I asked them to check the charger inside the notebook, before I pay them an outrageous sum of money for a shiny new battery, that might ultimately be no use if the charger is broken. "Allright, our technician will take a look at it tomorrow. We'll charge you some additional money for the work, and if the bettery replacement doesn't fix the problem, we'll take the battery back." And that's exactly how we did it. It was indeed the battery. No problem that it took them a fortnight to deliver the battery. I didn't even mind coming twice to pick up my notebook just because they didn't have the battery out of stock the first time around (after they'd invited me).
As this was an after-guarantee part replacement / material purchase, I got my "broken" battery back from the service center. So I went to complain about the refurbishment to the refurbishment company. No problem here - they've apologized, reported that they'd found and replaced a misbehaving cell and provided an even neater measurement protocol.
Nevertheless, even after my complaint was thus processed, the battery didn't come back to life. Unfortunately I couldn't find a "battery formatting util" on the web or from friends (as I have found out later, it wouldn't help me anyway - see the technical description below.) So I took it as a challenge and ventured a frontal screwdriver attack at the battery. When I first opened the lid, I had to nod in appreciation upon the mechanical purity of the refurbishment. The refurbishment guys did a great job even on the inside.
The battery had a reasonable voltage, precisely identical across every cell. By the voltage and the typical discharge curve, it was charged to about 70 per cent - even though the notebook was reporting 0 per cent. It was also able to generate reasonable current, without dropping the voltage significantly. Unfortunately my homebrew electronics equipment and limited time didn't allow for a more detailed exploration, such as a proper capacity measurements etc.
I discovered that the battery contained a tiny PCB, with two SMT IC's on it: a larger one (a DIL16 package) and a smaller one (a DIL8). I managed to read the codes: the smaller one was an AT24C02 (clearly an I2C/serial EEPROM by Atmel) and the larger one was a BQ2092. And voila - it's called a "gas gauge", manufactured by Texas Instruments (originally by Unitrode, later acquired by TI), and there's a datasheet available. Cautious optimism :)
It didn't take long to discover that I can talk to the BQ2092 using its SMBUS port. The SMBUS is electrically compatible with I2C, SMBUS commands are a subset of I2C commands. The serial flash contains pre-programmed initial values and some run-time data - so that even if the PCB with BQ2092 loses power, e.g. during a cell refurbishment procedure, the gas gauge IC still remembers the old remaining capacity. The IC can be asked via I2C to perform a reset - later on I discovered that you need to power-cycle the IC to complete the reset (unsolder/resolder the battery of cells from/to the PCB). The I2C flash is connected to a "private" I2C port of the BQ2092 that is not directly accessible at the outer battery connector. The I2C flash could be accessed on the PCB using conductors with some sorta in-circuit probes - this way the gas gauge circuit can be callibrated.
I also remembered that there was some I2C support under Linux. It turned out that most of the software in Linux is written for a myriad of internal PC peripherials, such as heatsink temperature sensors, fan RPM counters, TV and radio tuners and whatever have you. It took me a while to find the parallel port driver by Daniel Smolik. I was also lucky that I already had previous experience with #including conflicting header files in GNU C/C++ - so that I managed to wrestle the direct inclusions of kernel headers within user-space code, which is a prerequisite for using the I2C library functions (macros). And in the end finally I had a nice conversation with my battery - I've retrieved a heap of data out of it, managed to interpret most of it, and finally I've also managed to reset it.
And I was lucky - even the mere reset has woken up the battery to pretty much normal operation :) Even though perhaps it would use some callibration. No time and no equipment for that, though.
For more technical information, read on.
A brief technical description
My battery contains NiMH cells, its nominal capacity is 3800 mAh at 9.6 V (eight cells). The manufacturer is a taiwanese OEM called GLW. Besides Presario 1600, the battery also fits into a Presario 1200. There's also a newer 4,5 Ah model in the same format, and a Li-Ion battery (3.6 Ah at 14.4V ). In other words, it would seem that the built-in charger of the notebook is indeed somewhat smart. GLW manufactures batteries for many different notebook brands and models. Some time ago, I myself was speculating about the outer pinout of a Li-Ion battery in a Compaq Armada M700 that I had in my previous job - the battery is smaller and the shape is different, but the number of pins is identical (five) and so is the power supply voltage (18.5 V), and a few simple electrical measurements were showing similar results to what I have later encountered with my current NiMH battery (that is certainly older by date of manufacture).
The battery is controlled (or perhaps I'd better say "monitored") by a built-in IC called BQ2092, that is communicating with the notebook via SMBus/I2C.
This image is just a poor-quality preview - you can check out the schematic in full quality in the
data sheet available from Texas Instruments.
You'd better download the datasheet anyway - you'll need it to interpret data read from the battery, if you decide to try that. Somewhere among the application notes on the same web site, there's a generic PCB, amusingly similar to the one I've found in my battery pack - only the current-sensing power resistor is created as a section of a winding thin copper trace, whereas in my battery there's a true discrete SMT device. Apart from the cells and the PCB, the battery pack further contains a discrete thermistor connected to the outer connector (despite the fact that the BQ2092 itself contains a temperature sensor and the value measured is available via I2C) and also a fuse, that's connected in series with the cells and is hidden somewhere among them. Another noteworthy element of the PCB are the four LED's comprising a charge indication bar graph, activated by pressing the "DISPLAY" button.
The TI pages also contain other members of the Unitrode's "gas gauge" family, such as the now deprecated BQ219 or the newer BQ2040 and more - check out the "gas gauges" product folder. The principal I2C communication and probably even the register set should be fairly similar. At the USENET forums there are several reports of the BQ2092 being quite frequent in numerous different batteries. According to the documentation, it can cope with both NiMH and Li-Ion batteries. Therefore it's reasonable to conclude that the information presented here could be useful with many different notebook brands and models.
Next, we need to solve how to connect the battery to a computer via I2C. This can be arranged using the parallel printer port - all you need is a male 25pin Canon connector (D-SUB25M), a piece of cable or thin conductors (three strands) and a few pieces of brass of whatever origin, that can serve as makeshift blade contacts against the female battery connector. And of course you need a soldering iron and a piece of tin and resin.
The battery's got five pins - see the picture below. The list below the picture shows their meanings:
- +V(batt) = positive battery terminal. This pin goes straight to the positive terminal of the first cell.
- SMBC aka SCL (SM Bus Clock, Serial CLock)
- SMBD aka SDA (SM Bus Data, Serial DAta)
- thermistor(+). Its second leg is connected to ground (pin #5).
- Ground = negative battery terminal. Well, almost - between this pin and the negative terminal of the last cell, there's the current-sensing resistor (0.05 Ohms). I.e., the outer pin #5 is connected to the PCB, which is connected straight to the last cell.
This is the pinout at the parallel port (for the i2c-pport driver by Daniel Smolik that's a part of the Linux-based I2C package):
14) SDA
16) SCL
18) ground (in fact this can be any pin between 18 and 25 - all of them are GND)
Tu sum up, the battery connector can be connected to the parallel port in the following way:
