Yes, that is what I did to bring it back to life (always worked for me). Never seen anything like boot loop before.
Good news: I finally successfully upgraded my BIOS from 3.04, and it fixed the suspend issue for me! After some back and forth with support they suggested I try upgrading to 3.06 first, and I did so using the EFI shell updater here. That already fixed the suspend issue for me but YOLO, computer luck is in the air today, and I tried updating to 3.08 and it also worked using the EFI shell updater from this thread! Now my BIOS is fully up to date and suspend seems to be working great. Woohoo!
EDIT: wanted to note that the 3.08 shell updater did not work for me on battery power, but worked when I plugged in.
5 Likes
Is a stable EFI updater ever going to be released or has it been abandoned altogether and we should just write it off? At that point, if this has been abandoned, I would just prefer to know rather than wait another year for something that will never come.
It will be a huge disappointment and will impact my future purchase decisions but it will at least be honest. We have been waiting for close to 2 years for the promised features, 61Wh battery compatibility and numerous security patches and there has been no updates regarding the state of the EFI updater for several months now, so considering it abandoned seem the only logical conclusion at that point.
6 Likes
Id like to add that its one of the steps, to power the laptop with the external powersupply:
Its not noted in the top post however, that would be a good addition
3 Likes
It works! Hallelujah. Well, hopefully nothing goes wrong, but it’s seems so. If this problem affects most/all 3.04 users, I really hope they make a note/warning at the top of the page.
3 Likes
I also successfully upgraded to 3.08 using the 3.08d update at the top of this thread. I updated from 3.04 to 3.06 (having to do a few reboots and a few re-accessing the usb thumb drive) to get it for force the steps (as listed in the guide). And then, I updated to 3.08. The 3.06 bios update has a very verbose script and will report each of the 5 steps and can tell you when the update is complete. The update to 3.08 will just show a black screen and then reboot. If you boot from the USB thumb drive again, it will report if the bios update is complete.
For anyone else updating from 3.04 on a 12th gen system, read the guides, follow the steps. Format your USB thumb drives to FAT32 and eject them properly after copying the files. Shutdown and unplug the system for at least 90 seconds before rebooting and ensure all your ports work. Unplug any peripherals. I used USB2.0 thumb drives (both 16Gb). Keep your system plugged into wall power throughout the process until the upgrade is complete and don’t unplug your USB thumb drive until the update reports as completed.
2 Likes
I finally gave up and installed Windows on a spare SSD and just ran the windows installer. I was super patient, but got tired of not knowing when it might be released. Overall, it took me about an hour to open the laptop and swap in the spare drive. Install windows, update and install drivers, then install the BIOS update.
All went well.
4 Likes
Same here, going from 3.04.
I put Windows on a spare SSD, updated it and installed like it was going to be my main OS (with Framework drivers). Unplugged all expansion cards and peripherals.
Originally, it didn’t seem to update to 3.08 but it got there after a couple of reboots.
3 Likes
What a pain to think I will have to do this and to think I will have to do this again if they release a newer patch/version.
I am also quite tired of that situation. I hope very much there is journalistic pressure again so we can have some updates on the Linux bios situation on 12th gen.
4 Likes
Just fyi, the EFI updater was released for 11th and 13th gen. It essentially has the same structure there. And it causes the same problems of users misunderstanding what is updated and what not.
The only thing missing is reports of where CapsuleApp does not like the EFI partition somehow. Which fails to update the BIOS without a good error message, but not critically.
11th gen update was just dumbed down considerably. Doing that to the 12th gen update would remove the standalone update ability. But they do not care that this is missing for 11th gen.
I think they are being inconsistent in what they consider good enough for release…
2 Likes
Re: “LVFS will not update the CSME firmware”. What problem would be caused by not updating the CSME firmware? If I decide I do not care about CSME, can I use LVFS to upgrade?
1 Like
As far as I know Framework has not uploaded the current version of BIOS firmware to LVFS (the ReTimer firmware should be there, in the beta branch though), so you would have to package that into lvfs format yourself (should just be metadata / config files, the capsule itself should basically be the same).
Regarding the ME firmware: we do not know. Generally BIOS and ME firmware are not coupled 1:1 but it might be that one introduces a new feature or changes behavior that should be matched by the other. Mostly, I think its just testing though. Nobody is testing every ME version and every BIOS version together. So most things will work but you might run into problems (stability, features that involve ME) because the combination you are running was never tested by anyone. I do not know how the interface between BIOS and ME is defined to judge how often / how likely issues would be expected to creep up. But since the original attempt at an EFI installer for 3.08 did not install ME and we never saw reports from those affected about additional instability, I do not think the chances of issues with the current version are high. But there is a reason it was updated in the first place. Probably security issues that will remain unpatched.
But the ME firmware updater is a separate executable. You could just run the EFI version of it manually or even get the Linux version of it (Intel provides one. Owners of 11th gen have found it before and used it when Framework failed to provide EFI or Linux installers).
1 Like
I’ve been following along with the 12th gen firmware saga since December 2022.
Today, I tried for the first time to use the 3.08d UEFI Shell package to update my 3.04 BIOS. Like others, the process did not work. The only component updated was the Intel ME Engine to 16.1.30.2313. All of the other hardware is at the same firmware version as before I started. Looks exactly like the experience alko89 had back in May (12th Gen Intel Core BIOS 3.08 Release - #464 by alko89)
I’m running Linux Mint 21.3 as the OS. The EFI partition is 537MB w/ 493MB free. That should be more than enough space for the update to be saved to.
$ df -h | grep boot
/dev/nvme0n1p1 511M 42M 470M 9% /boot/efi
I got to @Kieran_Levin’s post at the end of May and read through the post (12th Gen Intel Core BIOS 3.08 Release - #509 by Kieran_Levin).
Looking at the photos I took of the UEFI screen, my NVMe drive is FS1, like alko89’s. I tried resetting the BIOS settings to optimal defaults, dropping to the UEFI shell, and running CapsuleApp.efi winux.bin firmwarehdr.cap -OD FS1. My result was like Adonnen’s from June 3rd and NF117’s from June 9th. The folder on the ESP partition is UpdateCapsule, not UpdateCapsule000x as mentioned by Keiran_Levin on the June 5th
$ $ sudo ls -R /boot/efi/EFI/
/boot/efi/EFI/:
BOOT ubuntu UpdateCapsule
/boot/efi/EFI/BOOT:
BOOTX64.EFI fbx64.efi mmx64.efi
/boot/efi/EFI/ubuntu:
BOOTX64.CSV grub.cfg grubx64.efi mmx64.efi shimx64.efi
/boot/efi/EFI/UpdateCapsule:
firmwarehdr.cap winux.bin
My efivars
$ xxd /sys/firmware/efi/efivars/Boot0001-8be4df61-93ca-11d2-aa0d-00e098032b8c
00000000: 0700 0000 0100 0000 5c00 4500 4600 4900 ........\.E.F.I.
00000010: 2000 5000 5800 4500 2000 3000 2000 6600 .P.X.E. .0. .f.
00000020: 6f00 7200 2000 4900 5000 7600 3400 2000 o.r. .I.P.v.4. .
00000030: 2800 3600 3000 2d00 3600 4400 2d00 3300 (.6.0.-.6.D.-.3.
00000040: 4300 2d00 4200 4600 2d00 3100 4100 2d00 C.-.B.F.-.1.A.-.
00000050: 3100 3200 2900 2000 0000 0201 0c00 d041 1.2.). ........A
00000060: 030a 0000 0000 0101 0600 000d 0305 0600 ................
00000070: 0300 030b 2500 606d 3cbf 1a12 0000 0000 ....%.`m<.......
00000080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000090: 0000 0000 0000 0003 0c1b 0000 0000 0000 ................
000000a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000b0: 0000 7fff 0400 5243 ......RC
$ xxd /sys/firmware/efi/efivars/Boot0002-8be4df61-93ca-11d2-aa0d-00e098032b8c
00000000: 0700 0000 0100 0000 7400 5700 6900 6e00 ........t.W.i.n.
00000010: 6400 6f00 7700 7300 2000 4200 6f00 6f00 d.o.w.s. .B.o.o.
00000020: 7400 2000 4d00 6100 6e00 6100 6700 6500 t. .M.a.n.a.g.e.
00000030: 7200 0000 0401 2a00 0100 0000 0008 0000 r.....*.........
00000040: 0000 0000 0020 0300 0000 0000 9148 49ff ..... .......HI.
00000050: 8e15 2b4a b644 989e a102 44b0 0202 0404 ..+J.D....D.....
00000060: 4600 5c00 4500 4600 4900 5c00 4d00 6900 F.\.E.F.I.\.M.i.
00000070: 6300 7200 6f00 7300 6f00 6600 7400 5c00 c.r.o.s.o.f.t.\.
00000080: 4200 6f00 6f00 7400 5c00 6200 6f00 6f00 B.o.o.t.\.b.o.o.
00000090: 7400 6d00 6700 6600 7700 2e00 6500 6600 t.m.g.f.w...e.f.
000000a0: 6900 0000 7fff 0400 5749 4e44 4f57 5300 i.......WINDOWS.
000000b0: 0100 0000 8800 0000 7800 0000 4200 4300 ........x...B.C.
000000c0: 4400 4f00 4200 4a00 4500 4300 5400 3d00 D.O.B.J.E.C.T.=.
000000d0: 7b00 3900 6400 6500 6100 3800 3600 3200 {.9.d.e.a.8.6.2.
000000e0: 6300 2d00 3500 6300 6400 6400 2d00 3400 c.-.5.c.d.d.-.4.
000000f0: 6500 3700 3000 2d00 6100 6300 6300 3100 e.7.0.-.a.c.c.1.
00000100: 2d00 6600 3300 3200 6200 3300 3400 3400 -.f.3.2.b.3.4.4.
00000110: 6400 3400 3700 3900 3500 7d00 0000 6100 d.4.7.9.5.}...a.
00000120: 0100 0000 1000 0000 0400 0000 7fff 0400 ................
$ xxd /sys/firmware/efi/efivars/Boot0003-8be4df61-93ca-11d2-aa0d-00e098032b8c
00000000: 0700 0000 0100 0000 6200 7500 6200 7500 ........b.u.b.u.
00000010: 6e00 7400 7500 0000 0401 2a00 0100 0000 n.t.u.....*.....
00000020: 0008 0000 0000 0000 0000 1000 0000 0000 ................
00000030: efcb 7589 bfe7 7a42 a65e 7576 c3ea a5d0 ..u...zB.^uv....
00000040: 0202 0404 3400 5c00 4500 4600 4900 5c00 ....4.\.E.F.I.\.
00000050: 7500 6200 7500 6e00 7400 7500 5c00 7300 u.b.u.n.t.u.\.s.
00000060: 6800 6900 6d00 7800 3600 3400 2e00 6500 h.i.m.x.6.4...e.
00000070: 6600 6900 0000 7fff 0400 f.i.......
$ xxd /sys/firmware/efi/efivars/Boot2001-8be4df61-93ca-11d2-aa0d-00e098032b8c
00000000: 0700 0000 0100 0000 0400 4500 4600 4900 ..........E.F.I.
00000010: 2000 5500 5300 4200 2000 4400 6500 7600 .U.S.B. .D.e.v.
00000020: 6900 6300 6500 0000 7fff 0400 5243 i.c.e.......RC
$ xxd /sys/firmware/efi/efivars/Boot2002-8be4df61-93ca-11d2-aa0d-00e098032b8c
00000000: 0700 0000 0100 0000 0400 4500 4600 4900 ..........E.F.I.
00000010: 2000 4400 5600 4400 2f00 4300 4400 5200 .D.V.D./.C.D.R.
00000020: 4f00 4d00 0000 7fff 0400 5243 O.M.......RC
$ xxd /sys/firmware/efi/efivars/Boot2003-8be4df61-93ca-11d2-aa0d-00e098032b8c
00000000: 0700 0000 0100 0000 0400 4500 4600 4900 ..........E.F.I.
00000010: 2000 4e00 6500 7400 7700 6f00 7200 6b00 .N.e.t.w.o.r.k.
00000020: 0000 7fff 0400 5243 ......RC
$ xxd /sys/firmware/efi/efivars/BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c
00000000: 0600 0000 0300 ......
$ xxd /sys/firmware/efi/efivars/BootOptionSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c
00000000: 0600 0000 1103 0000 ........
$ xxd /sys/firmware/efi/efivars/BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c
00000000: 0700 0000 0300 0120 0220 0320 ....... . .
$ xxd /sys/firmware/efi/efivars/OsIndications-8be4df61-93ca-11d2-aa0d-00e098032b8c
00000000: 0700 0000 0400 0000 0000 0000 ............
$ xxd /sys/firmware/efi/efivars/OsIndicationsSupported-8be4df61-93ca-11d2-aa0d-00e098032b8c
00000000: 0600 0000 7f00 0000 0000 0000 ............
Based on the comments from the past several weeks, it sounds like the only way to get from 3.04 to 3.08d is to either use Windows (which I don’t have a spare NVMe SSD to use) or update to 3.06 first. Neither option is desirable for me right now 
2 Likes
I had the feeling it would come to this but I was really hoping for a more straightforward update method for this last year and a half. I’m a Ph.D. student so, being money conscious, I don’t really have spare SSDs lying around since all the ones I buy are intended to be installed in systems I own.
If I buy a decent M.2 I might be able to reuse and useful to me in a future system, I have to spend at least $50 which makes for a very expensive BIOS upgrade, and this SSD might have to sit idle and unused for several years in case I need to do another BIOS update (if another even ever comes).
I feel this situation has become ridiculous at that point, them leaving us for so long with no update path nor any communication or information regarding this update. I needed a desktop replacement laptop and I was thinking of the Framework 16 but my experience with this BIOS update was the only reason I went with another manufacturer, since for most of the rest, despite the price, spoke in Framework’s favor. I consider, as many in this conversation, BIOS upgrade to be very important as some vulnerabilities or bugs can have serious consequences. This is also why I’ve stopped recommending Framework Laptops to other people after convincing several to buy one when they needed a new laptop.
Regular and long-term updates and support is such an important part of making a product long-lasting tech product and it’s sad to see a laptop touted as easily maintained, repaired and upgradable to not receive the necessary upgrade to prevent it from being e-waste or seriously limiting its potential uses so early after being released.
In any case, thank you very much for the tip! I’ll go the Windows route whenever I can find some time to go through the entire process. Knowing that it went well does alleviate some of the worries I had regarding updating the bios through the Windows route.
1 Like
Correct me if im wrong, but future updates would be able to be delivered via LVFS as long as the retimers dont need updated. This one was unique bc the retimers needed an update.
1 Like
I beleve they pulled the LVFS update from the repo.
Oh, I didn’t know that was the reason. I thought it was due to LVFS and EUFI capsules not being able to update intelME. Could it be both?
I never took a look at how retimers were updated for thunderbolt/USB interfaces tbh and I sort of assumed this was just like any other firmware update since I though they could be updated via LVFS/fwupd & UEFI capsules.
In the case that the IntelME is the reason why this update cannot be done via UEFI capsules, that would mean that any update containing an ME update will have to be done by the Windows route if no (production-level/stable) UEFI updater is released. Am I wrong by making this conclusion?
Retimers can be updated using LVFS, but the CSME update can only be done using an intel proprietary tool.
We have found some of the issues related to port functionality after retimer update and found a fix for them, so we will be able to resolve these further in a future update.
Given that we do not cross validate all CSME firmware with all BIOS firmware, we consider it risky to publish LVFS updates where CSME may be out of sync with BIOS versions.
I think if we get another update from 3.20, we may release limited LVFS updates for the BIOS if the CSME firmware does not change. Eg from 3.20 to 3.21.
Unfortunately for Intel products, this is the situation.
AMD does not require a proprietary CSME updater. So this platform does not have this issue and we anticipate we can publish all updates on LVFS without issue for AMD.
11 Likes
I was able to do this update from 3.04 to 3.08 in linux. The process was a little nuts:
- Drain the battery to 70% (power port can randomly reset when fully charged, which will cause BIOS update to throw random errors as it continually checks for the power cord)
- Power off and disconnect power for 3 minutes to get a clean start (usb-c port can get into buggy states)
- USB boot the 3.06 update from here
- The update ran for a while, updated ports on the right side (I had power plugged in on a right side port)
- The update then failed to the shell complaining about not being able to redirect to etc. This is fine: I looked at the usb-c port and noticed it was off.
- Power off the laptop unplugged for 3 minutes.
- Plug back in and re-run the 3.06 update. Completes fine. It had already updated the right side ports so no reason for it to break this time.
- Power off for 3 minutes to get a clean start again.
- Boot 3.08 update. It ran all the way through.
FWIW:
- I did 3 minute off times but it’s really “at least 90 seconds”
- In the thread I see things failing at all kinds of random points, which I strongly suspect is just the power disconnecting.
- Running ubuntu 24.04, not a fresh install. upgraded base OS a few times.
Results:
I hope some other bugs I’ve been experiencing are fixed, but it seems like it still can’t use my monitor’s usb-c port. It will reset the port when suddenly under load (like loading a web page) and drop the monitor. So I can’t use my monitor’s KVM. Also stuck with HDMI and moving USB cables around.
6 Likes
Can you elaborate why ME is such a problem? Other manufacturers manage to bundle ME firmware into their main BIOS update / capsule. Just as your main BIOS capsule includes the firmware for PD controllers and the SMC firmware already.
Is that just functionality that Insyde does not offer? Or some other complications?
Also, given that your Windows installer has been just a wrapper for Capsule updates and the proprietary Intel ME updater and just tries to initiate all of them in sequence when the installer is executed.
Is something similar not possible for Linux? A script that executes the ME firmware update in place, just like in Windows or the EFI updater, followed by using fwupdmgr to start the Capsule updates?
I know LVFS offers more convenience when it also hosts the update files and that cannot work for ME updates as long as they require the separate updater executable, but for Windows you have also not been using the option to host the updates with Microsoft, but simply provided them via your own download that includes the “proprietary updater”.
Any reason to not just provide the same for Linux? Other than that it is a departure from the LVFS way available to AMD systems?
If updating ME via capsule is not possible in the foreseeable future, this would be the most convenient way to handle the updates. And they’d internally be as similar as before. Capsules whenever possible and running the separate ME updater as you already do on Windows or in the EFI shell.
Just automated, so that users do not forget parts of the update.
3 Likes