Wow. What a completely unforced mistake. @nrp , want to make a statement? You owe it to the beta testers doing your QA work for free.
Framework Laptop 13 Ryzen 7040 BIOS 3.05 Release and Driver Bundle is also still pinned, despite being not the latest recommended firmware, given they are emailing everyone saying Software update for your Framework Laptop 13 (AMD Ryzen⢠7040 Series) - BIOS 3.07
.
Just small company not doing joined up thinking I guess on that one.
Did anyone have an official response from Framework acknowledging the bug ? Is this maybe why itâs not been added to the offical LVFS for Linux users at Framework Laptop 13 BIOS and Driver Releases (AMD Ryzen⢠7040 Series) ?
Thanks for the detailed info. This looks indeed like something we can fix on our own. For now Iâm still waiting on the 3.0.7 to hit the LVFS stable channel.
This may be water under the bridge at this point, but I donât really understand what the Battery Extender functionality is designed to achieve in real life. I donât want my computer thinking it knows how to manage my battery better than me; I want it to do what I tell it to do - no more, no less.
In that vein, greater control of and options for the Battery Charge Limit functionality would seem to be better ⌠and what most other manufacturers do. Just let me set maximum charge, minimum charge, and the âfloat rangeâ percentage manually, and I should be fine.
The new â5% float rangeâ is a good first step, but what if I would like it to âfloatâ more than that? I know one can manually manage this by disconnecting and reconnecting the power cable ⌠but should I really have to do that?
It would have been nice if Framework had decided to make items #2-6 in the OP part of one firmware upgrade, and make #1 (the âbattery extender functionalityâ) optional. Is there some sort of regulatory issue somewhere (EU perhaps?) pushing #1 as a priority? The whole situation feels very much self-inflicted âŚ
When Framework released the 61Wh battery, people reported early degradation and battery swelling. Framework replaced them under warranty and examined the batteries. They then stated that leaving the laptop plugged in is what caused the issue. The battery extender prevents the battery being kept at a high charge and constantly pumped with more juice to keep it that way. Thus preventing the early degradation.
TL:DR, the battery extenderâŚextends the life of the battery.
Yes, I understand that, but the same could be effectively achieved through intelligent application of the existing Battery Charge Limit functionality. Why not modify that further, to allow for greater fine-tuning of that functionality, rather than add a new and competing feature?
Most, if not all, of those issues go away if the battery doesnât charge to 100%, or fall to >10%. Setting max and min charge limits (say 80% max, 20% min) keeps you in a relatively safe range ⌠I have not had any of these issues so far, by doing (effectively) just that.
I get that the Battery Extender functionality is basically âbattery management for dummies.â I think that it was poorly implemented should be obvious by now ⌠but I also question whether it is the best way to achieve the original purposes for which it was created. I personally do not think so.
Attempting to have more intelligent hands off battery management is starting to creep into a lot of devices.
My work MacBook will learn when Iâm generally plugged in and not charge past eighty percent if it thinks Iâm going to stay plugged in.
My pixel phone will makes similar decisions but about charge speed, intentionally charging very slowly overnight to preserve the battery, because itâs confident it will be left plugged in for long enough.
Iâm not really a fan of Frameworkâs algorithm, but its clearly their attempt to follow in those sorts of footsteps. Both of my examples are user overridable with a simple in operating system click, whereas the framework one isnât (easily), which I think is its biggest drawback.
My current experience:
Set this in Bios:
Charge limit: 60
Battery extender: on
Days to charge full: 1
Days in battery: 30
Interestingly it stopped charging immediately after setting this (the LED turned white)
What i found out via upower:
Battery discharging (like it should)
Plugged in: yes â This is new (normally it states unplugged if charge limit is reached)
So maybe this is all just a âUIâ change.. Like my Desktop Environment Battery Plugin tells me its charging, but according to upower its not.. maybe its all a misunderstanding (change of behavior before the update)
Ill test it a few days and report my findings here.
I got the email that Firmware 3.07 is available, but I canât find any update with the fwupdmgr
command and in the LVFS database it says itâs ânot be suitable for production systemsâ. Is this just a beta version then? When is it expected to be released as a stable?
The last table version (3.05) was in April 2024.
Itâs not released as stable in the LFS database yet. Maybe Framework is still discussing if they want to enable automatic bios updates with that battery issue (given that many Linux distributions suggest to automatically install LFS firmware updates).
+1 to the battery charge limiting issues, disabled the battery health functionality but the charge limit is not honored. I noticed the battery percent continued to increase after the led has turned white which is a bit odd.
Also has anyone noticed any fancurve issues? been playing with ollama as the cpu is quite responsive but have had issues with the cpu cores pegging at 100c for several minutes and the fans not ramping up. Avoiding being annoying is fine but iâd have thought if its in performance profile you give it permission to go âHAMâ and that would include dealing with the increase in power.
Fans seem to ramp normally in graphics benchmarks in the brief testing ive done so far.
Iâm not sure what you mean. I was referring to wattage, not voltage. Whether or not 5 volts is âsufficientâ is debatable. My point, if you read the conversation, was to make an example of why one might want a device to work with more USB chargers. If you think my example was bad, fair enough. Iâd further add that my phone is a piece of garbage, although thatâs irrelevant.
+1 for battery limit issues on 3.07 bios.
They should have released only the security fixes then. You donât ship a broken feature period.
TL;DR of the whole thread: Framework is grossly incompetent or it does not care about its users.
Iâm also hit by the charge limit bug. Please provide a workaround before the fix is rolled out.
So.. today my battery charge limit is still working.
The settings are a little bit confusing, but it seems to work
You probably meant CVE-2024-56161 (2024 rather than 2025). Also, a more relevant CVE might actually be CVE-2024-36348, since the other one specifically considers the impact in the context of confidential computing. AMDâs AMD-SB-7033 advisory doesnât make the distinction super clear, but you can sort of read it between the lines.
In any case, it wouldâve been great if the fixes were included⌠In the meantime, at least on Linux thereâs this kernel stop-gap.
After FW update:
- Old charge limit (60) does not work anymore
- Disabled new battery extender funct
- Set charge limit to 70% does work
- Set charge limit back to 60 does not work any longer
- Set charge limit to 65 appears to work (battery extender disabled)
This applies to immediately after the firmware update and after resetting the embedded controller.
A reasonable charge limit would be between 80% and 90%. Your battery health would not benefit more below that.