11th Gen Intel Core BIOS 3.19 release

Folks, I ran through the instructions here Framework Laptop BIOS and Driver Releases (11th Gen Intel® Core™) to upgrade my firmware from 3.07 to 3.19 using the EFI shell method. (Copy everything to fat32 usb key, let run to completion, etc.)

Everything seemed like it worked… the file was verified and the EFI shell upgrade completed. Rebooted just fine, but everything says it’s still 3.07. (Both the bios screen and the ‘sudo dmidecode -s bios-version’) I can reboot into ubuntu just fine… just didn’t upgrade I guess?

If I try to run it again by booting the usb key it just says already installed. I feel like I missed a step but not sure what. Any ideas?

1 Like

The instructions seem to say that a CSME update is already included in the 3.19 release:

There will not be an LVFS update for this specific release because it has an Intel CSME update, which can’t be delivered through LVFS. Use the UEFI Shell update method instead for this release.

Is there a way to check the CSME version?

Didn’t work for me the first go either. I had to follow the above instructions, and add -allowsv option. Got a green progress bar on the update this time.

  • Extract contents of zip folder to a fat32 formatted usb drive.

Just a bit vague. Exact commands would cause fewer issues, IMO.

I seem to be facing a similar issue - I’m on Aurora. After upgrading to BIOS 3.19 this morning, it worked fine through the day. Then, this afternoon, it got stuck in a boot loop.

In addition to the power button behavior you’re describing, it LED on the side is solid green for a bit, then blinks green with some occasional orange and blue.

In the meantime I could fix the issue by disconnecting the internal battery (and the cmos battery, but I’m not sure, if that had any impact), wait a few minutes and booting the notebook afterwards.

Experiencing the same issues upgrading from BIOS version 3.10 to the latest BIOS version. I’m currently running Linux Mint 21.1 on 11th gen Intel, and I’ve tried the following with formatting the drive:

  • Nuking and reformatting USB drive with Fedora Image Writer for FAT32, extracting the zip package to the thumb drive
  • Re-formatting the drive by running mkfs.vfat -F 32 /dev/sda, and then re-extracting the contents of the provided zip over to the thumbdrive.

Subsequent attempts were executed with the prompt fwupdlcl.efi -F fwupdate.bin -y -allowsv as mentioned above. The last two attempts, I made sure that my battery did not go above 90% to ensure that the machine was in a charging state when attempting another BIOS update and I also reboot the machine after logging into my Desktop after each attempt, to try and force the FW to load on the next reboot to no avail currently. I’ve checked both with sudo dmidecode --type bios as well as booting into setup, and both report the version to be at 3.10.

It’s a relief to know there’s a fix, thank you! Is the fix persistent or did you downgrade your firmware once you got your laptop booting again?

Took me two tries as well, first go-round left 3.17 installed.

I also used the -allowsv parameter, though I didn’t wait for a second failure before adding it.

And the next day booting, we’re back to the old behavior of bootlooping :confused:

I was able to boot again. I have no real idea under what conditions it boots correctly anymore. *sigh*

But at least I found out, that I’m suffering the same issue that dmidecode reports the former Bios version:

	Vendor: INSYDE Corp.
	Version: 03.07
	Release Date: 12/14/2021
	Address: 0xE0000

If you’re seeing the same behavior I was, if you change the line

fwupdlcl.efi -F fwupdate.bin -y

in the efi/boot/startup.nsh file to

fwupdlcl.efi -F fwupdate.bin -y -allowsv

You’ll be able to apply the same firmware update a second time. I’m just blindly following instructions from earlier in this thread, but it got my version number to increment and I haven’t had any problems following that.

My search foo is bad… I didn’t see lots of folks are in the same situation

Sounds like battery status matters? My battery is kinda old. Do I need to buy a battery to upgrade my BIOS then?

It seems like I need to upgrade my BIOS to use the new battery, so that might mean a chicken/egg or hole-in-the-bucket kind of a situation?

1 Like

I reset my main board status and it worked fine, but then after putting my computer to sleep and waking it up, it once again entered the boot loop. I also have deep sleep enabled. I wonder if deep sleep is responsible for this somehow.

1 Like

Oh, that’s something I’m running too! And indeed, it could be happening after a deep sleep.

cat /etc/rc.local

echo deep > /sys/power/mem_sleep

For now I switched to s2idle instead.

1 Like

I hope we can get some help on this one. I’ve made sure the USB stick is really FAT32 (not just FAT) and the battery is in charging state. I’ve done this several times now. The only anomaly I can find is that while the instructions say this:

4.     System will reboot and install the update. 

Mine just sits there with a prompt and I have to reboot it myself. So I wonder if there’s some step that isn’t happening.

Likewise, my system is booting and waking from sleep fine after going back to s2idle. I’m not in the same boat as everyone else, where the BIOS update isn’t going through, with the capsule update failing for some reason.

Same situation here, @David_Krause and @George_Coss. I’m trying to update from 3.06. First time through, script completed successfully, machine rebooted as expected, but I was still at 3.06 after reboot. Second time through, I ran into the “same version” error. After I modified the script to add -allowsv, the update re-ran successfully, but I got the cannot find a valid file system on boot devices error and machine did not reboot. Still at 3.06.

1 Like

Worked for me on Linux. Thank you framework team!

Here’s my experience report with the Linux 3.19 upgrade:

  • Updating from which previous BIOS release?

3.10

  • How did the update go, any issues experienced?

After upgrade, the BIOS was still at 3.10.

Trying to run it again, it refused.
-allowsv made it retry, but after that completed it was still at 3.10.

Upgrading 3.10 → 3.17 → 3.19 worked without any complications.

1 Like