Public Service Announcement, since Framework is dragging their heels on this.
DO NOT upgrade to BIOS 3.20 on Ryzen 7040 series.
There have been many reports of bricked laptops due to BIOS 3.20, requiring hardware level hacks or mainboard replacements:
I must have been lucky
Me too. So were a lot of other people.
As a datapoint, I upgraded FIVE 7040-series boards and not one of them were bricked. 4 of them are 7840U and one is a 7640U.
I also did one 7840 and one 7640, getting 0 bricks.
This user posted that they updated 11 machines and only the last one bricked. So you’ve got 6 updates left before one of them bricks: Framework Laptop 13 Ryzen 7040 BIOS 3.20 Release STABLE - #30 by HHPC_IT
Personally I ordered my flasher yesterday. Far too many reports of bricks for me to roll the dice without a recovery plan in place. Hopefully I never have to use it.
What’s a flasher?
It’s a device that you can attach directly to the firmware chip on your motherboard, and then write whatever you want to that chip.
If your firmware gets corrupted by the 3.20 update then normally your laptop would be a brick since it won’t boot. With a flasher, a 2nd (working) computer, and the right firmware file, you could open up your laptop, attach the flasher, and use your 2nd computer to write directly to the firmware chip.
You can see people discuss flashers and the general process in this thread: Success in recovering from bad BIOS upgrade - Framework 13 AMD 7040
(naturally, be careful with that stuff. You can damage your laptop if you use the flasher incorrectly.)
You’ll more than likely mostly, if not always, here about the situations where things went wrong.
When things go right - you mostly get silence.
This is why forums are often filled with issues. They are genuine issues, of course, but it can create a somewhat skewed view.
Very true. If there is a questionable BIOS the UEFI method is the most “offline” approach and generally the safest.
Though BIOS updates are getting more complex (as they have gotten more advanced). I miss the days when booting to a USB and it just called BIOS packages in a batch file.
If one didn’t work you could modify the batch file and force the next update in line that needed to be done if it broke itself.
I did one and it is now bricked
This still doesn’t excuse Framework from refusing to replace bricked mainboards that are “out of warranty”.
Before the BIOS update, the mainboards worked. After the BIOS update (provided by Framework), the mainboards didn’t work. Framework is at fault here, regardless of the warranty state.
The proper solution is of course to not provide BIOS updates that brick working laptops in the first place.
What BIOS version did you come from?
What BIOS version did you upgrade to 3 20 from?
3.18
Ap
I have several questions:
Same issue here using the Ubuntu Firmware Updater.
From 0.0.3.18 to 0.0.3.20.
Hmm. It really is beginning to look like BIOS updates need to happen an incremental fashion being sure to not skip a BIOS version.
Have you opened a support ticket about this? Your being out of warranty should not prohibit you from opening a ticket - it just makes it much less likely you’ll get a new mainboard in the post.
Indeed it looks like its necessary. Looks like 3.19 wasn’t sent to production on the LVFS, I had to enable `fwupdmgr enable-remote lvfs-testing`.
i could then upgrade to 3.19 and then to 3.20 successfully.