I’m confused by this statement (or is it a typo?):
We need to be on 3.05 to update to 3.05?!?
Or is that only referring to the retimer update? If that’s the case, the sentence should probably be moved to that section.
UPDATE: Used EFI Shell method to upgrade from 3.04 to 3.05, and retimer update applied as well. All seems in order. Thanks for publishing the EFI Shell method promptly!
Are the Windows BIOS / retimer files safe to install with Bitlocker on?
YES! That is the exact monitor that I have. Today, I plugged into my TB USB dock at work like always. The monitor plugged into the dock would not come on. The keyboard and mouse worked. So I turned my computer around backwards and plugged into the other side and the monitor worked! Some time later, I undocked for a meeting. When I came back, I plugged it in as usual and the monitor worked.
Tonight I had the exact same issue on my dock at home (same Dell TB dock as at work).
My normal USB-C for dock and monitor is back left (opposite of the power button). However, it seems that using the rear USB-C on the same side as the power button seems to work. And after it works, the normal rear USB-C dock works.
I’ve had the FW 13 for nearly a year now and used this same setup every day without any hiccups. The only thing that has changed is the new BIOS and driver bundle. I have not tried installing the Intel drivers again, but may try that soon.
Should I uninstall all Intel drivers and reinstall from the Intel support site?
Thanks!
@Harold_Pearson I tried to reproduce your issue, and i can reproduce this issue on the upper left port. But not on the lower left port. I can reproduce this issue if the display is connected before the system is powered on. While we investigate this, I would suggest you try connecting your display to a different port.
I have a 1360p FW13. W11Pro 23H2 with all patches applied before beginning this process.
I first applied the driver updates.
After restart I ran the BIOS 3.05 .exe from W11Pro. I experienced an error message that quickly flashed off the screen and before I could grab a photo. Honestly, I cannot remember if that error occured at the very end of the windows portion of the upgrade or at the end of the upgrade that happens outside windows. However, the error disappeared quickly and the laptop continues the upgrade. I checked for the correct BIOS version and firmware upgrades post upgrade and all looks good.
Upon first boot after the BIOS upgrade, Windows wiped out my fingerprints and also required I login to my Microsoft account to reset my PIN. Any ideas on why the credentials were lost? My W11Pro installation uses bitlocker and that did recover OK and resumed after the BIOS upgrade. So, clearly the TPM was not wiped out, but selectively my PIN and fingerprints were gone and had to be setup again.
After the BIOS upgrade, I did the Port 1 then the Port 23 retimer upgrade. No issues with either of those upgrades.
It’s only been a few hours, but all seems OK otherwise.
I would like to suggest FW offer a driver package where either the user can choose which drivers to upgrade or if the package detects newer drivers, such as Intel graphics, wifi, BT, etc. not to overwrite any newer driver with older versions.
Hi Kieran, Thank you for following up! I was going to post tonight with the same fix. I moved my USB-C to the front location and it is working 100% of the time for the past 3 days at work. This is a good long-term solution for my use case. Best, Harold
I thought I was crazy, it completely wiped it, and the password I had as a backup wasn’t working.
Had to dual boot to wipe the OS password. Even after that the pin/windows hello was wonky for a bit.
Luckily I didn’t have bitlocker enabled
After I installed this bios and driver bundle, I had my screen freak out. Initially it did this “double vision” type thing and made it unreadable. I connected my external monitor and then removed it and it reset for an hour or so. But then it just freaked out entirely and went to full screen flashing. I was able to restart using my external display. I went ahead and installed the latest Display driver from Intel’s site and it seems fine now.
Did you have a newer display drivers installed on your laptop than the one in the driver bundle? It frustrates me that FW simply overwrites newer drivers with their driver bundle. At the very least they should detect newer drivers and display a message asking us if we want to overwrite a newer driver with their older driver in the package.
I have bitlocker enabled, but the BIOS update detected that and let me know it would pause bitlocker before upgrading. I had no issues with bitlocker resuming after the BIOS upgrade (thankfully), but this wiping of other credentials is worrisome. If it’s normal behavior I suggest @Kieran_Levin add it to the release notes.
I believe nothing is supposed to be wiped normally. Bitlocker needs to be disabled, because on default config it measures the BIOS code itself, which will change due to a BIOS update, so that stored data would be invalid after. Bitlocker reenabling simply uses the newest measurement to recreate the secrets stored in the TPM.
But I do not think that the Windows PIN is normally dependent on this like Bitlocker is, as no PC of mine so far has ever lost that during an update, only when I manually reset the TPM. So I am guessing either the PC was running a different config than normal, or the TPM storage was wiped in its entirety. I do not know if fingerprints themselves somehow involve the TPM as the specific sensor should match on chip. Though TPM might be involved in Windows Hello in general, which Fingerprints and the PIN are part of.
Hi there!
I have just received a mail that we have our first BIOS update for the 13th gen!
We got installed from factory 3.04, and we’re going for 3.05.
If we follow the instructions from the knowledgebase at the Linux/Other/UEFI Shell update section we can follow the instructions to install it… even it states:
You must be running 3.05 or later to apply this update using EFI.
Which to me seems like either a mistake on the version we must be running (as our first bios update is being this one, so we’re all behind!) or that there is a lack of an alternative steps to follow for this first update (which maybe is in another gen but not in this one).
Would be nice if somebody from the framework team can clarify this here and also complete the guide for further users!
I would tend to agree with you that no credentials should be wiped. But it also seems from this thread that I’m not the only one who experienced this anomaly.
If my TPM was wiped as part of the BIOS upgrade, bitlocker would not have been able to resume. But it did so that seems to rule out the upgrade wiped the TPM.
The only things I can think of that are possibly “non standard” in my configuration are:
I have a BIOS password setup
A couple of Microsoft accounts on my PC are AD managed. Not the login user account, but two accounts for Microsoft Office applications.
Are we anticipating that this update will be distributed for Linux via fwupd? If so, is there an ETA?
Yes it would. If Bitlocker is paused, the encryption key is written to the partition in question. Any system could decrypt that drive. When Windows attempts to resume Bitlocker it overwrites anything pertaining to that Bitlocker partition in the TPM. Resume should even work if you explicitly clear the TPM or switch out the entire PC while paused (though Windows might not auto-resume if it has never seen the drive before).
No. I spoke about this in the 12th gen thread in more detail. But fwupd only ships capsule updates, no executables. And the ME firmware as Framework is delivering it is not that. And it seems the BIOS cannot currently handle ME updates from capsules. So Framework would need to be willing to split the update into 2 parts: everything but ME could be shipped easily through fwupd (we might be able to do this ourselves if you do not need it signed to upload through lvfs). And for ME you would need to manually download the ME firmware and the installer and run that (or reuse the EFI/standalone updater for that alone). The other updates that were provided via fwupd did not include any ME update, so the splitting was not needed back then.
FW seems to not be interested in doing this split and has never spoken about if ME capsule updates would be sth. that could be added with further BIOS updates or for future devices.
I observed this issue with my Anker USB PowerExpand 9 USB-C with power delivery dock. After installing the BIOS and retimer updates, the display did not work until I connected it once to the port closest to the power button.
Linux kernel 6.6.36
I can’t be 100% sure, but I do usually check the “optional updates” section in Windows Update and install everything there, so quite likely, yes. My machine has been running fine, I was just hoping something in the firmware/drivers might help with battery life. Hashtag-waiting-for-ARM 
It looks like another user successfully tested the UEFI process with Linux running 3.04, but I agree, it would be helpful if Framework can clarify the circular reference.
Hi Kieran.
I am running into a similar issue as @Harold_Pearson on my side after updating to 3.05 incl. retimers updates.
I have a USB-C monitor (LG Gram View+) connected through a Caldigit TS4 dock which worked fine using the upper left port through a USB-C expansion card.
After the update the upper left port stopped working for the TS4 dock completely while the bottom left one just works sporadically.
The ports on the right side seem to work fine.
Is there a way to downgrade back to 3.03 or 3.04 for this?