12th Gen Intel Core BIOS 3.08 Release

[Stewart_Webb1]

Update 2:
Since this update, charging has not been behaving well.
Whilst the machine is booted, I get warnings from the OS:

This is via a Dock.
I’ve also tried directly plugging in a power supply, and the port LED lights up - but doesn’t seem to start charging.

Update 3:
Charge accepted from at least Left Top USBC port via official adapter after a “Disconnect Battery” from BIOS.
Pretty sure this won’t get me 100% out-of-the-woods, though.

I’ve opened a ticket with Framework support to see if they can help me get this charge issue resolve and/or help me get this Retimer update applied.

[Carlos_Felipe_Diaz_R]

I am having a similar issue. Updated and now my HDMI doesn’t work but only on the right side. HDMI still works on the left side. Which is strange because USB-C works just fine on the right side. Just not HDMI.

[CodeAsm]

What versions did your PD and retimers get updated to? if they did? I eh, only tested my right side for Hdmi. Oddly, the retimer didnt get updated for that side (I dont have anything inserted when I ran the updates).

Maybe a partial update for some reason?

[Carlos_Felipe_Diaz_R]

You know what…? Maybe its because the OS I was using to do the update was running off an expansion card on the right side.

[CodeAsm]

You may try it again, but now boot from the other side? I think the updater was smart enough to skip whats updated already

[Dafisch]

How can the update actually be performed when my main partition is LUKS encrypted ?

[Ray519]

It does not use the main partition. It wants to use the EFI Partition. Which cannot be encrypted, because that is how your system boots in the first place.

It may only get complicated with TCG Pyrite / Opal setups where that partition might be read only etc.

[Alexander_Keusch]

I tested the update with following setup:

• FW 13 1260P
• Current BIOS version: 03.05
• Fedora 40
• LUKS encrypted

The update failed with following result:

• after the upgrade progress reached 100% I got a “FW updated completed successfully and a reboot will run the new FW” message
• then I got the “‘FS0’ is not a EFI System Partition” message
• the green screen still shows version 03.05
• checking the BIOS after the upgrade process also still shows version 03.05

[Aymeric]

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.

[Ray519]

@Aymeric

Also, I had to force a flash of the BIOS by adding -allowsv flags.

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.

[pierce]

@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.

[Ray519]

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.

@pierce

these mistakes were really silly

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.

@pierce

is that the technical people inside framework don’t read these threads, they are only skimmed by forum/community managers

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.

@pierce

also the windows installer posted for the first few day

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.

@pierce

just let it go sometimes

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.

[Stewart_Webb1]

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

[CodeAsm]

Auch, thats a painfull mistake by FW. hope they notice. My guess is this update would have worked fine then for me way earlier.

[p_e]

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

[Simon84]

@pierce

and just let it go sometimes

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.

[Matt_Hartley]

@Simon84

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.

[Ray519]

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.

Edit

And here for the lazy: both GUIDs. As also used with the Windows updater, the depublished EFI updater and the 3.06 beta updaters.

[pixelforest]

@pierce

that the technical people inside framework don’t read these threads

Hey @pierce and everyone - I hear you all, and want to re-assure you that the technical folks (myself, Kieran and Nirav) read all of the feedback on these threads (in addition to our community team) and are working on solutions the fastest we can for you all. We collect the feedback, internally triage/review/try to reproduce and then work with the corresponding internal and external partners.

Some insight as well to the the Alpha release, is we did internal testing, although on a handful of units prior to the release here that Kieran posted.

It looked good there and we wanted to get it out for you all for more feedback (thank you again!).

Something I have been working on is how we can get more robust test coverage (# of tests and tested on a wider range of setups for compatibility) prior to Beta releases, as it stands now, Framework’s QA team is also Kieran, Matt and I doing double duty as our QA team.

We know this has been frustrating, and do apologize, any further updates on the next version we will share here as soon as we know.

[CodeAsm]

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

• FAILURE SKU# and SYS SERIAL NUMBER: FRANDACPA4234… (is this really necessary to be public? if so, ill edit, prefer to pm)
• SYS CONFIG: 12th Gen Intel(R) Core™ i5-1240P
• RAM: Crucial 32GB x 1
• SSD: WD, SN850 2TB
• Wi-Fi: AX210NGW
• External Devices/Other: 1 Philips 16GB usb 3.0 stick FAT32 with only updater files
• EXPANSION CARD TYPES: 2x USB-C, 2x USB-A (Right lower was fitted with Philips update stick. Right upper was usb-c and was powered by official PSU)
• BIOS VERSION: 3.08*
• DRIVER PACKAGE VERSION: none, using Linux
  (dual boot windows sometimes
• OS VERSION: Arch Linux, last update 15 May 2024 (very recent), Windows 11 Pro , 22H2 22621.2861 (was last? I havent ran windows in a while)
• FAIL RATIO: 0%*
• STEP TO REPRODUCE:
  inserted usb stick on the right side, rebooted the system and made it boot the usb
• OBSERVED RESULT: fully updated the retimer (also tried and maybe did update again the bios?
  * EXPECTED RESULT: Not updating things that are already up to date
• ISSUE RECOVERY METHOD: moved an older file from 3.06 onto the filesystem of the 3.08 filesystem
• EXTERNAL DEVICE MODE or NAME:
  Philips 16GB USB 3.0 stick

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