Gentle reminder that github etiquette for something like this tends to be to like/+1 the issue description instead of a flood of “me too” messages in the issue thread.
(edit: and don’t forget to subscribe to the issue)
7 Likes
Definitely ‘released’ to ‘stable’, it’s on their driver releases page.
Framework Laptop 13 BIOS and Driver Releases (AMD Ryzen™ 7040 Series)
Guess they couldn’t afford to spend resources waiting for an actual stable release when they have three new products to launch. 
4 Likes
From the 3.07 release notes:
If the battery extender mode is disabled, and charge limit is set below 100%, the charge limit will not be enforced causing the battery to charge to 100%.
The broken charge limit is a rookie level bug, that should have been picked up by rudimentary internal testing prior to releasing the beta. It would have taken a few minutes to detect, if there was a proper testing regime.
What’s worse, it was detected during the public beta testing period, and yet Framework explicitly chose not to fix it. WTF? How much effort does it take to change a few lines of code once the bug is known?
5 Likes
I’m fine with them releasing the “broken” beta version. They’re transparent about the issue and the battery charging to 100% is a super minor bug if you’re honest about it. That’s just normal behavior for most other laptops. Plus the new bios apparently fixes other more important issues. And validating another update could take even more time, making people more angry.
That said, yes, the battery charging issue should’ve been found super early during code reviews or unit tests, because it’s probably a super simple logic mistake in the code. I’m a professional software developer, and it doesn’t look good to take that long to make an update and still have obvious bugs like that in it.
2 Likes
I’m still on 3.05 but from the above replies I read, I conclude:
The (manual)Battery charge limit is not enforced when the Battery Extender is Disabled.
and
The Battery Extender is Enabled but the Battery charge limit is overridden when the Battery Extender is “triggered”.
For example, if you set the Battery charge limit to 60 and the Battery Extender is untouched, i.e. Enabled, 5, 30. The battery will be 60% until 5days plugged in, then goes to 85%~95%.
The solution for manual charge limiting would be:
Set the desired limit % in Battery charge limit. Set the Trigger to 999 days and Reset to 1 minute.
The broken charge limit is certainly not a “minor” bug. It’s a major regression in functionality. It’s also an unnecessary regression, as it was discovered and reported during the public beta release period.
A charge limit of say 80% materially prolongs the lifetime of the battery.
The charge limit worked fine with BIOS 3.05, and many people enabled it.
Lacking the ability to set a charge limit is not “normal” behaviour for other laptops. Any decent manufacturer provides an option to limit the battery charge. It’s an exception not to have a charge limit option.
Releasing the 3.07 BIOS with this known regression is a faux pas, and suggests to customers that Framework is very hit-and-miss in supporting its products. Or perhaps its engineers require a refresher course in QA / testing new releases?
12 Likes
I don’t quite agree that it’s a super minor bug. I see two issues here:
The first is that Framework has a battery longevity issue severe enough for them to implement the battery extender, which is a bare minimum charge limiting for people not using the existing (and previously working) feature. Since they broke the charge limiting in 3.0.7, everyone is stuck with that bare minimum solution now. Framework only needs to worry about the battery dying in the 2 year warranty period (here in Europe). Their bare minimum solution may achieve that. But I worry about my battery dying in the 5+ years I plan to use the laptop. Now I need to choose between getting security fixes and preserving battery life.
The second issue is the way this was handled. They take forever to publish important security fixes in a beta BIOS (3.0.6) that also includes a broken battery extender. Then they spend months fixing it, blowing past their own announced deadlines with very little communication. They eventually publish a “fixed” BIOS (3.0.7) beta version, in which the battery charge limit is immediately reported as completely broken, despite the release notes explicitly indicating that the charge limit functionality was “enhanced”. They never respond to the problem, and just publish the BIOS as stable as if the issue didn’t exist.
Framework does a lot of things right, and I love this computer. But they have clearly and repeatedly demonstrated that they just can’t handle BIOS updates correctly.
19 Likes
I guess, what he is trying to say is: “You’re holding it wrong”.. you know.
2 Likes
They aren’t transparent about the issue though. The 3.07 BIOS page linked above and the email both say that they’ve introduced a new battery extender feature, and say nothing about the fact that the manual battery charge limit has been completely broken.
If you weren’t following this thread you’d now be installing a broken BIOS having no idea you’re doing so and no way to roll back.
8 Likes
bad move Framework… what is the point of beta testing then?
9 Likes
I’d understand if Framework were to have difficulties in finding Firmware Engineers, having issues finding an open ear with manufacturers, are overwhelmed by their success, and possibly a lot more reasons.
But the way they have handled these issues for several months now, without even an proper explanation (besides dumping some info in the forums like we’re on ali express), is certainly disappointing to me, to say the very least.
10 Likes
ArsTechnica article from April 2024 – seems nothing much has changed over the course of a year. So many promises, and yet so little to show for “working” on improving BIOS updates.
Another ArsTechnica article from August 2024. In “The bad” section at the end of the article we have “Extended software and firmware support is still a work in progress”.
@Quin_Chou @Matt_Hartley @Kieran_Levin Given the public exposure of BIOS update issues for at least a year, what has the Framework team done to improve the situation? The recent 3.06 and 3.07 updates are a mess.
8 Likes
Frankly, this poor management of BIOS updates goes back much further than last year:
Security related BIOS updates - Framework Laptop 13 - Framework Community
More than the actual charge limit issue, the fact that Framework’s own commitments, promises and processes on this topic have been broken (yet again), demonstrates that they are not serious about lifecycle management of software for their products. I use my laptop for business and I cannot risk having broken BIOS updates, security vulnerabilities and unclear support levels on software.
Unfortunately, after waiting (patiently) for 18 months for these software support issues to be resolved (understanding that Framework is a “young” company), I will be selling my Framework 13. They have had 4 years with a shipping product to work out how to make their products sustainable not just from a hardware perspective, but also software.
Oh, and I still have intermittent charging issues from the top right USB-C port of my AMD, Given up on EC fixes to resolve this…
7 Likes
Why the heck did I buy a Framework for extra $ if I just wanted a NORMAL laptop? Heck, my NORMAL work laptop is Lenovo, and they supply a simple command-line tool to set battery charge min & max values.
1 Like
Well, Framework should definitely fix the battery management issue. That’s obvious. What I was trying so say was that given how slow and bad Framework already is at releasing firmware updates, that it is better to at least get an update (with somewhat broken battery management) than to also take down that beta update and wait another couple of months for another attempt that may or may also not work 100% correctly.
Like not having bios security updates is definitely worse than the battery sometimes charging fully.
I was incorrect about Framework being open about the issue. I thought they listed the problem in the known issues section, but now I can’t find it.
Let’s hope they release another update soon with the battery issue fixed.
6 Likes
You were right, they do mention battery charge limit not being respected as a known issue on the BIOS release page in the Downloads section.
“If the battery extender mode is disabled, and charge limit is set below 100%, the charge limit will not be enforced causing the battery to charge to 100%.”
What I gather from the reports here though, is that it doesn’t work with battery extender enabled either. Waiting for it to become available on lvfs to test myself.
1 Like
Is that work?
Maybe they felt it to be important to get everyone off BIOS 3.05 because of the security fixes in 3.06 and 3.07 ?
However the security problem that sounds like it might be worse to me, because exploit details have been released, namely CVE-2024-56161 isn’t in the list of fixes included.
5 Likes
That would be a stance I could understand. But at this point it’s speculation, because they simply don’t communicate. What prevents Framework from posting on this thread and explaining their rationale? A message along the lines “Thanks for the valuable feedback. In order to not delay the release of security fixes we have decided to release the current version as is. We have looked into this issue and our analysis shows…”
Maybe provide a workaround if there is one. Maybe tell us why they think this is not a major issue. Maybe provide info about which machines are affected, if it’s not everyone. Maybe provide information about planned actions (if they are sure to be able to follow through - in the past such announcements have done more harm than good). Basically, communicate and demonstrate that they care.
11 Likes
Hi,
I don’t have a FW13 AMD, but I do have a FW16.
I have not observed the battery problem. I limit mine to 70% and it stays at 70%. I disable the battery safe feature because I don’t need it. If you power off and unplug the laptop every night, it never will trigger the battery save feature.
But, my understanding is that battery charge/control is done by the EC (embedded controller) which is 100% open source. So, if people are seeing battery charge problems, they could look at the source code and suggest fixes. I have made changes to the EC code that fix some bugs in the EC, but none of those are charge related.
Algorithmically, the battery needs some input parameters:
Fixed set by user:
- global charge limit
- battery save enable/disabled
- battery save trigger setting.
Measured values:
4) battery current charge level
5) EC uptime.
State that must survive a power off of the EC / laptop
6) state of hyterisis cycle.
1-charging to the limit
2-discharging to limit -5.
The rules:
Say you have set the global limit to 80%.
That is fine until the uptime triggers the battery save. It then is looking to use the 98%, then less over time.
That set of rules is odd and suspect in my opinion, but is consistent with what problems people are reporting. I would have chosen a different set of rules.
My suggested work around is therefore to never trigger the battery save function or set the global limit to 100%. Then reset the EC so the uptime is reset to zero and not triggering the battery save function.
To reset the EC:
- power off the laptop, not suspend.
- unplug the PSU for 2 minutes.
- plug power back in.
- power on laptop.
- use ectool console to check the uptime has been reset.
Summary: unplugging the power for a few seconds does not reset the EC.
3 Likes