Indeed (rip my first work dell precision mainboard) but somewhat ironically apple has one of the best ways to recover from bricked firmware with their dfu rescue mode (maybe because they store all their firmware on the ssd shared with the os or maybe just because of their phone heritage)
Which is a whole other issue of itself.
Pre Apple silicon you were able to boot an os from an external ssd, in case your internal ssd failed.
Now you cant, since the firmware is also on the ssd and you need a bga rework job to get it running again ![]()
Oh the soldered ssd thing is horrible and putting the firmware on the ssd is a really extreme way to save a few cents and a few mm2 of board space but dfu rescue is really nice.
Contact support. You might have done a step wrong dint wait, or a bad flash and cant recover on your own. (I hope there is some emergency recovery method, or ship the board for repair method ).
In contact with support now thankfully.
Figured out what happened. I got an email directly from framework to update bios. Clicked their link and installed correctly, but turns out the email they sent me was the incorrect BIOS version for my system. Hopefully I can do a main board reset, as I see the guide for the 11th Gen, but not for later versions.
So you tried to install a e.g. 11th or 13th gen bios on your 12th gen?
Correct. The email, which Iâm sure you all got, stated âSoftware update for your Framework Laptop 13â. Iâm not sure why they sent me the wrong email.
Would have been better if they just said âan update in available for 12 genâ instead of writing its for âyour laptopâ and then a direct link to only one BIOS.
And the updater did not refuse to install???
Many years ago I tried to flash an new bios for a Gigabyte board rev. 1.0 to my 1.x board of the same series. And it refused because of the wrong type.
I really would have expected to to see such a safeguard in Frameworks and every update procedure!
Nope, no problem! Even admired that nice bios install screen that says framework.
I tried running the .exe on my desktop to see the process and info again, but wouldnât even load.
Pretty much any ARM based SOC is un-brickable.
They all have some ROM in them that can boot from the UART. As it is a ROM, it can never been deleted, and thus one can always recover it.
x86 systems donât have a ROM, so become more easily brick-able.
Some x86 main boards have a small arm chip on them, that provides the un-brickable feature.
For example, I have seen a x86 mainboard that one can install a new BIOS even with the x86 CPU removed.
It would be nice if FW introduced that feature to the FW mainboards.
Might be worth adding something like this to x86 platforms too, if you can spare die area for crap like pluton you can probably also spare some for a simple recovery environment.
That has gotten kinda standard now at least on the amd side (probably cause of the insane amount of generations am4 got)
Hell a programming header + instructions/tools to use it would probably already do it in this case.
I donât know how much of the following is true or not.
Some people tried to port coreboot to the FW. They tried a bit, bricked all the laptops, and so dev work had to stop.
If FW had made the FW unbrickable, we would probably have coreboot running happily on it by now.
Those laptops where not intel bootguard enabled, allowing custom bioses, but they (the devs) seemingly dint have the hardware flashtools or time to manually flash back an original bios image. Semi bricking the boards. Ours however are intel bootguard locked, thus only framework blessed bios images will boot. Minor details, im very sad said devs dint able to flash their âbrickedâ boards for whatever reasons.
Still hopeing for a coreboot framework laptop sold world wide (not the chromebook, isnthat even sold anymore?). Meanwhile im gonna apply this bios update
Hmm, I lied before. When smashing my machine doing a parallel software compilation I do see a drop to 400MHz, but then I go back to full speed (the CPU cools down?). Funny, I never noticed that before doing this BIOS update, but I donât usually have heavy workloads on this machine and it only throttles back for a brief period (10s?). Anyway, for those who find themselves locked at 400MHz, I guess there must be something in that logic where the machine throttles back and then gets stuck. I think the speculation has been that this is a firmware bug somewhere? Or a hardware flaw? Sorry I canât be of more help for people who are experiencing that.
Nope, i did not get this.
Damn.. If true, this is on FW..
The motherboard has IDs for the update to check for, so it should prevent the update on an incompatible machine..
Sadly, for me the 3.17 â 3.18 update via the windows installer didnât show any progress bar after the reboot, and it seems to be stuck without any diagnostics on screen. Is it already bricked or do I risk bricking it by a force reboot?
Probably no way to tell.
But it happened with one of mine (sadly not in person, a relative did the update, did not know whether it did anything / show anything after going down for reboot).
After 15min I told them to just shut it off and it did the update on the next boot. Like it simply failed to reboot normally but had never even started the update.
But no guarantees. That is the risk. But the update should be long done in 15min. So if it started the update and was just missing display output, it should already have completed.
If it started, but did not complete it (and is not just hanging on the boot after the new firmware is already on it), it would already have failed catastrophically all by itself and there really is no way out of it other than force a reboot⌠And hope that frameworkâs BIOS has support to recover from partial BIOS updates / you got lucky.
Ok after lots of back and forth with framework support, they are telling me my mainboard is e-waste now and itâs up to me to buy another, which I will not be doing.
This is officially the shortest lived laptop I have ever had, lasting less time than my 2005 Compaq that if I pressed too hard on the case it would shut down, but lasted over 3 years.
Good luck to everyone else!
Have you asked that the case be escalated for review? I am surprised that the updater did not check the board version for compatibility prior to executing. That it did not do so and updated an incompatible board feels like a bug in the updater, and something that the company would want to make a replacement exception for.
You also may be able to find an independent sho that can flash the correct image with specialized hardware.
Best of luck.
I couldnât agree more. If Framework linked or otherwise provided an incompatible update OR the updater doesnât have robust enough checks to prevent this from happening, itâs Frameworkâs responsibility to replace the board. Regardless of warranty. A board is a few hundred dollars, a customer is worth thousands over lifetime. Do the right thing guys. @Phillip_Williams I would escalate as well.