I have it too. And I found this:
Would be very useful for battery calibration though. A thinkpad style battery recalibration mode would be nice where it completely discharges then charges the battery while connected to ac.
Very nice that people are starting to play with the ec, keep it up.
I have a version of âectoolâ here:
It fixes a few things, but more recently, fixes the âectool chargecontrolâ command so that it does not disable IDLE mode, that I warned about previously.
1 Like
Does this mean it is resolved in Arch? when does that move to fedora?
Once the new version of upower hits the stable repos. It will fix the âannoyanceâ of the plugged/unplugged
https://bodhi.fedoraproject.org/updates/FEDORA-2025-7fe27371fb
https://bodhi.fedoraproject.org/updates/FEDORA-2025-cc92961dbb
Can anyone point me to the patch that fixed upower ?
I saw this one, but my Linux kernel 6.14.2 does not surface
/sys/class/power_supply/BAT1/charge_control_end_threshold
The file does not exist.
I was trying to understand what upower got wrong, in case it affects my EC fixes I am working on.
I have not yet looked at the âbattery extenderâ code to see how that interacts with my current EC fixes.
I just leave the âbattery extenderâ BIOS setting to disabled at the moment.
edit:
My changes to the EC code break the battery extender function.
For example, with my changes:
If you set the charge limit to 60% and enable the battery extender function.
When the battery extender triggers, it will charge up to about 85%
If you set the charge limit to 100% and enable the battery extender function.
When the battery extender triggers, it will not do anything and stay at 100% charged.
If the battery extender triggers at any time, and the current charge is less than 85%, it will charge up to 85%, ignoring the charge limit setting.
Without my EC code fixes:
When the charge limit is set below 85%. If the current charge is less than 85%, and the extender triggers, it will try to charge up to 85%. It will battle with the charge limit setting, looping round charge/discharge on about 1 second cycle.
I have pushed my EC changes to this repo for the Embedded Controller of the FW16.
Note: This makes no changes to the EC code for the FW13. I donât have a FW13 to test with, so cannot help much there, but I think my changes would help the FW13 also.
My changes are on the branch:
fwk-lotus-azalea-19573
âlotus-azaleaâ is the FW16.
In the output of:
sudo ectool chargecontrol
With PSU connected:
NORMAL == Charge battery if there is spare PSU capacity after powering the CPU/GPU.
IDLE == Donât try to charge or discharge the battery. Only power the CPU/GPU.
DISCHARGE == Disconnect PSU, discharge even with PSU connected.
With PSU disconnected:
NORMAL == expect to start charging when PSU plugged in.
IDLE == should not see this.
DISCHARGE == should not see this. (after my EC fixes)
sudo ectool battery
in the âFlagsâ part:
CHARGING == ignoring any charge limits, the battery would like to be charged.
DISCHARGING == extra power is being provided by the battery to the CPU.
If the PSU is connected, and you see ectool battery DISCHARGING, it means the CPU needs more than the PSU can give, and its getting the extra from the battery.
The ectool chargecontrol should still say âIDLEâ while power is being used from the PSU and the Battery at the same time.
If the Battery discharges below a threshold, the ectool chargecontrol should change to âNORMALâ so that it starts charging if the CPU/GPU power usage drops again.
2 Likes
The logic sounds reasonable to me.
This is the upower issue: https://gitlab.freedesktop.org/upower/upower/-/issues/306#note_2856003 (probably best to start reading at this thread, the issue is pretty chaotic). The problem was that upower started to ignore the charging state reported by EC and instead said âdischargingâ even when EC says charging but the battery current is negative. This was to make upper layers aware of situations in which the PSU is not powerful enough so that they can still react to low-battery states, e.g., shutdown when battery < 5%.
1 Like
If you can put together some documentation, I would be willing to test changes on the FW13 for you. I have a Ryzen 7040 series machine 
No disrespect to @James3 intended whatsoever but Iâd be really sure about how using custom âhomebrewâ firmware affects your warranty & any future support before proceeding. Not to mention risk of straight up bricking your laptop. I guess most people knowledgeable enough to consider trying this understand the risks but worth reiterating.
I opened an official support request yesterday for the fact that battery status switches to discharging even when I have AC plugged-in (only with FW 60W charger, not with my Satechi 100W). Iâm working through the support email troubleshooting process
definitely a good point. That reminds me that I meant to open a support ticket too! I am just so used to eBay thinkpads that I forgot I can do that 
That said, I am aware of the risks and if I can get information on how to safely flash my EC I donât mind helping out if it helps others in the community as well
1 Like
I think one frustrating thing here is that FW released a new version of the EC firmware in the latest FW13 BIOS update, but have not published into the github repo what changes they made to the EC firmware.
People have reported battery problems with that latest firmware and I now understand the EC firmware source code enough to finally test and fix the bugs they might have introduced.
As an example as to how crazy the firmware is.
It has 3 different algorithms for battery management that all run at the same time. It applies the result of one algorithm, then a second later applies the result of the second algorithm, and occasionally applies the results of the third algorithm.
As all 3 are very different algorithms, they of course argue and are flipping back and fourth between the various algorithm results. This is what is causing the flipping between charging and discharging. One algorithm is telling it to charge, and the other algorithm is telling it to discharge.
So, one of the bug fixes I did to the firmware was:
- disable the third algorithm entirely. (leaving just 2 algorithms to fight is better than 3)
- when the second algorithm is running, suppress the first algorithm.
My patch actually prints a EC console message when it is suppressing the first algorithm. - when the second algorithm is not running, use the first algorithm.
The result of the bug fix is that only one algorithm is actually permitted to run at a time, resulting in a sensible outcome.
It is only really me putting a plaster on it.
The correct answer is to have a single algorithm that handles all the needed edge cases that the 3 algorithms are trying to handle.
So, that is just one example of how crazy the EC firmware is.
4 Likes
Wow, I guess I would be really curious to know how that made it into production. Do you know if this is the same for the Intel boards?
I am still running 3.05. Are you able to prepare something for me to test?
@Will_Nilges
I am quite cautious about bricking the laptop so I have created some tools so that it makes it very difficult to accidentally brick the laptop. I have a pretty safe way of experimenting now.
The problem is it involves compiling code from about 4 different repos and then following a specific set of steps to try things out.
In summary, its going to take me quite a few hours to write up the instructions and steps. I am hoping to find the time this weekend, but cannot promise anything.
3 Likes
Ah, I gotcha. Well I very much appreciate your work and let me know if you are able to do so. In the meantime I will also open a ticket with Framework about this because while I am not sure itâs explicitly harming my system it is concerning.
If left unchecked, what effect would this have on the health of my system?
In at least one of the branches, thereâs this comment:
Some boards have a sing capacitor problem with mode == IDLE. For such
boards, a host can specify EC_CHARGE_CONTROL_FLAG_NO_IDLE, which
makes the sustainer use DISCHARGE instead of IDLE. This is done by
setting lower != upper in V2, which doesnât support the flag.
Iâm most definitely not an EE so I might be mis-interpreting this, but: This reads as some boards are electrically not capable of true âidleâ in terms of (dis)charging. Do we know which those boards are?
1 Like
There is that comment. But I donât think that code was written by a FW developer. I think it was written by someone at google. So âsome boardsâ could mean some board that is in the wider market, and not necessarily a FW mainboard.
My FW16 mainboard definitely supports IDLE.
1 Like
Just got home and docked my laptop and another weird thing happened: my laptop seemed to still be discharging. Unplugged and replugged my dock and it started charging again. Thought it was worth mentioning because thatâs the first time Iâve seen that behavior. Iâm using a ThinkPad USB C Dock Type 40A9
I made a reply above a while ago, itâs about a portion of power input not available without using the battery
Itâll discharge the battery at about 10mA.
Sorry what?
As long as the systemâs overall electrical load is significantly below the chargerâs capacity (so we donât need to worry about losses/overhead etc), the battery ideally shouldnât be under any load whatsoever. But again, Iâm not an electrical engineerâŚ
Thatâs what the code comment says, maybe meant to say sink?