Just btw, when you use HWInfo under Windows to check ME firmware versions, there are 3 versions.
Main, Recovery and FITC. Main and Recovery always seem to match, FITC seems a much older version (maybe the one from the factory, don’t know). So my guess is, that those 3 versions linux reports are just that. And across multiple non-framework machines it seems that the FITC version is never the version you updated with any ME update. So I think, only the first and maybe the second version in that version report are relevant to confirm a correct ME update.
3 Likes
Now that’s insightful.
I’ll go ahead add this info to the github ticket for framework-tools.
3 Likes
The BIOS should show the correct version though.
2 Likes
This i can confirm. I cant immediately find what FITC means, but main is updated
Found this thread:
Could be the version of the “Flash Image Tool” used to create the firmware image?
That still sounds rather unbelievable given where we are. Reminder:
- You listed an issue as fixed, that I reported as not fixed. Yet there was never any response or reaction to that. You have since released that version (2nd ReTimer update fails when using the 3.08x Windows updater is the issue) without further notes to users on how to handle this. Even if my setup was known to be the cause of that and so rare that barely any other customer would be affected, I should still be told what it is about my setup that caused that issue. And I believe I was not even the only one who hit that issue.
- You were notified of a bug in the 3.08 Windows installer. Reacted quickly with the fixed 3.08b Windows installer in January. Yet when trying to release the updater in response to bad press, you managed to release the old version without additional notes. It took 2 people posting screenshots of the updater failing on reddit for a community manager to take note and switch out the link. Even though multiple people in this thread posted about it long before. And I notified said community manager of said problem 2 days before the wider public started to take note. If you actually read through the thread and make notes of issues that are reported, I cannot imagine making that mistake for as long as you did.
- to this day, the release notes for the released firmware include trivial math mistakes like calling 2 different software version of the GOP firmware “same” (21.0.1061 vs 21.0.1046). This was also pointed out now months ago (apart from comparing between 3.06 and 3.08, even though 3.06 was never a release and is not otherwise known for customers only looking at the knowledgebase article as they will be on 3.04/3.05).
So I find it hard to believe that technical people read over the feedback here. Or if they do, they seem to not do anything with that feedback or it seems to be ignored somewhere.
Now, you clearly tried not to respond to my actual concern:
You said
It was announced as Alpha, I do not expect a great many of tests.
The point I raised, was that the 3.08b EFI updater as released CANNOT EVER update the right ReTimer.
Unless I am very wrong about how UEFI Capsule updates work (and I don’t think I am, otherwise I would not be writing this. And if I somehow turn out to be wrong I will change my opinion quickly), this leaves 2 options:
- Your testing procedures did not verify that the ReTimer was correctly updated / did not notice that the right side ports do not function (as I understand it USB2 and charging might still work in this case, but nothing else).
- A configuration where you tested the update from the prior release (i.e. 3.04/3.05 factory versions) was not among those configurations that were tested. In this case I would expect somebody to take note of not testing an update to work in the situation that I imagine is the ultimate goal of producing that update and not mentioning it somewhere. For example a “we have only tested on boards with 3.06 and 3.08, but we think it should also work with the officially released versions” would have sidestepped this whole issue.
Now, you clearly did also not engineer that installer only for beta participants. Because customers that ran the 3.08a EFI installer ended up in a state where everything was updated, but the ME firmware. As was reported many times in this thread before and after you pulled that installer. And this combination (everything but ME up-to-date) is not detected by the current 3.08b EFI installer. It instead claims everything is updated, even though ME is still outdated. So I can only imagine your goal in developing the new installer was only the official update path from released firmware version to released firmware version. Which is also the one that does not work. And if I am correct can never have worked.
This also leads to another concern that you seem to not care enough to give people enough information to get into those well-known states that you are designing and testing for (or not as it looks). Something that I also would have considered handled, if you made any public statement after reports of the ME update missing.
Coincidentally, this issue also means, the missing ME update was also not caught by your tests. Sadly, H2OFFT documentation is not public, so I cannot tell myself whether it should update ME firmware like Kieran implied. I only know that it has a commandline flag to update ME (that you have not been using). So I am curious: does it have a very unreliable feature such that it did not update ME for multiple people but did so reliably in your testing? And implicitly without the extra update-ME flag? Then it would make perfect sense why that problem was not caught by internal testing. Or is that like the ReTimer updates now, where you did not have a test that either verified ME updated correctly (as you will not notice unless you check the version) or not a test with older ME firmware that needed an update?
You have also received reports of the hardcoded filesystem path not working for everybody. And I even tested and concluded that this is most likely caused by whether the USB stick the installer is on is USB2 or USB3. The amount of other FAT32 partitions on the internal NVMe (that come before the EFI system partition) also affects it. So again:
- if technical people read this thread, a great solution would be to add a note of that. So that volunteers know when their setup definitely won’t work for the updater.
- If that is instead an area, where you are not even sure if the rules I found are complete and correct, then you should have asked people for whom fs0 is not the EFI system partition to report their file-system mappings and what USB stick they were using. So you have a chance of fixing it.
- If you in fact are aware of the complete rules for that, then it is not acceptable to still not notify volunteers about that known limitation.
In this case it also worries me, that the developer that hardcoded it in the same script that also searches all volumes for the USB stick itself, did not realize that hardcoding “fs0” was either a temporary stop-gap solution (that needs to be documented with a comment and noted when publishing the installer) or that the developer did not think that hardcoding something like that could ever be a problem. And nobody else looked over that small script and noticed.
The other issues with the alpha updater seem reasonable to me for an alpha-quality update (show success message even though it failed for example seems a much more niche case than the basic update from officially supported state to official supported state not working).
And to round out with a little more nuance:
- I am not directing this at specific people. I have no idea who does what and is responsible for what exactly. This is directed at the company as a whole.
- I personally do care a lot less about the speed. Yes the time so far has been a criticism. But I find Frameworks explanation for that plausible, now that we have finally gotten that: mistake in not planning for those resources and it took very long to compensate.
- I want a notebook that is modular, upgradable and repairable. I want to have confidence in that the product either has no issues or that Framework wants to and will fix issues it has with either hardware or software updates. This requires trust that Framework can deliver an update when it needs to. And will tell me, when a hardware upgrade fixes sth.
- What I care most about right now: It looks like Framework is not on a path that leads to reliably working updates any time soon. And you refusing to answer questions regarding that makes me only assume worse. Because the last time Framework was so very vague about things, the reality was the worst possible interpretation where you did not lie: you said you “will deliver an update”. And it took far over a year, dragging Framework by their feet with bad press and mistakes in even selecting the release that was produced months prior in order to actually do it. So if you make it actively look like you don’t see an issue, won’t change anything and I am also not wrong, there would be a very low chance of Framework ever having an installer that works for all the situations it needs to. And it looks like Framework wants to obfuscate that fact by not acknowledging it.
- These are issues of process that are probably affecting all other devices as well
13 Likes
A big wall of text, sadly I do see and agree with most of your points.
I hope they do better with the people onboard these days. Hope the latest reports help diagnose the troubled efi shell code
2 Likes
Hi all,
So I’ve made an updated image for flashing Framework 13 12th intel with EFI.
Grab the file from there: https://aplu.fr/AZqhaWeOBT/Framework_Laptop_13_12th_Gen_Intel_Core_EFI_3.08b_flashdisk.zip (update: it seem there is a bug where you can get stuck on flash loop while the USB key is plugged, I’ll give a look and update accordingly)
Unzip it and simply copy the disk image to USB disk (all data will be lost), for Linux user, simply run dd if=Framework_Laptop_13_12th_Gen_Intel_Core_EFI_3.08b_flashdisk.img of=/dev/sdX
Where sdX match your USB key.
That should work better for flashing both Retimer firmware.
I forgot to mention in my initial post, but one of the issue I had was the thumb key I was using was badly partitioned and not recognized by the BIOS.
The image in the zip use GPT + fat32, labelled has EFI boot device,
I’ve also updated the Startup.nsh script to not use FS0 and let Capsule find it’s on way to find the appropriate device (at least worked for me).
1 Like
I wanted to chime in. I was able to update the firmware via the UEFI Shell update version. It was a little sketch, and it took a long time to complete, but it does appear to be good now.
However, just to report, the bug with the battery charge limit causing the USB ports to overvolt, and temporarily disconnect still exists in this version for Linux users.
3 Likes
I am using a 1280p F13 board with 3.05 and Fedora 40 installed.
-
Downloaded
-
Formatted USB 2 drive GPT+FAT in Gnome Disks
-
Used restore disk image tool in Gnome Disks to write image to USB drive
-
Rebooted and disabled secure boot
-
Booted to USB drive
Resulted in a “Installing system update” loop.
Contact him directly, the normal update to flash various bios parts is to be expected to reboot a couple of times however, the screen should tell you sometimes what it detected and what it just had updated.
I think I replied to him. Not sure what you mean. Anyways, it didn’t say specifically what it was updating - just “Framework” and “Installing system updates”. After it finishes, it reboots. After 15 reboots it was clear something was wrong, so I unplugged the drive. I am still on 3.05. It’s wild that Framework hasn’t fixed this. I get more Intel security updates in a month on my work Dell PC than I have gotten on my Framework PC (zero).
Hum… I think I’ve an idea of what’s going on Capsule updater is failing for one of update and that goes indeed in loop for that case.
I think the easy way is install capsule one by one instead of pushing them all at once.
I’ll update the zip soon to correct that (but not until monday).
1 Like
Hey, I have experienced some pretty weird stuff keyboard-wise, and now it finally prompted me to maybe connect it with the EC update. I still don’t have nearly enough evidence to push this, so I wanted to ask if maybe someone else have also experienced issues mentioned below?
I just updated through Windows 3.08b installer while it was still Beta, but everything else described below is happening on Linux.
The problem: some time ago after an update my Delete button started to misbehave. It would stop reacting for like 20 seconds to 5 minutes, and later randomly continue to operate normally. No signs of mechanical issues, no jammed objects inside, nothing of the sort. But I initially thought this was probably a key switch itself wearing down, which is pretty early for it to go actually, my laptop is now almost exactly 1 year old.
But right now the same thing happened to the Fn button, so this tipped my mental scales towards a possible FW issue.
I understand this issue should be filed on the EC Github repo, but I don’t feel it should be there without significant evidence.
- SYS CONFIG: 12th Gen Intel(R) Core™ i5-1240P
- RAM: Kingston 2x8GB 3200MT/s (KF3200C20S4/8G)
- SSD: Samsung 980 PRO
- Wi-Fi: AX210
- External Devices/Other: None
- EXPANSION CARD TYPES: 2x USB-C, 1x USB-A, 1x Ethernet
- BIOS VERSION: 3.08*
- DRIVER PACKAGE VERSION: Linux kernel 6.8.9
- OS VERSION: Arch Linux
- OBSERVED RESULT: Update successful, but possibly introduced a suspected EC FW issue
- EXPECTED RESULT: Update successful, no issues introduced
UPD: Fn came back just now. 17 hours later. That’s the longest vacation a key got on me yet.
So the safest way to update rn is install windows and use the windows firmware updater?
- SYS CONFIG: 12th Gen Intel(R) Core™ i5-1240P
- RAM: G SKILL 2x32GB 3200MT/s
- SSD: Samsung 980 PRO
- Wi-Fi: AX210
- External Devices/Other: None
- EXPANSION CARD TYPES: 3x USBC 1x USBA
- BIOS VERSION: 3.06
- DRIVER PACKAGE VERSION: Linux kernel 6.8.9
- OS VERSION: NIXOS
^my current setup, new to nixos and trying not to brick my setup.
1 Like
I feel like we should all go on those HN and reddit and Mastodon threads and inform those readers that FW says no such things HERE to their existing users and doesn’t actually do the things that they do say.
3 Likes
I own a 61Wh batter that I can’t use until I get this BIOS update. When can I expect to actually be able to update my BIOS?
1 Like
framework_tool has received a PR that fixes it’s ability to read multiple CSME versions.
Hopefully they’ll release it in a package version sometime soon.
1 Like
Hi Everyone,
Thanks for the feedback. We have updated the efi update to address several of the issues as another Alpha release.
https://downloads.frame.work/bios/Framework_Laptop_13_12th_Gen_Intel_Core_3.08d_EFI.zip
SHA256sum
9da8e5edc6ad43170f1d622d2c20282b604be5b778c408a1aec42d93c12a4889
This modifies the update script to install the update capsule to the boot drive (auto selected), and will update the CSME.
This removes the retimer updates from the update by default, as there is an issue with some ports not working after the update. We are working with our bios vendor to fix this issue in a future bios update. If you want to update your retimers, you can manually execute the updateretimers.nsh script when booted to the EFI shell, but you will need to power off/wait 2 minutes with no chargers attached, and then power on again to clear the error. Not updating the retimers will not have any functional issues, so this is ok to skip this step.
10 Likes
Hi,
I have faced the issue with RAM test error after BIOS update. So my laptop wont boot because it cannot pass the RAM test.
About BIOS update from, 3.05 to 3.08 - this issue appeared first, during the update. Bios update was made via Windows(no usb drive). Laptop did not launch after 30-40 minutes with black screen(power button was glowing).
After troubleshooting it and reading this thread - got the advice to remove RAM and SSD for it to boot. It worked.
After a while I have faces this issue faced this issue more than 10 times already. 3 times during this week, 2 of them right now).
I was woried that bios updates was installed incorrectly and tried once more. Seems like all components are up to date but the issue is preset.
This is so sad because my laptop is my daily drive and this issue forces me to disasamble it every time. Like starting car with a hammer every time i need it)
I will add the steps for the issue bellow: hope it will help. I do not know if i need to create a ticket.
SYS CONFIG: FW13, i5-1240p, DIY edition.
RAM: 16GBx2 SO-DIMM DDR4-3200 1.2V CL22 (Crucial CT16G4SFRA32A)
SSD: WD SN 770 2TB
Wi-Fi: WIFI 6E AX210
External Devices/Other: NONE.
EXPANSION CARD TYPES: Type-C x2, USB-A , HDMI gen1.
BIOS VERSION: BIOS 3.08
DRIVER PACKAGE VERSION: If known and if using Windows.
OS VERSION: Windows 11 Pro, 23H2, 22631.3593
FAIL RATIO: Closer to 100%
STEP TO REPRODUCE:
This is 100% case.
- Press Power button and wait for framework logo;
- Press and hold Power button to turn it of;
- Press power button again.
OR
This happen from time to time. (3/10)
- Press power button.
OBSERVED RESULT: Error code indicating RAM test failure.
EXPECTED RESULT: Successful launch.
ISSUE RECOVERY METHOD:
Issue fixes with different steps from time to time.
Solution 1:
I need to disassemble laptop, put out RAM stich from any slot. Turn on PC and wait for it to launch. Turn off PC. Put the second ram stick back. Turn on PC - fixed.
Solution 2(if 1 failed, to make laptop work with both sticks):
I need to disassemble laptop. Put out RAM stick from slot 1. Turn on PC and wait for it to launch. Turn off PC. Put back on RAM stick to slot 1 and put OUT Stick from slot 2. Power on PC and wait for it to launch to Windows. Turn off PC. Put all Ram sticks back together. Turn on PC - fixed. Laptop now work with both RAM sticks once again.
EXTERNAL DEVICE MODE or NAME: none
3 Likes