I keep getting “EFI ERROR CODE 21” when updating with LVFS.
Linux distro and release: EndeavourOS (rolling release)
Updating in the laptop or just the mainboard on its own: in the laptop
If you’re having issues, have you tried a clean install of Fedora 39 or Ubuntu 22.04.3: No
Does anyone know if Phoronix is doing benchmarks on the FL13 AMD as we speak? Would love to see the benchmarks.
Do you have sufficient space on your EFI partition?
Do you have sufficient space on your EFI partition?
My EFI partition is 1,000 MB with 68.87 MB used. I assume that’s enough space, right?
I can’t seem to get the Windows 3.03 BIOS updater to run successfully. When I run it, the screen completely locks up for several minutes; only to suddenly show Windows as rebooting. After it finishes the Windows-unloading portion of the reboot, there’s just a black screen, and a varying degree of fan noise. After several minutes of nothing, I extremely reluctantly held down the power button to turn off the laptop, turned it back on, and saw an error message from the BIOS stating that there was an error during decompression (error 02, maybe?) It went away fairly quickly, then the computer booted normally into Windows, and seemed to still be running 3.02.
I tried this process twice with similar results; since it feels a bit too close to potentially bricking the motherboard, I’m reluctant to try it again with that same updater unless there’s something else I should try 
I might try it with the Linux/LVFS or UEFI updaters at some point, but wanted to report on the Windows side of things.
Update power limit table.
Hi! So, what exactly was done here? Were the limits increased? Decreased? In what context, on battery, plugged in or both? What consequences should we expect from whatever change was made? Apologies if this was already answered, I did a quick search only
Mentioned a bit above 
Seeing some possibly strange USB PD negotiation behavior since the update. My typical Anker 737, when plugged in to the top up-to-100W port, just causes the orange LED to flicker on/off and never settle in to a steady state. A smaller 30W phone charger I have negotiates fine.
The issue with the Anker seems to resolve if I shut down and wait 30 seconds or so for the EC to reboot. Not sure what then makes it start happening again. I’ll do some testing with charging-after-entering-sleep.
Can you check on the bios screen upper right corner to see the battery and AC status.
Thanks for Framework for the quick turnaround, everything seems to work indeed much better with the new BIOS.
I was having issues with suspend, but it turns out was not related to AMD but having nvme.noacpi=1 as a kernel parameter, which I’m not sure why I’ve added in the first place (I’m reusing my P31 SSD I had previously).
Might need to give it another day or two to know for sure, but 3.03 on Fedora seems to fix it up nice. I ran all my usual gamedev stuff on it without any issues or amdgpu errors in the log, and played some games without running into GPU resets or compositor crashes. Great work!
Update was smooth on Win11 
Another smooth update on Windows 11 with the 7640U!
I am curious about something. It seems like the AMD Adrenalin driver version is locked - does this mean we will need new driver bundles from Framework to get the latest versions?
Could you provide more information around your Windows configuration? E.g. the version that appears in System Information and whether there is anything else that could be noteworthy? Partitioning or other modifications from a default installation.
Update was smooth as butter!
Updated successfully on Windows 11. No major issues, but I have noticed the fan bursting up to full speed under near-idle (video playback) loads once every few minutes. It doesn’t seem correlated to CPU or GPU usage spikes according to task manager, and it goes back to completely silent within a second or two. It also didn’t happen before, so it’s probably a regression with 3.03 – maybe somehow related to the power limit changes?
Can you check on the bios screen upper right corner to see the battery and AC status.
Yes, the icons show that the battery is full and the charger connected.
Attempting to update using fwupmgr gives the same thing everyone else seems to get:
Failed to connect to daemon: Timeout was reached
Fedora 39 beta.
Laptop.
Using a fresh install of a supported distro/release does the same thing
Note that battery was at 83 and later 91% and laptop was plugged in and charging.
Checking systemctl status fwupd.service says
start operation timed out. Terminating.
Ooh, so there is something a bit funkier than average. The SSD I installed, while I purchased it for this machine, spent a bit of time in a Ryzen-powered Beelink where I’d partitioned it for dual booting. While I was prepared to reformat right away, I had trouble running Rufus on the machine I had at hand (a Mac running Windows 11 in Parallels), and the Windows partition got up and running more easily than I’d expected with all the drivers, so I delayed pulling the trigger on a reformat.
While I’m definitely in a non-standard situation at the moment with bringing the drive over, I will ultimately be dual booting Windows and Linux, at least to start. Would it be expected that the Windows updater might have problems with unusual partition/EFI setups for now?
And to answer the other question, the Windows 11 version is 10.0.22621 Build 22621 - don’t think there’s too much else noteworthy other than installing various developer tools and enabling WSL2.
On Fedora 39, I managed to get the fwupd service to start by disabling Gnome Display Manager with systemctl disable gdm and restarting. On start up, I ran Ctrl+Alt+F1 to connect to a tty and then fwupdmgr refresh --force and fwupdmgr upgrade succeeded. After rebooting, I renabled gdm, restarted, and everything was back to normal. amdgpu dmesg errors are now gone!
Thanks for the quick update Framework team!
