Sort of? I think flashing BIOS firmware should always be done with caution. I agree that you do stand a point
Old reply
Making BIOS updates manual or opt-in in LVFS(default setting of automated firmware upgrade is off, can be turned on by a single click) is not removing the ability/ease of access.
Removing the ability of downgrade BIOS is also not the answer, especially if said BIOS is installed automatically. OS, in comparison, can be re-installed indefinitely.
Therefore, automated OS update has more benefits than risks as long as the update is functional in majority. If said update is problematic, you can always rollback or reinstall.
Automated BIOS upgrade is not the case if BIOS downgrade is not possible as you can’t(nobody can) guarantee the newer version is free from (including not discovered)problem. The risk of being locked in a crippled BIOS is unacceptable.
Updates always come with the risk of falling victim to undiscovered bugs. An OS update can just as easily eat your data and while you can reinstall the OS or potentially rollback a change, that risk of data loss is always there. As usual the solution is a sane backup regime…that I personally skip because proper 3-2-1 backups are kinda inconvenient.
Anyways, I agree for a beta BIOS, downgrades should be possible or if not, prompt updates to fix bugs within a week is a reasonable expectation, neither of which Framework has historically delivered.
I’m a big fan of Dr. Richard Thaler’s work regarding nudges. I think updates should be automatic and seamless and opt-out if a user chooses to do that. Either way, Framework continues to need improvement on how firmware updates are handled.
Since we now have assurance that the battery charge limit will be fixed by the end of the month, I decided to not postpone the upgrade to 3.0.7 in order to get the security updates. Hopefully that’ll turn out to be the right decision, fingers crossed.
The update went smoothly (had to go through Windows, as LVFS update wanted 92 MB of free space on /boot/efi, and that partition is only 100MB in total on my system).
On the first reboot, I disabled the battery extender and set the charge limit to 85% (was 80% previously but I thought changing it might help). For now that limit is respected, I’ll see how it goes.
The update at issue had better come by then and it had better lack serious bugs. For: (1) undertakings are to be honoured; (2) the previous bugs and previous delays have been such that yet another mess-up (delay and/or piece of brokenness) would be a gross breach of trust.
I love Framework and their mission, and I love my AMD FW13. If I were to buy a new laptop today, I probably would still go with FW.
But the lack of prompt and well tested BIOS updates when there are vulnerabilities to be addressed really needs to be… addressed. It really doesn’t inspire confidence, and I’m surprised this hasn’t seen some wider publicity and criticism recently. There’s no good excuse for it.
I also really wish they would unbundle the Windows drivers or change the installer to allow you to pick which ones you want or don’t want, if they’re not going to be keeping them up to date with upstream. But I digress…
Hi @Quin_Chou and FW Community, thank you for your work on this and for folks sharing their experience.
After upgrading today, I thought I’d mention: a) I had to disable secure boot before fwupdmgr update would actual update the bios; b) as others have pointed out, I changed the ‘Battery charge limit’ from where I had it to something else, save & reboot then back to my preferred setting in order for it to stick. I left the ‘Battery Extender’ settings as is even though they don’t impact my use case.
I’m grateful for the continued FW firmware updates and am especially a fan of the option to set the battery charge limit.
I wonder if there’s an opportunity to unify your BIOS into a single development tree and flag features on/off based on hardware? Like how you can use options to build different kernels from the same source.
Since installing the updated BIOS, I have noticed that ryzenadj now misses most of the sensors that used to be working. I’ve tested this on Fedora 41 and Opensuse Tumbleweed (both kernel 6.13.6). Recompiling ryzenadj from git doesn’t help. Is this a glitch in the latest kernel or related to the update? My feeling is it’s the latter, but I can’t be 100% sure.
CPU Family: Phoenix Point
SMU BIOS Interface Version: 15
Version: v0.16.0
PM Table Version: 4c0009
| Name | Value | Parameter |
|---------------------|-----------|--------------------|
| STAPM LIMIT | 51.000 | stapm-limit |
| STAPM VALUE | 3.626 | |
| PPT LIMIT FAST | 51.000 | fast-limit |
| PPT VALUE FAST | 19.874 | |
| PPT LIMIT SLOW | 33.000 | slow-limit |
| PPT VALUE SLOW | 3.799 | |
| StapmTimeConst | nan | stapm-time |
| SlowPPTTimeConst | nan | slow-time |
| PPT LIMIT APU | nan | apu-slow-limit |
| PPT VALUE APU | nan | |
| TDC LIMIT VDD | nan | vrm-current |
| TDC VALUE VDD | nan | |
| TDC LIMIT SOC | nan | vrmsoc-current |
| TDC VALUE SOC | nan | |
| EDC LIMIT VDD | nan | vrmmax-current |
| EDC VALUE VDD | nan | |
| EDC LIMIT SOC | nan | vrmsocmax-current |
| EDC VALUE SOC | nan | |
| THM LIMIT CORE | nan | tctl-temp |
| THM VALUE CORE | nan | |
| STT LIMIT APU | nan | apu-skin-temp |
| STT VALUE APU | nan | |
| STT LIMIT dGPU | nan | dgpu-skin-temp |
| STT VALUE dGPU | nan | |
| CCLK Boost SETPOINT | nan | power-saving / |
| CCLK BUSY VALUE | nan | max-performance |
So we installed a BIOS version that was actually unstable, that’s brilliant. Dear Framework, prioritising the release of new products while the current ones have such big issues is a huge management problem.
I encountered the issue with battery charging to 100% the other day; I wasn’t seeing the issue initially, but what triggered it for me was putting the machine to sleep. After it woke up (or maybe while it was sleeping), it proceeded to charge to 100%.
Battery limit is set at 80% and the battery saver values are set at whatever their defaults are.
After I discharged the battery past 80% and plugged it back in, it only charged to 80%. I haven’t attempted to replicate it but that was the only time I had a problem.
