Regarding something more in line with the topic of this conversation, what does this mean in the specific context of this BIOS update? Will we ever see a stable/production-level EFI updater? And if so, when/what is an honest a reasonable ETA?
There has been zero communication from Framework since May and that was 4 months ago. I want to stress out that this is a serious issue and the only reason why I didn’t go with a Framework 16 for a desktop replacement laptop. This lack of communication and software support is very concerning and not reassuring, thus preventing me, and probably many others, of investing again in Framework hardware given our current experience.
Additionally, will we see similar delays and issues for every update that includes an update to Intel ME or any time there is something difficult regarding update to a specific bios/firmware component?
Let me clarify a bit more. As I made a statement in my post above that was too broad.
Starting at 13th gen Intel, we can update the CSME region using capsule update, so this can be distributed using LVFS. You can also check the CSME version using the ESRT table (eg fwupdmgr get-devices) which is fully exposed.
For 11th and 12th gen however, this was not supported by the BIOS vendor, so we were not able to support this.
Yes we are looking at what it would take to bundle the CSME updater utility in Linux along side manually installing the update using fwupdmgr. But I have a lot of concerns about doing this method.
we have to cross test a lot of distributions. Various kernels etc.
If users follow the exact flow that we currently do using EFI/windows, we want this to be as foolproof as possible(which is a low bar). I still have a lot of concerns that asking a user to perform manual steps for a multi part update process, and unexpected issues from the large number of linux distributions will cause a lot of customer unhappiness. Eg if we release a manual process, and it does not work on some distributions, then we will end up with even more unhappy people that are upset in the community.
So for me the priority is to fix issues and improve the update process on EFI first (which covers the broadest possible set of use cases). And then we can start looking at enabling a manual LVFS based updater.
I am also working on revamping our instructions, and improving bug reporting. As we are getting lots of valuable feedback from the community that we are going to improve our updates with. As well as regressions that the community is reporting. However in the last few updates community feedback has been very light, and repro steps and descriptions could be much better to allow us to narrow down on the issues faster.
We really appreciate all the community here, and your support and feedback. We are getting this into our ticketing system and trying to repro cases as well. So that we can keep improving our firmware.
I would like to suggest again, that you put info like this, especially that is aspirational in nature and shows that some things are going on behind the scenes and in which direction we are heading in some place more visible. Like the blog or maybe even the knowledge base for the “supported features” parts. At least for me, this kind of info moves the needle. I use info like this to decide whether I would recommend newer Framework products to others or would want to upgrade to newer boards.
And I think you are shooting yourself in the foot by publishing for example the 13th gen update just using the same quote you have been using on 12th gen and earlier, stating that LVFS update is not available:
I presume the reason is more, you already had the beta EFI updater and Windows updater from 12th gen that use the separate ME updater executable and it was just easier to reuse that. And the answer “unified ME updates and LVFS updates are possible for future updates of 13th gen and newer, but we are not ready for it yet” would have been much more accurate and informative.
Understandable. I always overestimate the capacity of other users to use a commandline successfully.
But on the other hand, your current EFI update procedure, as published for 13th gen includes a quick-time event to interrupt the default script and includes running a command on the EFI shell without extremely explicit instructions. So you are already doing similar things with firmware updates.
Also you are saying things like
without stating any reason for why anybody would ever want to run this update.
That sort of thing makes me question what is going on with your firmware updates, if Framework cannot even state the pros/cons of doing sth. optional. I would assume it either fixes bugs or improves the power consumption for some combination of expansion cards. Because if it adds nothing, why are you even offering it, especially in this way.
I have tried to update BIOS from 3.04 to 3.08 and got the error: Script Error: Invalid Parameter (Line 116).
What did work for me is first upgrading from 3.04 to 3.06 as described on: 12th Gen Intel Core BIOS 3.06 Beta This also failed during the update process. I removed AC, waited 5 minutes and it did finish just fine.
After that the upgrade to 3.08 went mostly without hiccups. For some reason I had to swap the USB-A to bottom-left port since BIOS wasn’t recognising bootable media from the top-left port.
I am a super happy panda now, because my Framework Laptop is much faster! I suspect that the Linux kernel blocked some BIOS vulnerabilities in a version 3.04, which slowed it down massively. Everything works flawlessly now.
another report of a successful update (maybe to counterbalance all the failure reports that scared me away from daring an update for quite some time…)
Using the EFI shell update for both updates (3.04->3.06->3.08)
followed all the instructions
had my battery at 64% when starting (that’s my usual charge limit, which I changed to 98% before updating to have a “normal” charging situation (I see empty battery warnings in KDE/Plasma occasionally, which go away by themselves after a few seconds))
had my USB stick in a lower left USB-A port
Both updates ran through without any complaint, no need to restart anything in between (of course the reboots initiated by the updater(s) occurred)
Even ran the timer update without any trouble (I have no real clue what that does though)
The absolute only “issue” I had was that when I tried to boot from USB after pressing F12 to get the update started, my thumb drive sometimes didn’t show up. Un-/replugging usually helps, if not another restart made it show up. Please note that that only happened at the very start of the update and not for the automatic reboots done by the updater.
Borrowed an NVMe SSD from work and performed a fresh installation of Windows 11 23H2. Installed the drivers from the support site and made sure Windows updates through 2024-08 were installed. The 3.08b MSI upgrade started off looking good, but after seeing the system update progress bar, the laptop shut down. Manually booting to Windows 11 and checking Task Manager showed the firmware upgrade had failed. Tried the upgrade again, and no difference. None of the system components upgraded. Next, I tried the older 3.06 beta MSI installer, but that didn’t work either.
While still using the Win11 SSD (formatted by Windows 11’s installer), I tried a fresh copy of the 3.08d UEFI updater. That still failed with the same UpdateCapsule error message I experienced and other users reported. Then, I tried the older 3.06 Beta UEFI updater, which also failed (I didn’t record the details).
Finally, I formatted the borrowed SSD with Ubuntu 24.04’s installer. After a quick reboot I tried the 3.08d UEFI updater. It still failed with the updatecapusle error. Then I tried 3.06 beta UEFI, AND IT WORKED! With the laptop updated to 3.06, 3.08 finally installed using the UEFI updater.
My takeaway: The upgrade process for 12th Gen laptops is broken. Based on the conversation in this thread, I knew going from 3.04 to 3.08 was practically impossible, but I honestly expected the Windows package to work on a fresh OS install.
I was already on 3.06, so only had to update to 3.08d using the EFI installer. Used an old 1GB USB 2.0 stick in the lower-left port, freshly formatted as FAT32. Everything worked on the first try. After the successful update, I updated the retimers too, which worked as well.
So, on one hand, yay! Success. On the other hand… a simple BIOS update shouldn’t be that scary. On my old Dell laptop, running Arch Linux too, fwupdmgr was enough to install BIOS updates, and I never had to even think that things could go wrong. It just worked. Framework team: I know you can do this, and I firmly believe that this community here is wanting to help. So, please get us there!
Should I be able to update to 3.08d from an earlier 3.08 (likely 3.08b)?
I put 3.08d on a USB stick and booted to it, but the laptop thinks it’s already current on “Version: 03.08”, release date 12/25/2023, build version “hx30_v0.0.1-4ea1c89 2023-12-11 14:15:35 runner@fv-az1124-221”.
In this case, all sub-variants with letters only changed the installer, not the actual firmware. That would be why the firmware versions listed are “3.08” for all of them.
FWIW, I can reproduce this with BIOS 3.08 and Intel LPMD 0.0.7 on Fedora 40 (I built the RPM using the Fedora RPM spec for rawhide) running kernel 6.10.10. I also have a Framework laptop with the Intel Core i7-1260P.
I never tried LPMD on an older BIOS version so no idea if it’s a regression or whether any firmware version ever supported it.
External Devices/Other: HDMI Monitor, USB-C hub with wireless keyboard and USB stick containing the firmware update (both attached to the hub).
EXPANSION CARD TYPES: 1 USB-C, 1 HDMI
BIOS VERSION: 3.05
DRIVER PACKAGE VERSION: Not using Windows.
OS VERSION: Debian 12 Bookworm.
FAIL RATIO: Can you reliably reproduce this issue 100% of the time? Is it only 50% of the time? Occurs randomly?
STEP TO REPRODUCE: EFI Shell via USB drive.
Step 1 - Boot with the USB stick plugged in, press F12, select to boot from USB. It’s important to say that I did not disable Secure Boot.
Step 2 - The EFI script booted and started the upgrade process.
Step 3 - I had the error unable to redirect to file happen to me. I was dropped into the EFI shell.
Step 4 - I read some posts on this thread, and decided to reboot the machine. So I typed exit in the EFI shell.
Step 5 - I was immediatelly dropped into the boot selection screen (F12) again, i.e., the machine did not reboot.
Step 6 - While inside the boot selection screen, I noticed a new entry called BIOS upgrader (if I recall correctly).
Step 7 - I chose that entry. The EFI script booted again, and this time it actually started upgrade the BIOS. The upgrade succeeded, according to the script’s output.
Step 8 - The system automatically rebooted. I started pressing F2 repeatedly in order to enter the BIOS and confirm that the upgrade was correctly done. The system did not enter the BIOS screen and rebooted one more time.
Step 9 - I pressed F2 repeatedly again, and this time I was able to enter the BIOS. I noticed that the version is still 3.05.
Step 10 - I booted into Debian, ran dmidecode and confirmed that the BIOS version is still 3.05.
Step 11 - I decided to try the upgrade process one more time. I rebooted the system, pressed F12, and selected the USB stick containing the BIOS upgrade again.
Step 12 - The EFI script booted, but this time it refused to proceed with the upgrade because it says the BIOS is already at that version (3.08).
OBSERVED RESULT: I can still boot my system and use it normally (at least I believe so), but the BIOS upgrade did not succeed and now I’m not able to retry it because the script thinks I’m already running version 3.08.
EXPECTED RESULT: Obviously this one, we expect it to flash successfully and be reflected in BIOS settings.
ISSUE RECOVERY METHOD: I’m not able to retry the upgrade process anymore. My BIOS says its version is 3.05, while the EFI upgrade script thinks the BIOS version is 3.08.
EXTERNAL DEVICE MODE or NAME: Generic USB flash drive.
Should I file a support ticket providing the information above as well? It’s not clear to me if there’s any official position from Framework on how to proceed with these failed upgrades.
Apologies if someone already asked this, but the thread is too long and I couldn’t find this specific information.
I’m not sure if there’s a recommended way to tell if your retimer firmware is up to date or not (the quoted sentence implies there is?) The best method I’ve found on Linux is by reading EFI variables to get the retimer version:
The key part of each output is the bottom line with the value. 36 01 00 00 is 0x136 which is decimal 310. This matches the suffix of the Framework_Laptop_12th_Gen_Intel_Core_Retimer_port??_310.cap files in the zip file, so I assume this means the retimers are both up to date on this system.
)