2012-02-07 - Testing SBS boards with the new Atom FC

Jamey, Tim and Andrew went to the PSBA to figure out if the new Atom FC could talk to the BQ3060 Smart Battery System (SBS) fuel gauge and the BQ24725 SBS battery charger chips.

Hardware Setup

Attached VGA monitor, USB adapter and Ethernet cable to FC.
Made a three wire to 2mm connector to access the FC's CN15 connector, which is the SMB connector. Used pin 1 (GND), pin 2 (DAT) and pin 3(CLK).
Hooked up all 4 Agilent E3646A power supplies to the BQ3060 evaluation board (EVB) to act as faux batteries. Each power supply is set as 3.7V @ a current limit of 100 mA. This gave a 14.8V "battery" stack.
Hooked up Agilent Infinium scope to CH1 on CLK and CH2 on DAT @ 100us/div with trigger on clock to view I2C transitions. Also hooked up GND, obviously.
Pulled "SYS_PRES" on BQ3060 EVB to ground with a jumper to PACK-.
Pulled PACK+ up to "4P" battery input to wake up the BQ3060 from sleep.

Software Setup

Made grub image on CF card talk to console not serial -- maybe this was a bad idea, but we did it anyway. Sorry Josh.
Set BIOS to boot off of external USB mass storage device.
Booted USB flash drive that had Debian Live (live.debian.org), specifically, stable build, USB-HDD variant for i386 with "standard" image. Running 2.6.32. Hmmm, maybe we wanted to run the 3.2 kernel?

We then ran these commands to get some more tools:

sudo dhclient eth0
sudo apt-get install acpi i2c-tools

Experiments

And we got things! Lots of things! Here are some of the commands we ran:

sudo modprobe i2c-dev
sudo i2cdetect -l
sudo i2cdetect -y 0
acpi -V
Also there's i2cdump and i2cget and i2cset
We then ran sudo apt-get install lm-sensors and ran sensors-detect program from it and found an SBS on I2C at address 0x0b (hooray!).
We ran sudo modprobe sbs but that didn't seem to do anything? It was recommended by sensors-detect.

Then we poked directly at address 0x0b using i2cset and found our lovely BQ3060:

sudo i2cset -y 0 0xb 0x0 0x1 w
sudo i2cget -y 0 0xb 0x0 w
... gives me 0x3060 (DEVICE TYPE cuuuuutee!)
sudo i2cset -y 0 0xb 0x0 0x2 w
sudo i2cget -y 0 0xb 0x0 w
... gives me 0x0014 (FIRMWARE VERSION)
sudo i2cset -y 0 0xb 0x0 0x3 w
sudo i2cget -y 0 0xb 0x0 b
... gives HARDWAREVERSION = 0xff
We checked data address 0x006 ("Manufacturer Status (0x0006)") to get the status of the BQ3060 (page 56 of the BQ3060 tech ref). This told us it was discharging normally, and it was!
0x010A == discharging normally
0x410A == turning off top power supplies
0xCC0A == turning off and turning on top power supplies... which shut off the PACK+ output and we couldn't get out of.

We then sent sudo i2cset -y 0 0xb 0x0 0x41 w which is the reset command (and then we read it back, just in case) and the status went back to 0x010A and the outputs came back on.

Fun!

Conclusion

It's a mixed bag. While we could clearly talk to the BQ3060, Linux didn't automagically recognize it as an attached smart battery.

Questions and next steps:

So, uh, Josh? Can we do ACPI magic to let the Linux SBS driver where the chip is? So it all just works? And there's world peace? And holographic rainbow ponies? Jamey mentioned that perhaps we need to force the ACPI table to be what we want it to be, or something like that.
We'll need to the same for the BQ24725 battery charger chip.
Breadboard both EVBs together, for twice the SMBus fun.