11th Gen Intel Core BIOS 3.19 release

Framework Laptop 13
220

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
221

I also tried upgrading directly from 3.07 to 3.19 and ended up needing to reset the BIOS (via completely powering down the mainboard and then reconnecting the coin cell and main battery) after a s2idle [deep]. Updating through the public versions, in order, (3.07, 3.10, 3.17, 3.19) seems to have worked.

Some potentially relevant information:
Linux kernel version: 6.6.32 (NixOS)
/sys/power/mem_sleep is set to s2idle [deep]
/sys/power/state is freeze mem disk
/sys/power/disk is [platform] shutdown reboot suspend test_resume.

Armchair analysis is that some bit of firmware is not getting updated with the 3.19 capsule updater but does get picked up by something along the 3.07 → 3.10 → 3.17 → 3.19 chain.

If there’s any other system configuration info that would be helpful let me know and I’ll try to provide it.

1 Like
222

I can confirm the following works as well:

3.07 → 3.17 → 3.19

I did the upgrade to 3.17 using the USB key just like the 3.19 upgrade. For whatever reason, going directly to 3.19 fails, but going to 3.17 first works great.

4 Likes
223

Also confirming that 3.10->3.17->3.19 upgrade worked for me, where the 3.10->3.19 direct upgrade didn’t work.
@Sapphire , does deep sleep work as expected for you after a successful 3.19 upgrade?

1 Like
224

At the very least it doesn’t put the system in to a state where it fails to POST, from a quick check. I haven’t tried leaving the laptop in sleep mode for longer yet.

1 Like
225

AT LAST

Holy cannoli, I was finally able to upgrade my BIOS from 3.07 to 3.19.

I’m on Ubuntu 24.04 LTS, Framework 13 11th gen.

Here is what I did.

  1. I upgraded from 3.07 to 3.10.
  2. I tried to upgrade from 3.10 to 3.19.
    This was not so easy. For some reason, my USB wasn’t recognized as a bootable EFI disk anymore, although I’d been using it in my previous attempts. I had to go read F12 Bios Menu not recognizing USB Drive for bios update to 3.10 to solve that one. The TL;DR is that you have to set the boot order to First or Last. If it’s Auto, then you can’t even see it in the BIOS settings, much less the BIOS boot menu. Then, startup.nsh thought that I was trying to install the same version. I did the -allowsv thing and it didn’t help!
  3. I upgraded from 3.10 to 3.17.
    This seemed to go OK. By this point I’d done a metric ton of reboots into the BIOS, reboots to try to boot from my USB drive, and multiple operations to change what versions of files were on the USB drive itself. It was time consuming and confusing, so I made sure to delete everything from the USB drive every time so as not to get part of one version and part of another.
  4. I upgraded from 3.17 to 3.19.
    This time, it recognized that I was upgrading to 3.19 from a different version. Instead of the text/CLI progress that I’d seen before, I got a really nice graphical UI that said Please wait while we install a system update with a nice progress bar.

Now, sudo dmidecode -s bios-version reports 03.19 as it should. The takeaways for me are that you might have to go version by version, rather than jumping from 3.07 to 3.19, and that some of the upgrades might change BIOS settings such that you won’t see your USB stick in the boot menu.

9 Likes
226

After trying many things to go directly from 3.07 to 3.19, or even from 3.07 to 3.17, I followed the same sequence as @Peter_Conrad and am now running the 3.19 version.

I had secure boot enabled before trying, so I did have to disable secure boot in the BIOS, but other than that, the upgrade from 3.07 → 3.10 → 3.17 → 3.19 was a success using a FAT32 formatted USB stick. dmidecode confirms 3.19, and the BIOS screen seems to confirm the CMSE update, as well.

Really appreciate Peter posting his sequence.

Framework team could possibly help people out by suggesting to go one version at a time on the 3.19 release notes. I had not been keeping up with BIOS updates, but got an e-mail from 3.19, and tried to just jump ahead, which many of us tried to do, judging by the comments in this thread.

5 Likes
227

11th Gen Intel - Ubuntu 24.04 - had BIOS 3.10 from a previous update, updated to 3.17 successfully, then updated to 3.19 also successfully.

228

Has anyone had difficulties going from 3.17 to 3.19? I have a Gen11 running Fedora 40. The USB thumbdrive creation appears to be no problem. I can boot from it and it starts the BIOS update and appears to complete and reboots. But when I check the BIOS it still reports 3.17.
If it matters this is a 13 inch system.

Has anyone else experienced this?

1 Like
229

Thanks, @Peter_Conrad and @David_Krause for your detailed accounts. I too was finally able to upgrade incrementally (3.06 > 3.10 > 3.17 > 3.19). I re-enabled secure boot after upgrading to 3.17, since the 3.19 upgrade instructions didn’t call for disabling it. Agree that it would be nice if the general instructions recommended upgrading incrementally.

230

Deleted.

I started writing a post that I thought was going to be about a bios bug not saving settings, but it was a dead coin cell.

231

I was on Bios version 3.07, tried to do the UEFI update to 3.19. It ran to 100%, then restarted. I checked the BIOS version and it was still 3.07. I tried booting to the thumb drive again and it gave an error saying it couldn’t migrate to the same version, which makes me think the update did run.

What am I missing? I checked dmidecode and booted directly into the bios to check the version. I’ve confirmed I used the correct version for my Linux and my 11th gen 13" framework.

232

Hi Eric.
It seems you would need to do the updates in order, i.e. 3.07 → 3.10 → 3.17 → 3.19 (see this post)

1 Like
233

I also noticed this when I just did the update. Also from Fedora 40

The EC still reports its previous version too. Only thing that appears to have updated was the ME.

234

I’m seeing the same CapsuleApp errors, am trying to update starting from 3.17. I have added the -allowsv flag, since I’ve attempted this a few times now. This is on arch.

In full, this is what I get:

FW Update: [100% (1)] Do not Interrupt
FW Update completed successfully and a reboot will run the new Fil
FSO:\> CapsuleApp.efi winux.bin firmware_hdr.cap -OD
CapsuleApp: creating capsule descriptors at 0x439E4B18
CapsuleApp: capsule data starts at 0x3EA4C018 with size 0x45422
CapsuleApp: capsule block/size 0x3EA4C018/0x45422
CapsuleApp: creating capsule descriptors at 0x439E4E98
CapsuleApp: capsule data starts at 0x30840018 with size 0x2208904
CapsuleApp: capsule block/size 0x30840018/0x220B9D4
Error: Cannot find a EFI system partition!
CapsuleApp: cannot find a valid file system on boot devices. Status Not Found CapsuleApp: failed to update capsule - Not Found
FSO:\>

It’s clear that the CSME has sucessfully updated to v0:15.0.42.2235, but the bios dmidecode output is still 03.17.

I suspected that @Michael_O_Donnell was on the right track with the updater getting confused by inconsistencies

for example, if the CSME install succeeds on the first try but EC/BIOS fails, then later EC/BIOS updates will fail because it’s on an unexpected CSME version. I tried reinstalling 3.17 to revert my CSME (not even sure if that packages a CSME, actually) and then upgrading to 3.19. But I had the same result. Stuck on 3.17.

I’ve tried in various states of battery life + charging/no charging, no dice. Any suggestions?

1 Like
235

How much space is available on your EFI system partition? The EFI shell should display it if you run dir fs0:\, or you can check it from your OS.

You’ll need at least 64MB free. If you do not have that, the updater may not consider the volume viable.

2 Likes
236

Thanks for the tip, I’ll check that next time I sit down :slight_smile:

237

You can also try to run CapsuleApp -F (no other arguments!) to see what it thinks about your available volumes.

If it doesn’t find any at all, then you have a slightly different problem… you’ll want to verify that the partition type in your GPT is C12A7328-F81F-11D2-BA4B-00A0C93EC93B or, shorthand, EF00. You can do this with gdisk on Linux (gdisk /dev/nvme0n1 then p), or Diskpart on Windows (diskpart, sel dis 0, sel par 1, detail par – assuming that your ESP is partition 1). If it’s not, you actually don’t have an ESP. This could break any number of tools.

1 Like
238

On Fedora 40 I downloaded the zip file again to a new thumbdrive and unzipped it and this time it and after reboot I was on 3.19. The update process the second time showed a progress bar during update but the first time did not. It simply rebooted.

Check your hardware and downloads.

239

You may want to try the Linux updater I found and tossed up so you can just do the CSME. That’s what I did for my device. There’s info posted above where to find the zip I shared.

I do wish that Intel would post those directly for the devices as there’s different tool suites based on chipset, and the one I posted matches the hardware.