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.
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.
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.
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)
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.
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.
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!
)