I tested the update with following setup:
The update failed with following result:
Hello,
I had same issues as others using the EFI based update to update Retimer23… after many attempts, I found the issue.
The retimer23.cap is the same file as retimer01.cap, grabbing the retimer23.cab from the MSI for windows (extract it with 7zip) and replace the file, I was able to have all fw updated to the latest release.
Also, I had to force a flash of the BIOS by adding -allowsv flags.
And finally -OD FS0 from Capsule command can be removed (at least on my side), that was able to flash without any issues.
That command only updates ME firmware. Not the BIOS. That is done by the firmwarehdr.cap in the same line as the 2 ReTimer capsules. And the only reason the ME updater would refuse, but run with the -allowsv flag is, because the ME firmware was already updated on a previous run. You’d have better removed that line or commented it out (‘#’). Although I would have thought it would just show you its message of not doing the update (“because up-to-date”) and continue on with the rest.
But you are right, the header information for both capsules actually even states “Framework ADL Retimer01 (Left)” and targets the GUID of the left ReTimer. Fascinating that CapsuleApp would not even warn of trying to target the same GUID twice.
@Kieran_Levin @nrp I am aware you called this “alpha” state, but at this point it is proven, that nobody could have successfully run this update on even a single test machine. And that is what you choose to publish for your customers? That is WAAAY beyond experimental and just plain incompetent.
This deserves an IMMEDIATE and PUBLIC post mortem of the chain of things that Framework did wrong to end up at this point. Otherwise, Framework can absolutely not be trusted to ever deliver on anything firmware related. Are those these process changes that enable you to release firmware updates faster that you promised? Just skipping any semblance of quality control? And not even monitoring the thread where you asked for feedback for your broken installer? Is this the quality work that is delivered by that new team you contracted?
It has been 2 weeks. Everybody that tried the new EFI installer and did not have already updated ReTimers ended up with a half-bricked board. And you did not the slightest bit of troubleshooting after failure reports, that would have clearly told you that the update is inherently broken (apart from the other issues with the script) and needs to be pulled, fixed or for once get updated “KNOWN ISSUES”.
Are you actually just testing all 12th gen updates on boards that are already on 3.06 version and already have the ReTimer updates? And that is how you end up believing that the ReTimer updates work even though you have never actually tested it?
Need I remind you that you claimed for the 3.08 Windows installer, that issues with updating both ReTimers from Windows are fixed (point 6 of your change notes), even though that has clearly not been the case? I have been reporting that issue before and after you released 3.08. And you have still never updated the Known Issues for that installer. I had hoped that maybe it was just very rare and it was my bad luck that I hit that issue on a sample size of 1 (in exactly the same way as I hit it when updating another board to 3.06 beta back when that released). But by the looks of how you cannot possibly have tested the new EFI updater (or the previous EFI updater for that matter), I am starting to believe you are just not testing it all.
And in light of Frameworks problems communicating openly on this issue, it seems that your customers have to assume the worst case for every possible situation until such a time as Framework chooses to actually begin admitting mistakes and actually explaining how things are being changed, so that those mistakes will not be repeated.
@Ray519 I’ve seen your rants in a number of threads on this forum, and also in the comments in the ArsTechnica article, and probably elsewhere too … and because you are mostly technically correct, I want to urge you to keep it short and sweet, and just let it go sometimes. The probable result of posts like yours, is that the technical people inside framework don’t read these threads, they are only skimmed by forum/community managers who can’t recognize the valid technical points (or don’t have a way to raise them to some engineer).
Firmware for this kind of device is hard (and it seems is 99% done by remote contractors), but these mistakes were really silly. Multiple cases of: using the wrong file. (The EFI installer retimer23.cab, and also the windows installer posted for the first few days of the official non-beta release.) The EFI shell script is also a basic thing with simple errors (EFI partition selection, ME updater flag …). In a long-history high-drama firmware release like this … come on framework, you need to find someone sharp, who at least keeps track of what firmware file is what, to manage this.
I do tend to write longer posts, you have a point here. And you may argue that me posting here about how the installer works to the extend I have may water down the thread.
But this is not just silly. That is bad to a degree where you really have to question the qualifications of whoever did it. It exposes fundamental problems. If I was responsible for whoever did that, I’d need a damn good explanation as well. Or that somebody needs a lot more supervision.
This thread is specifically for feedback on pre-release level software. This was explicitly requested for the new EFI Updater. If no technical person / developer involved is reading and reacting to that feedback, the entire thread and public “alpha” installer should not exist. Or it should contain guidance on how to file reports, such that they are actually useful to the developers that want that feedback.
Very different type of error. The installer was just too narrow in the boards it accepted. While showing some lack of care, it did not risk any devices and to some extend is the purpose of a beta. I was completely happy with how that was handled. It is the fact that they released the wrong version 4 months later that also exposed other fundamental problems in Frameworks processes.
I try not to rant, but be constructive. My whole point was, that it is proof, that the newest updater could not have been tested. EVER (at least for the purpose of updating from previous release). And just like with a review of the entire notebook, my goal is that less technical people can gage the level of quality that can be expected from Framework to make informed decisions. And that this instance is an extremely worrying and unprecedented failure on a very technical level that undermines the trust in future updates released by Framework. Again. And it is in the best interest of everybody involved to restore that trust quickly.
replacing retimer23.cap in the bootable USB with Framework_Laptop_12th_Gen_Intel_Core_Retimer_port23_310.cap from extracting the Windows MSI has resulted in the Retimer version to be reported to be updated to the same version as the left for me.
However, I’m still seeing an introduced oddity from the OS using framework_tool --versions in the CSME part of the report expecting /sys/class/mei/mei0/fw_ver to show 3 of the same version numbers, where mine now does not.
I’m tracking this on the GitHub issue: panic when trying to get csme data with --versions flag · Issue #35 · FrameworkComputer/framework-system · GitHub
Auch, thats a painfull mistake by FW. hope they notice. My guess is this update would have worked fine then for me way earlier.
I just checked the thread on github, I can confirm that my laptop does still also report the CSME versions as :
0:16.1.30.2269
0:16.1.30.2269
0:16.0.15.1810
I upgraded with the help of the old EFI and forced the CSME update manually. Reading the posts about the new updater, I essentially used the method that is now integrated into the script.
The last version that is reported seems to have been included in the 3.06 BIOS (which I never installed). I currently do not plan to investigate further, especially looking at the state of the new EFI updater. But if it helps the system has been mostly stable for the last few months.
I don’t know what this implies for security or the state of the CSME (but I have abandoned the idea of using a framework for any security critical stuff with the current state of the software support).
If people would let it go sometimes, we probably wouldn’t even have a version 308.
Framework seams not to listen if people are quiet and express their concern only once or are quiet if their concern was expressed already.
Everyone,
Appreciate the feedback, however, we absolutely do take all feedback seriously.
In terms of expressed concern and frequency, if we determine there is something needing attention, we do everything possible to address that concern.
That said, yes, this process has not been what we want and we are doing everything we can to balance out an outcome that matches our customer’s expectations, reality in terms of release state and our own expectations.
We have been hyperactive in collecting community provided data, doing our due diligence in reproducing user experiences to ensure everything is where it needs to land.
The EFI updater very much is a focus of attention, work and forward movement. There are number of considerations we must focus on to make sure when it’s ready, it works well for everyone.
Look, I am a full time Linux user. I get it, this is frustrating. Full stop, I get it.
I will state this. I have personally been involved in testing and re-testing and re-re-testing. This is NOT something that is remaining idle. Rather, it is actively being worked on. But there are elements we need to sort before we release this.
What I am asking for is this. Keep providing us with your user test data if you are comfortable. Each test, each provided data point is extremely helpful in us getting this done.
The fastest track is us getting an overflow of data like you have all done an amazing job with thus far. Invaluable and appreciated as it helps us get to the other end of this.
Thanks to each and every one of you for working through this with us.
Again: using your own open-source tools or the EFI tool that is part of the updater, you can verify yourself, that the new 3.08b EFI updater contains a copy of the retimer01 firmware renamed to the retimer23 file.
It is impossible that this updater as linked here will ever update the right ReTimer. Because its capsule header targets the GUID of the left ReTimer.
To officially acknowledge/confirm that you made a mistake and that the updater will leave the right ports quite unfunctional until fixed by currently unofficial means is not a big ask.
If you cannot simply update the zip file with the correct firmware (just as @Aymeric already showed how to do) you should at least officially document this as a known issue. Or warn that the 3.08b EFI updater only works for boards that are already running 3.06 beta or have the ReTimers both on 310 by other unofficial means.
It is a recurring theme that Framework cannot even manage to update Known Issues to reflect the issues that have been reported to you, even when that includes an update failing without error message and leaving the board in an intermediate state without official instructions on how to recover to a supported state. That really makes it look like you are simply ignoring all feedback.
ive made a new USB stick (just in case) put the latest EFI update files on it.
I copied the retimer23.cap from the 3.06 EFI update (as the retirmer01 matches SHA256 with the 3.08 and 3.08b EFI updates, but their 23 retimers are for tyhe 01) as per Aymeric post on Retimer 23
SHA256 for retimer23.cap: 2f6f59fa03407b7e1a6f3c730f77fb7aeb3738045f123472f05964df9fa6eea7
NOTE I obviously reply to my emediate previous post. I have ran the none B version of EFI already, where the BIOS and PD firmware updated fine. the Intel CSME i updated manually before (using a uefi shell command. I did not knew the retimer file was the cause of the right side retimer not updating. using a fresh copy/install of the 3.08B EFI update files with retirmer23.cap added from 3.06 (or as stated by Stewart_Webb1 from the windows MSI file) now fixed the update media, and updated my system as expected fully.
All versions (bios, csme, pd, retimer) seem to match what this update should do
I also get:
0:16.1.30.2269
0:16.1.30.2269
0:16.0.15.1810
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.
Now that’s insightful.
I’ll go ahead add this info to the github ticket for framework-tools.
The BIOS should show the correct version though.
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:
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:
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:
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:
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
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).