Resources for **30 EC battery control

[m11k]

I've recently gotten some slice batteries for my X230 as well as my T430 and W530 (the W530 really needs the extra battery life...). One of my favorite aspects of my T61 is the ability to balance between the traditional battery and the ultrabay battery, using the tp_smapi linux kernel module coupled with the tp-bat-balance script . I would like to find some way to do that with these laptops as well, so that I don't run down the slice batteries to 0%. Controlling charge thresholds works as expected (well except for the X230 slice battery -- I can't seem to prevent that from charging up to 100%). But I can't find a way to force discharge of one battery or another. The battery calibration mechanism does work as expected, but it can't really be used for battery balancing (I think it only works when plugged into AC).

My X230 and T430 both have coreboot installed instead of the stock BIOS. The W530 still has a Lenovo BIOS (well the ivyrain mod to remove the wifi whitelist). All three also have the EC mod for the classic keyboard and battery whitelist removal.

I've spent a while playing around with ectool (part of coreboot) to poke at various bits of the EC memory. I've also looked through the coreboot source for general EC documentation, as well as the tp_smapi source code (which doesn't work on the *30 series). I feel like this must be possible somehow. One of the interesting things I noticed is that on the 28++ slice (for the T430 and the W530) there is a latch to lock and unlock the battery. When I unlock the latch, the EC stops discharging from that battery. I wonder if its possible to emulate this in software somehow. I looked through the X230 schematics online (yes I know wrong model, but close-enough) and can see that there is a slice_eject_lever signal in the dock connector, which appears to be routed to one of the EC GPIOs. I took several EC RAM dumps (using ectool) and compared them with the latch open and closed. I can see the status bits change, but I can't find any way to trigger the same behavior without actually moving the lever.

Has anyone looked into the EC at this level, or know of any other online resources that might be helpful? I was thinking of taking the EC flash dumps that are on the hamishcoleman github page and trying to use the radare scripts that he has posted, or possibly trying to inspect them with Ghidra, but this is pretty far beyond anything I've attempted to do before.

[atagunov]

T61 ... ability to balance between the traditional battery and the ultrabay battery, using the tp_smapi linux kernel module coupled with the tp-bat-balance script

I would like to find some way to do that with these laptops as well [X230, T430, W530]

tp_smapi ... doesn't work on the *30 series

Hi, so our problem is that tp-smapi does not work on *30 and so tp-bat-balance script doesn't work. Okay. Do you happen to be using TLP at all? I was under impression that was an absolutely essential tool for anybody wishing to have decent battery life on any Thinkpad. Well at least on any that is supported by TLP. I thought there's no other alternative software on this planet to replace it..

If you're not using it here's how I installed it on Ubuntu

Code: Select all

sudo add-apt-repository ppa:linrunner/tlp # necessary for 18.04 but not for 20.04 currently; better do it
apt-get install tlp tp-smapi-dkms acpi-call-dkms smartmontools linux-tools-generic

So it seems TLP can adapt and use different mechanisms for querying and controlling the battery depending on what is supported for each Thinkpad model. The way to test it is to run "sudo tlp-stat -b". I think it will tell you then if you need to "apt-get" anything else to unlock full TLP potential. I think TLP will also tell you which API it's using. Here's what I see on my T520:

Code: Select all

$ sudo tlp-stat -b
--- TLP 1.3.1 --------------------------------------------

+++ Battery Features: Charge Thresholds and Recalibrate
natacpi    = active (thresholds)
tpacpi-bat = active (recalibrate)
tp-smapi   = readonly (data)

So why did I mention it? It seems TLP supports the following commands:

Code: Select all

sudo tlp discharge [ BAT0 | BAT1 ]

In my understanding it should cause Thinkpad to run on battery even when Thinkpad is plugged in. Further it seems to have the ability to make it run on a specific battery. I wonder if that works at all on *30. If it does then perhaps TLP sources can reveal how exactly it's doing that and may push you in the right direction.. I'm hoping that "tp-bat-balance" functionality can be replicated on *30 via some other API provided by Linux to mange the battery. Possibly via "tpacpi-bat"? That's what seems to be used by TLP on T520 according to the output above. The prospect of messing with EC firmware directly actually does scare the pants off me

P.S. are these same or different slice batteries that work for X230/T430/T530? Given docking connector is the same I would have naively thought there exists just one battery that fits all of them? How are you recalibrating if not via TLP?

[m11k]

Do you happen to be using TLP at all?

Yes, I definitely use TLP on all of my laptops. I use it to set battery charge thresholds on boot, as well as to disable bluetooth (and other power optimizations it makes).

The TLP discharge control functionality only works when connected to AC. This isn't a limitation of TLP, it appears to be a limitation of the EC. See the comments here: https://github.com/linrunner/TLP/blob/m ... pi-bat#L19. When I manually run the tpacpi-bat script with the force discharge command, I can see that it makes the ACPI call, but it doesn't have any effect.

This is what tlp-stat -b outputs on the W530:

Code: Select all

--- TLP 1.3.1 --------------------------------------------

+++ Battery Features: Charge Thresholds and Recalibrate
natacpi    = active (data, thresholds)
tpacpi-bat = active (recalibrate)
tp-smapi   = inactive (ThinkPad not supported)

This is what it outputs on the T430 (with coreboot):

Code: Select all

--- TLP 1.3.1 --------------------------------------------

+++ Battery Features: Charge Thresholds and Recalibrate
natacpi    = active (data, thresholds)
tpacpi-bat = inactive (superseded by natacpi)
tp-smapi   = inactive (ThinkPad not supported)

The tp-bat-balance script relies on the /sys/devices/platform/smapi/BAT{0,1}/force_discharge files, which are part of the tp_smapi module. This module doesn't work at all on the *30 series. Does this file exist on the T520? Does the force_discharge functionality work? The tp-smapi documentation on ThinkWiki says that not all functions are supported on all models.

P.S. are these same or different slice batteries that work for X230/T430/T530? Given docking connector is the same I would have naively thought there exists just one battery that fits all of them? How are you recalibrating if not via TLP?

The X230 takes a 19+ slice battery, and the T430/W530 take the 28++ slice battery. However I actually have a 27++ slice, which was for the T420 and W520, and lacks authentication, but works fine after applying the battery whitelist removal EC mod.

The battery recalibrate functionality does work on the W530. TLP recalibrate doesn't work on the corebooted laptops, but it is possible to trigger it manually using ectool:

Code: Select all

# Recalibrate BAT0
$ ./ectool -w 0xb4 -z 0x06
# Recalibrate BAT1
$ ./ectool -w 0xb5 -z 0x06

I've used this on my X230 and my T430. Credit for this goes to the X220 coreboot page.

[atagunov]

Thank you very much for explaining. I did feel like I was missing something

The tp-bat-balance script relies on the /sys/devices/platform/smapi/BAT{0,1}/force_discharge files, which are part of the tp_smapi module. This module doesn't work at all on the *30 series. Does this file exist on the T520? Does the force_discharge functionality work?

File does exist but it appears that it is not working (stock BIOS no mods):

Code: Select all

root@...:/sys/devices/platform/smapi/BAT0# ls -l force_discharge 
-rw-r--r-- 1 root root 4096 Oct  5 12:05 force_discharge
root@...:/sys/devices/platform/smapi/BAT0# echo 1 > force_discharge
bash: echo: write error: No such device or address

[atagunov]

slice_eject_lever signal in the dock connector, which appears to be routed to one of the EC GPIOs. I took several EC RAM dumps (using ectool) and compared them with the latch open and closed. I can see the status bits change, but I can't find any way to trigger the same behavior without actually moving the lever

So you'd basically need to locate the operations in EC firmware that checks for that GPIO status bit and replace them.. Probably find some unused "register" (similar to 0xb4 in ./ectool -w 0xb4 -z 0x06) and read value out of that "register" instead of using the GPIO bit? All this assumes that the binary op codes for the latter would fit in the space used by the op codes to check GPIO bit?

Here's another idea: are you putting classic keyboards into your *30 gear? If you're then you have the annoying problem of capslock led not working. There is a solution to that, I think - a tiny new board is added, connected via some internal USB interface. That board is loaded with firmware that makes it act as an extra keyboard. That extra keyboard then knows if capslock is on or off and it drives the led. Think that's a treaded path. Could a similar approach be used to drive that line on the docking connector high/low as required to temporarily disable the slice battery?

[m11k]

So you'd basically need to locate the operations in EC firmware that checks for that GPIO status bit and replace them.. Probably find some unused "register" (similar to 0xb4 in ./ectool -w 0xb4 -z 0x06) and read value out of that "register" instead of using the GPIO bit? All this assumes that the binary op codes for the latter would fit in the space used by the op codes to check GPIO bit?

That would be a great way to solve this problem if we a) had the source code to the EC, and b) could upload our own version. Ideally you would want to check both the GPIO status bit, and this new 'force_disable' bit.

Here's another idea: are you putting classic keyboards into your *30 gear? If you're then you have the annoying problem of capslock led not working. There is a solution to that, I think - a tiny new board is added, connected via some internal USB interface. That board is loaded with firmware that makes it act as an extra keyboard. That extra keyboard then knows if capslock is on or off and it drives the led. Think that's a treaded path. Could a similar approach be used to drive that line on the docking connector high/low as required to temporarily disable the slice battery?

Yes, I do have classic keyboards. The missing caplock LED doesn't bother me because I configure all of my systems to turn capslock into a control key. I think any hardware solution would need to cut the trace from the dock connector and interpose it. Possible? Yes, but definitely than I'm willing to do

[atagunov]

That would be a great way to solve this problem if we a) had the source code to the EC, and b) could upload our own version. Ideally you would want to check both the GPIO status bit, and this new 'force_disable' bit.

We certainly don't have the luxury of the source codes, but..

I was thinking of taking the EC flash dumps that are on the hamishcoleman github page and trying to use the radare scripts that he has posted, or possibly trying to inspect them with Ghidra, but this is pretty far beyond anything I've attempted to do before.

I will not pretend I know how radare scripts work or what Ghidra is. However apparently the keyboard hacks have been achieved in thinkpad-ec project via patching purely the binary codes. I understand thinkpad-ec project does allow you to decide which patches to apply and which not to. Therefore it should be possible to add one more patch. This would give us the ability to upload the modified EC code solving problem (b). Re problem (a) of course the adventure would involve messing with the binary codes. I was speaking under assumption that the operation of checking the GPIO bit looks somehow distinctive in binary code for this processor. I was assuming it's possible to find all cases where GPIO bits are checked and locate among them the case where this particular bit is checked. Then it would be a question of figuring out if it's easy enough to replace those binary instructions with new binary instructions for reading the "spare" "register". The question of course stands if new instructions will fit in. They'd need to take same or smaller number of bytes than old instructions. If smaller I guess NOP instructions could be added as needed. I don't know if this condition will be met. And now that I think about it it starts looking a little risky too.. I'm wondering if any sort of disassebly tools exist for this version of EC and if disassembling can help 1) locate the bit of code doing the GPIO bit checking 2) confirm it's indeed the right part of the code. Risky indeed. The risk is bricking the motherboard..

Yes, I do have classic keyboards. The missing caplock LED doesn't bother me because I configure all of my systems to turn capslock into a control key.

Oh.. that must be an ergonomics feature?.. I have quite a bit of issues with my hands.. Maybe I should try.. Do you do it at OS level? Since I'd need it to work with an external keyboard

I think any hardware solution would need to cut the trace from the dock connector and interpose it. Possible? Yes, but definitely than I'm willing to do

Wouldn't that depend on how exactly that latch works? When you move it to "eject" does it connect or disconnect the contact points? If it connects some contact points then it should be possible to imitate this in hardware without cutting any traces - the tiny controller that you add could pull the signal either high or low as desired, effectively introducing a 2nd parallel switch. If the lever on the other hand breaks a circuit then what you said is true and the task becomes hard. So it's sort of 50/50 chance

But even if "eject" position disconnects the contact points.. It might be possible instead of cutting the motherboard to open up the battery and cut the wires inside it. I read somewhere on this forum that these batteries are less impossible to disassemble and cleanly put back together than normal ones.

Update: this needs to be looked more closely at.. What exactly that latch does. It should probably be on those X230 circuit diagrams. What sort of resistors are involved? What nominals? It might still be possible to wriggle something out even if this latch is normally connected and disconnects in "eject" position. Might be a relatively simple task engineering-wise

[m11k]

Oh.. that must be an ergonomics feature?.. I have quite a bit of issues with my hands.. Maybe I should try.. Do you do it at OS level? Since I'd need it to work with an external keyboard

In some DEs (I know of MATE and KDE) there is a setting in the keyboard options to turn capslock into a ctrl key. For other DEs, you can use xmodmap to modify the X keyboard settings.

Update: this needs to be looked more closely at.. What exactly that latch does. It should probably be on those X230 circuit diagrams. What sort of resistors are involved? What nominals? It might still be possible to wriggle something out even if this latch is normally connected and disconnects in "eject" position. Might be a relatively simple task engineering-wise

Page 61 of the schematics found here show that the 'slice_eject_lever' is connected to a pull-up resistor. Whether a low indicates eject is active or not, I don't know.

To be honest, I'm really looking for a software solution. I don't want to do any hardware hacking. I'm wondering if there is some hidden code in the EC to re-enable this force_discharge functionality. I don't know why Lenovo would remove this functionality. My hope is that it is just disabled or no longer documented, and maybe there is some magic byte in the EC RAM that still controls this functionality. I would think that if it was there someone would have found it already, but maybe no one was that interested in looking for it.

[RealBlackStuff]

You've probably seen it already, but if not, there's tons of xx30 EC-info here: https://zmatt.net/unlocking-my-lenovo-laptop-part-1/
Try contacting Matt, he might know.