12th Gen Intel Core BIOS 3.08 Release

Framework Laptop 13
265

My BIOS firmware update silently failed.
I only ever saw one progress bar in the whole process, where it should have been 3 based on what’s said on the original post.

Windows is saying the update failed here:
image

It’s still INSYDE Corp. 03.05, 2022-08-23
FRANDACP06 - i7-1260P - 64 GB RAM - Windows 11 23H2 (10.0.22631 Build 22631)

I believe it may have happened because I didn’t plug the power? But now how can I retry?
It did automatically retry once when I didn’t expect it but I still didn’t had power plugged in.
Rerunning the msi file doesn’t change anything.

266

The MSI only force-installs the ME firmware and then “installs” the firmware capsules with Windows (what you have open in DeviceManager). Once they are installed, installing them again does not do anything. And Windows will hand those updates over to the BIOS for self-updating, when Windows considers it out-of-date and feels like it.

I do not know what makes Windows retry it, but you know it does, when the status of the firmware update tells you that it requires a restart.

With the retimer update that failed for me, I think it just took a reboot for Windows to mark the update for retry.

267

So…should we update? I’m still on 3.04. My gut is telling me to wait.

268

From what I have read in this thread, nobody reported regressions with the actual firmware.
It is just the installation process that is buggy (just as buggy as before, basically no change here / they added the ME update that is forced to overwrite).

So it seems like the update has a bunch of benefits, fixes a bunch of overdue security issues without any regressions. If you can deal with the pain of the update process.

But clearly one can make the argument that whatever FW says cannot be fully trusted. But also, no indications so far of this getting any better with more waiting.
And the way they have handled firmware updates so far, across all devices, I kind of don’t believe that the release firmware was handled any different: i.e. the release firmware is just as likely to contain undiscovered compatibility bugs as this release. So the unknowns are not really increasing.

2 Likes
269

Thanks for the fast response. I’m still inclined to just wait a month. I did plan on switching to Linux later this month when Fedora 40 is released. I’ll probably just swap the NVME drive back to windows when I’m ready to update the BIOS.

I still find it curious that this was not “officially” announced. Feels like a silent announcement where they updated the page and told no one.

270

FWIW, I’ll probably be doing exactly the same.

The whole situation has been quite frustrating to say the least, so I think extra caution is warranted. I use my laptop as a daily driver. Can’t afford to take chances.

I also think the fact we haven’t heard anything official here or otherwise should give pause.

Perhaps an admin can weigh in here (I hope).

2 Likes
271

When making the decision on whether to risk the buggy beta update, it’s worth considering the number of old well-known vulnerabilities in the older versions (especially pre-3.06). So your choice is really between:

  1. Risking a buggy update from prematurely released firmware, or
  2. Knowingly sticking with a vulnerable BIOS.

It’s a crappy situation all around. It’s common to define end-of-life for computers as the point when they stop getting timely security updates, and I think the 12th gen has fallen in that bucket for quite a while now.

3 Likes
272

Hi there,
Over the past 1.5 days I’ve been dealing with this exact issue. Ran the .msi but my BIOS didn’t update, device manager was complaining, and half my ports didn’t have video output. I also noticed that the .msi wouldn’t do anything after I’d run it once. Tldr, support got back to me and told me to run the EFI shell update (listed below the windows .msi instructions), and nearly everything is fixed! Only minor issue is the retimers23 has a Code 10 in device manager, but my BIOS is updated and my ports are working.

Details:
I’m currently running a FW13 with a i7-1260p using Windows 11 Version 10.0.22631 Build 22631. My port configuration is 1x USB-C, 2x USB-A.

I attempted to update my BIOS from 3.05 to 3.08, and after running the .msi, I was still on 3.05. After plugging my laptop into an external USB hub, I noticed that the right-side ports no longer have HDMI functionality. The left-side ports still worked fine. After some community support, we found that in Device Manager under Firmware, the BIOS and Retimers 23 items contained a yellow warning symbol, with these messages respectively:

“This device cannot start. (Code 10) Firmware update was unsuccessful.” (BIOS)
“This device cannot start. (Code 10) Indicates a revision number encountered or specified is not one known by the service. It may be a more recent revision than the service is aware of.” (Retimers 23)

Both also contain events saying “Device configured (oem134.inf)” and “Device not started”, and the times correspond to when the 3.08 updater was run.
I also noted the faulty Retimers 23 had a firmware version of CF, while Retimers 01 is working properly and has firmware version 136.

After emailing support and doing many things like testing memory stability, reinstalling the driver package, and resetting the BIOS to default settings, the thing that worked was using the EFI updater method. I’d definitely recommend being attentive while the process is running and making sure you’ve got a reliable AC power source. As for the file, FW has pulled it down officially, but you can still find ways to get it from this forum thread.

As always, checking with support is a good idea, and they were very responsive and polite. I hope your issue gets resolved soon!

2 Likes
273

yes, 12th Gen Intel Core BIOS 3.08 Beta Release - #209 by jmariondev is where the link can be found.

274

Does this still happens?
I’m now afraid to upgrade as I’m mainly using a Thunderbolt 3 eGPU enclosure as well.

1 Like
275

I’m pretty sure going the EFI way will be flawless so I’m not sure why it’s been withheld but now I’m mostly concerned about a potential regression another user posted:

And it seems I won’t be able to downgrade to my current version if I want my ports to function properly?

I really don’t want to risk having issues with an eGPU…
Does someone else has any feedback about using an eGPU with this latest firmware?

1 Like
276

Precisely what I observed with the ReTimer updates. Back when I updated my machine to 3.06 and again when I updated a 2nd machine to 3.08 (from factory BIOS, same ReTimer updates).
And the original 3.06 update thread explicitly listed to power off the machine for a few minutes when that happens, then the Windows-based update of the missing ReTimer resumes.
So in other words this was a known issue for 3.06 over a year ago, that is not listed in this thread, but never actually went away as the issue is probably in the updater-part of the BIOS that is already on the device.

Fascinating that support would recommend the EFI Updater, that FW pulled for “instability” instead of giving their own, confirmed workaround. And nobody thought to update this thread…

1 Like
277

Its not the firmware they pulled, its the update method (and tools that will do this for you). Worked fine for me and some others. I cant find the reports in the thread tho, so might have been reports to support itself. They did update the top post and this reply: 12th Gen Intel Core BIOS 3.08 Beta Release - #189
Maybe they still working on when what method works and which methods break when.

278

I only recently stumbled across this thread, so I don’t have context for the prevalence or severity of the EFI instability. I am glad that the EFI updater appears to work, I’m guessing because it’s more direct and doesn’t have to go through the OS itself. I’m happy that there is at least a path forward for people who encountered the issue I did, but I hope that FW is working on a reliable updater, whether it’s EFI or in Windows, as well as fixing whatever bugs remain in 3.08.

279

As my text says, I am referring to the Updater that was pulled for instability. Not the firmware itself. Once that is successfully installed on your device the method by which it was installed should not matter.

And actually, the OS is barely involved. The LVFS and Windows updates for Intel FWs use Capsule-Updates wherever possible. That means the OS just forwards the firmware files to the BIOS and the BIOS decides what to do with them, namely updating itself. If you have a capsule, it should work the same on Windows or Linux, because the same BIOS takes over after the required reboot. And both Windows and Linux do not have to do much themselves.

Problem is only, that Framework is apparently not setup to update ME firmware from a capsule (other manufacturers have that), so they need, in addition to the capsules, a manual updater from Intel (FWUpdLcl) for that, and that will be OS specific and according to Framework only exists as EFI executable and Windows executable, not for Linux.

The EFI-Updater does not seem to use the Capsule-method, but Insyde’s updater-executable (H2OFFT, that is also used for the AMD-systems for the Windows updates, but also only seems to exist as EFI or Windows executable). That gives it greater control. And in this specific case means it logs its outputs to the screen, so you can see what is being updated and why it fails, which the BIOS-integrated updater does not show (to us. It can report some status codes back to the OS that initiated it. No idea how detailed that error report is though).

The EFI-Updater also handles the PD controllers firmware separately, as those must not restart if the device is standalone, without battery and currently being solely powered through one of those PD controllers. Something, that FW apparently did not account for with the self-updating of the BIOS.

The instability of the EFI-updater seems to stem from the script FW uses to tie the various EFI updates & executables together and how it does not handle all situations. Like when some drive is behaving unexpectedly etc.

But in general, Capsule-Updates are the superior way, because the manufacturer has the most control over what is happening during the upgrade. Only the manufacturer-provided BIOS is running, the user is not involved in setting up a drive with a (minimal) OS on it to run executables that make critical changes to the system. Configurations and modifications to the OS the user could have made are irrelevant when the device is self-updating. But for that the self-updating has to work fully and reliably. Which it obviously does not.

5 Likes
280

I have a 12th Gen Intel Framework laptop that I dual boot Windows 11 and Fedora 39. I saw that the 3.08 Bios is now listed on the “Bios and Driver Releases” page . So I decided to pull the trigger and update. In Windows I downloaded and ran the .msi installer. The installer seemed to run correctly and proceed to tell me I need to reboot to complete the update. I reboot and… the laptop just boots back into Windows (my default boot choice) like normal. It didn’t run any additional update. Isn’t it supposed to perform some updating after reboot? I run System Information in Windows and see that I’m still at 3.5 not 3.8. Am I missing a step?

3 Likes
281

I have little issue and use an A770 eGPU. Any issue I have are more related to hardware than software/firmware I feel

282

Arstechnica.com has an article on the firmware issues Framework users have been facing.

18 Likes
283

Would have been nicer of FW to make a similar comment on this thread to what they are doing with BIOS updates, even a copy paste of what they said to Ars Technica.

7 Likes
284

Reading that made me feel so bitter it hurts. I said much the same a year ago and got slapped so hard I stepped away for months. I was called insulting and toxic. Suddenly everyone is seeing the light and yet there is not growing demand for Framework to pivot to Coreboot, which I have yet to see an articulated argument that explains how pivoting to Coreboot permanently wouldn’t fix these issues with firmware. Maybe I don’t understand Coreboot maintenance and how platforms are supported over there (very likely since not a dev) but I would think firmware would be easier (note I didn’t say easy) if it was Coreboot instead of Insyde.

7 Likes