adding support for /dev/i2c on linux? about smbusb

[5ch4um1]

Well, i recently got one of those cheap 8 channel logic analyzers...turns out, they are based on the fx2...the i2c pins are not broken out, but that eeprom is a nice place to solder wires to:

so thanks to smbusb_bootstrap i finally managed to get dumps of the firmware and the eeprom and could compare them to the results of some scripts i had written some time ago, and i could fix some errors.
I think i managed to dump both firmware and eeprom now via /dev/i2c
`#!/bin/bash

max=18416
for ((i=16384;i<=max;))

do
y=$(printf "%#.4x\n" $i)
let "i+=32"

sudo i2cset -y 1 0x0b 0x09 $y w
sleep 0.01
r=$(sudo i2ctransfer -y 1 w1@0x0b 0x0c r33)
echo $r | cut -c6-
sleep 0.01
done`

(edit: not sure what i smoked yesterday, but it took me way to long to realize that 20 actually means 0x20, aka 32...worked anyway, but i fixed this now and it reads the 32 bytes it should)

this for example should dump the content of the eeprom.
The output format is obviously different from what your tools produce, but i guess when doing the writes with i2ctransfer we'll need the data like that anyway.
I think i'll try these days if i first can finally fix my battery using your tools and then maybe try to write to the chip with /dev/i2c.
By the way, has anybody tried single block writes instead of writing the whole thing? iirc, the datasheet suggests that this should be possible? Oh, and for those who don't want to use the display data channel, but own a raspberry pi, this should work on a pi too.

[mefistotelis]

Responding more to the title of the issue than the actual discussion - it so happens that I made a tool which uses /dev/i2c.
It actually uses 'smbus2' Python module, and that Python module opens the device and does ioctl calls on it.

The tool:
https://github.com/o-gs/dji-firmware-tools#comm_sbs_bqctrlpy
Usage example:
https://www.youtube.com/watch?v=P5PNOO2GebY

[karosium]

Your description of the erase->write->exit process is correct.
https://www.ti.com/lit/ug/sluu187/sluu187.pdf might help with commands.

Someone wrote tools for /dev/i2c here: https://github.com/noolex/lenovo_battery_repair

Multi interface support would be good to have but I won't be able to work on it any time soon unfortunately.

[5ch4um1]

Ah, that's nice, that bat_hack script even does the math. :) I guess we can call this issue resolved then.
Unfortunately my battery stopped talking to me, so i can't test right now. (thought about buying a chip on aliexpress to keep playing, this broken battery has had a huge educational value for me so far...)
Another interesting project i stumbled upon these days was this: https://github.com/iam4722202468/ThinkpadBattery which is basically a smart battery emulator for arduino platforms. He simply uses an attiny85 to tell the laptop what it wants to hear. Tried this with an arduino nano clone, works like a charm, and also might be pretty practical for testing real batteries i guess.
And last but not least, for those of you who are interested in the firmware, there is this guy from australia who wrote a ghidra plugin: https://github.com/pelrun/ghidra-cr816
which is still way above my capabilities, but i hope to make use of it one day.
Anyway, thank you very much for you work, i have learned a thing or two from reading your code, and finally got a backup of both firmware and eeprom data.

[5ch4um1]

that looks like a lot of work, really nice!
i like that sbs_read_firmware_version_bq_sealed function! :)