(Issue 1) Hum…looks like charging flicker / toggling / flipping is still a thing when, in my case, Stop Charging threshold is set to 72, with Ubuntu 24.04 LTS, Kernel 6.8.0-31. (When looking at the battery indicator in the GUI, or Settings → Power). While idling.
Side-LED charging indicators stays white though.
In Windows 11, if you hover the mouse cursor over the battery icon in the system tray, I would see the popup tooltip of “Battery status: 72% available (plugged in)” changes to “Battery status: 72% remaining”…and back and forth once in a while (at lease once every 5 minutes of human monitoring period).
(Issue 2) And somewhere along a reboot from Ubuntu 24.04 to Windows 11, the laptop would momentarily continue to charge (ignoring the charge threshold of 72%)…and I see 73% in Windows?
Update (on Issue 1):
And looking at this, I guess it’s because 24.04 LTS currently doesn’t have an OEM kernel? Meaning if I don’t want to see this issue, I need to go back to Ubuntu 22.04?:
Update (on Issue 2):
If I only do Windows–>Reboot–>Windows, I still see the battery charged percentage increase from 72% to 73%.
So, seems like the implementation of the stop charging threshold still has gaps after 2.5 years (since feature release). Hope the BIOS team can look into this.
Both issues are observed with Framework’s 60W charger (and Framework’s USB-C charging cable), and Lenovo’s 65W USB-C charger.
The mainboard is an 11th gen Batch 5 on 3.17 with a coolermaster case and the BIOS is in STANDALONE mode.
I downloaded the 3.20 update, burned it to a bootable FAT USB, booted, and watched it run startup.nsh. It looks like it updated some stuff under EFI, then rebooted itself and came up with a blank screen.
I unplugged and rebooted the machine and it came up still on 3.17.
Tried again. Booted the USB, but this time it ran startup.nsh, tossed out some red text, rebooted before I could read anything, and same–still on 3.17.
I’ve confirmed secure boot is OFF.
The following may or may not be relevant.
Just out of curiosity, I ran “fwupdmgr get-devices” and see the following in the output
UEFI System Firmware:
│ │ Device ID: 4e494f28c524fcd4beef1b131512b664c09476d1
│ │ Summary: UEFI System Resource Table device (updated via NVRAM)
│ │ Current version: 785
│ │ Minimum Version: 1
│ │ Vendor: Framework (DMI:INSYDE Corp.)
│ │ Update State: Transient failure
│ │ Update Error: failed to update to 0: error-pwr-evt-batt
I just tried to update to 3.19, but get exactly the same behavior.
Meanwhile, I was reviewing Getting started guide with a bare motherboard and suspect this has to do with the (lack of a) battery. I know the rtc is good, because the mainboard keeps time properly between shutdowns.
I just found the error.log on the boot USB, which says
Error 331: Full FW Update using same version is not allowed. Include -allowsv in command line to allow it.
I opened startup.nsh and appended the “-allowsv” flag to permit a retry.
fwupdlcl.efi -F fwupdate.bin -y -allowsv
Re-booted the USB and carefully watched it run through to 100% successfully updated. Again, it rebooted, but I’m still on 3.17. There’s no error.log file, so I presume it thinks it worked properly.
fwupdlcl.efi does the ME, you want to run the line that has the graphical winux thing - but without the winux so you can see the bios updater log - I’ll try to find my laptop in a few and post more details
11th Gen Batch 3. Updated from 3.19. Everything went smoothly. There was a restart after the Framework symbol with a completion bar where the screen took a minute (or longer, can’t remember) to come back and fully update. I think the update took somewhere around 10-15 minutes.
Yep, no go just like the poster above. Hopefully in time FW will get a better updater. I might eventually try creating a windows to go usb drive and using the exe.
I have this same issue, only I was on 3.19 already. It boots from the USB, and installs the firmware (or so it thinks) but when you reboot it’s still showing 3.19 for me. I’m on Linux Fedora and used the UEFI Shell.
It would be cool if Framework made an AC<->DC adapter (or even just a DC<->DC adapter that converts from the battery ribbon cable style connector to a barrel plug) so standalone users had another option than having to open the case, and also pull apart your laptop to temporarily hook up a battery so you can do a BIOS update. Possibly easier said than done, since there’d probably have to be some electronics to emulate being a battery, unless the system has a mode where a connected device can say “this is really wall power, I have no charging circuitry.”
(Ideally, it’d be nice if the BIOS update could be done with dual USB-C power connections so the PD could be updated without losing power, but that might be a little more exotic than just making the device think it had a battery connected.)
Guess this all comes with the territory of a first gen product. Ah well, though… if this doesn’t improve, I’m still better off than I was because I got to upgrade my laptop and got a pretty nice HTPC as a side effect… Small price to pay.
It appears the update to 3.20 went well on my Laptop with the EFI updater (apart from when progress bar reached 100% and then jumped back a little bit and remain there for some nerve-racking minutes). After the reboot I checked all the version numbers and found they were as they should be according to the first message of this thread.
However I’m wondering, whether this has happened on my system:
I would expect iw phy to show at least some 6GHz channels working, but all are disabled. Also iw reg get does not list any 6GHz channels for phy#0 even though it shows, that country DE has been detected, where 6GHz is officially allowed.
I’m running Debian Trixie with kernel version 6.9.7
Has anybody had success with 6GHz WiFi after the update to 3.20?
