Framework Laptop 13 Ryzen 7040 BIOS 3.07 Release - Held

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.

2 Likes

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) ?

2 Likes

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 …

1 Like

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.

1 Like

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.

1 Like

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.

4 Likes

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.

3 Likes

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.

1 Like

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.

8 Likes

TL;DR of the whole thread: Framework is grossly incompetent or it does not care about its users.

5 Likes

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 :thinking:

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.

1 Like

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.

1 Like

A reasonable charge limit would be between 80% and 90%. Your battery health would not benefit more below that.

1 Like