I was working on updating my Framework Desktop over the weekend and saw that 3.06 was released with BIOS Recovery and some security patches. I decided that it was time to do my first firmware upgrade on my Batch 13 computer.
I followed the official guide using fwupdmgr and made sure that there was no power loss during the update. The command finished relatively quickly (~10-15s) and fwupdmgr rebooted my computer (with my consent). After 10 minutes of being unresponsive, I plugged in a display to see if it had posted yet, and then in another 5, I manually rebooted.
The computer has not POSTed since. Using the LED Diagnostic Blink Codes, I have videos showing 7 at one point and 6 for the last 3-4 attempts.
I’ve tried resetting the CMOS using the switch on the board. I’ve tried unplugging the RTC battery and clearing the CMOS. I keep getting 6 blink codes before the self-test stops and LED3 stays illuminated (rather than blinking during the tests). The last test was unplugging everything (including the RTC battery) and leaving the board overnight. It still has a blink code of 6.
I have an open ticket with support but have yet to hear back. Any other recovery ideas?
in this scenario, i think you need to use direct probes to direct flash the eeprom. you have to see the other thread iirc about fw16 laptop failed updates or something.
Yeah…that’s what I’m afraid of. I am hoping there is another option than learning the new skill of flashing EEPROM… However, it will be my last ditch effort if it is that or have an expensive paper weight.
If you search the forums you’ll find plenty of threads re 13" and 16", as well as people flashing the eeprom of the 13". You’re the first on the desktop model that I’ve seen.
It’s still crazy to me there aren’t any official and public updates, commentary, and guides on this; especially as now it seems the latest bios updates can brick all their device variations.
I wonder if the BIOS flashing failure rate is similar to other vendors or if it is really higher for Framework motherboards.
And also, what could be the cause? The flash program being weak and prone to failure? The ROM chip and all the hardware stuff around it?
This is also why having open source BIOS would be nice (this is what I asked for in a previous poll). The community could help debugging such issues in order to improve future products.
I have a similar situation here, just received my FW Desktop yesterday and tried to update to the latest BIOS as I thought that was normal for a new system. The update took way longer than expected and seemed to fail overnight. Trying to start my system now simply reads
I’ve since located the relevant chip (by removing the rear panel [the one that’s not see through]) and am gonna try a variation of the fix mentioned in the link above but with the FW Desktop firmware. Hoping for the best!
(Have also opened a ticket with support, pending details on that too!)
Oh yes, also wanted to mention that I’ve tried both the CMOS reset button method and EFI Shell Update, but the first one did not work to fix the machine and the second was not possible as pressing F2/F12 would not bring me to another page.
After a few back and forths with support, sending pictures and videos of the LED Diagnostic Blink Codes, they determined that it was indeed a faulty BIOS update. Since I purchased the board less than a year ago, they exchanged it with a new one.
While I’m slightly bummed that I didn’t get to mess around with EEPROM flashing, I’d rather learn on a less expensive main board.
It is still incredible that a bad BIOS flash would require a whole motherboard replacement. I bought mine in December 2025, that would mean that in 2027 I won’t be updating my BIOS anymore because if it bricks, you will have to buy a new motherboard. Most other motherboards have a a way to emergency flash a BIOS update. This should have been a feature also for the desktop from the beginning.
I don’t think it does exactly; it’s just a practical way for the support team to handle it, given that there is not an accessible way to unbrick at present. I am guessing that when bricked motherboards arrive at Framework Central, they get put in a pile, reflashed with the right electronic equipment, and then resold as refurb units.
I don’t think returned mainboards to FW get fixed. FW occasionally do mystery boxes that contain broken mainboards.
There is one report on here that the person who got the mystery box, just reflashed the bios and got a working mainboard. So it is that that makes me think that FW don’t currently repair returned mainboards.
Ah, I see. I wonder if they’ve decided for now that it’s not worth the cost/labour for the moderate sales it would generate, especially taking international shipping into account.
It occurs to me that it’d be a fun project for per-country volunteers to help with, like an unofficial or semi-official re-flashing service. However I dare say there’s so many legal compliance pitfalls that FW would not want to get involved.
I wouldn’t be happy that lets say the motherboard goes out of warranty and a bad bios flash would require me to buy a whole new motherboard especially in the current climate with prices going up and up. See other motherboard manufactures who have a procedure in place when a bad flash happens.