Can partly confirm this. After updating both retimers (01 and 23 i believe?) and bios via LVFS via commandline, the 23 retimer and dbx showed up as updatable again (dbx was not part of the first update though).
Updated via commandline again and now all seems fine.
Updated via Windows. Only got 2 progress bars (why can’t we see a little more details about what is actually being done. The other update variants show more…).
After that it asked for my BIOS (supervisor) password and rebooted into windows. It showed no failure message. The Retimer “23” showed up as not working in Device Manager
and the left ports did not work for USB4/TB connections etc.
I tried shutting down and waiting for 2m as instructed. Did not change anything. But selecting the restart option in Device Manager lead to a further update cycle, where the 3rd progress bar showed up and now everything seems to be working again.
So, my guess: for some reason the updater aborted after updating the first retimer, did not show any type of failure message. But during a 2nd attempt it worked.
Is there a way to confirm that both retimers actually have the expected firmware versions? (Device manager shows 136 for both retimers now). Or a log that shows why it decided to abort or on what?
I ran into a similar situation as @Ray519 where it only seemed to finish two progress bars (it restarted multiple times for each) and once I was back in I had the warning on Retimers 23 and had the Restart Computer option. After restarting and completing another progress bar I still have the below warning and event message on Retimers 23 and they (allegedly) are not started. However I will report TB does appear to be working in the left ports. My Firmware version is reporting 136 for Retimers 01, however for Retimers 23 it shows “CF” as the version.
Blockquote
This device cannot start. (Code 10)
Indicates a revision number encountered or specified is not one known by the service. It may be a more recent revision than the service is aware of.
Blockquote
Device UEFI\RES_{ba2e4e6e-3b0c-4f25-8a59-4c553fc86ea2}\0 had a problem starting.
Driver Name: oem76.inf
Class Guid: {f2e7dd72-6468-4e36-b6f1-6488f42c1b52}
Service:
Lower Filters:
Upper Filters:
Problem: 0x0
Problem Status: 0xC00000E5
I did the 2m+ shutdown without power again and it behaved the same. Luckily everything is functionally working as I would expect, but this is my current experience with the update.
Thanks to Morpheus636 on the FW Discord I had the idea to rebooting the EC via holding the power button for 30seconds. This fixed the issue, prehaps the bios update is failing to restart the EC?
See original post below
@Kieran_Levin I updated to the 3.06 BIOS from 3.05 via Windows 11 Enterprise. After updating to 3.06 successfully (Lets call this initial reboot) I went and updated my drivers (Intel Wifi and Bluetooth). At this point the HDMI was still working, however I restarted due to the wifi and bluetooth updates. After this the HDMI no longer worked. It recognises that a 2nd display is plugged in however it will never keep the setting of “Second screen only” or “duplicate display”
Ive powered off the machine, with it unplugged from AC and waited 5mins. I then tried it in both sides to no avail.
Retimers do not show any errors at the surface level:
I used the windows installer; it did two of the steps and then the computer shut off and didn’t reboot on the third update. I forced it to boot and it booted fine, but said that the two updates didn’t succeed and it needed another reboot.
This device cannot work properly until you restart your computer. (Code 14)
Firmware update was unsuccessful.
That was on both the bios and the retimers 23.
EDIT: It now tries to install every time I reboot… looks like it was a failure. Let me know if there are logs or such that I can provide to aid in investigating the failure cause & resolution.
Hi,
Update was successful with LVFS instructions on Arch Linux. Everything is working as intended. Will report if I notice any issues.
Only thing of note is, I checked for updates again after logging in, as reported by @Fraoch I too was prompted to “Update UEFI Device Firmware from 207 to 310”
I did that, rebooted, system went through it’s boot cycle and I was back to login screen a minute later. Checked for updates again just to be sure, nothing else was updated this time.
This was very fast and good firmware update experience. Well done.
Thank you for the fixes, Happy Christmas to y’all.
I tried to update multiple times using LVFS and also USB flash drive method. Retimer update always failed, left ports stayed disfunctional and fwupdmgr continued to offer retimer update.
Fix/workaround: I removed the NVME drive and did the update again using USB flash drive method - this time it worked first try and left usb ports started to work again.
I think that maybe retimer update somehow tries to read partition table of the internal SSD which fails because the drive is not unlocked (OPAL PBA / pre boot authorization).
But if that assumption is correct, I think this should be considered a bug. Don’t think the firmware update process should be influenced by the configuration of the nvme drive.
After attempting fwupdmgr I bit the bullet and did the USB method as the retimer didn’t update. I got up to 100% charge during the update, maybe the uefi version of fwupd has the same bug where you need to be plugged in and charging… who knows.
Anyhow, I was able to get my system down to < 5 W and < 100J draw reported by powertop before, now I’m seeing around double that. Maybe it idle’s down to 8.x W / 160J draw sometimes. This is on a 64Gig / 4TB / i1280P host with every power setting I can find, including esif_ufd and a custom minimized kernel. I’m going to boot Windows up and try resetting whatever else I can. If there’s any suggestions I’m all ear’s. I really like’d the nearly 10hours battery life I was able to get when fully tuned, perhaps barely 4.5 now.
It seems the thunderbolt NHI devices are now in the mix from what powertop indicate’s for devices drawing power, even when not plugged into anything.
Just here to confirm what @Ktwo mentioned: 3.05 indeed seems to be nicer on battery.
From what I can see in powertop (linux, kernel 6.0.9) this is mostly due to the processor almost never reaching C10 state anymore. (On 3.05 I managed to get the system down to about 3,5-4,5 W, now it is 6,5W)
On 3.05 I saw the CPU staying in C10 for about 80-95% of the time when the machine was sitting Idle with just powertop open (in a terminal window on an Ubuntu Gnome desktop and de-selecting the window to stop the cursor from blinking). On 3.06 it only shows C10 for about 3-8% of the time, instead the CPU now spends the majority of its time in C2.
The HDMI card does seem to play nicer; on 3.05 it added about 1W of power draw as soon as I inserted it, now it seems to add a lot less, but how much is harder to tell due to the higher draw of the CPU.
@Ktwo@Hans_van_Schoot very interesting, I am actually seeing an improvement. Using Fedora 37 Gnome, 64GB RAM, SK Hynix P41 2TB Nvme, I was previously lucky to get down to 5.3w or so, it was usually sitting at 5.8w. Now with the new BIOS I am getting down to 3.53w after 1 minute using only Powertop, with Firefox, Evolution, and Powertop running it settles down to 4.54w - 4.83w. I am definitely hitting C10. I use tlp for power optimizatrion, and thermald with dptfxtract for thermal optimization. My tlp conf is fairly straight forward as regards battery power, turboboost is off no other tweaks. I generally run with bluetooth off as well, with wifi on. This is the state for the above power draws. Overall I am seeing it reach C10 quicker as well, and this looks like a 0.8w on average improvement for me. I should also add I am using all usb-c expansion cards.
Happy to report that I am on 3.06 with Ubuntu. I used LVFS and what Kieren said here about making sure the drive is properly unmounted seemed to factor in.
It wasn’t and I lost the ability to charge the battery until the battery died and the system reset. After that I was able to update, and, yes, it took a lot of reboots.
All good though and I am grateful to Framework for taking care of the folks not running Windows as well as the Windows folks.
@nadb interesting, and good to know that the bios update should not be to blame here then. Are you running kernel 6.0.7 ? (checked what Fedora 37 should be using on distrowatch). My 6.0.9 is from the ubuntu mainline reo, but I’m seeing the same behaviour on the 5.17.X OEM kernel in Ubuntu.
My Framework is rocking a 1260P, with 2x16GB RAM and a 1TB Samsung PM9A1 SSD. Currently running with only 2x USB-C, although adding the USB-A and HDMI does not seem to add much with the new bios. My TLP config is almost fully default, and I’m also using thermald, but did not have dptfxtract installed.
Whoop whoop! thank you for the hint! after installing dpftxtract, I’m back in C10 for about 55-75% of the time, and C8 for another 10-25%. This drops power usage back to 3-4 W
Adding the USB-A card back into the laptop adds about 0,25-0,35 W draw from the battery, the HDMI card adds about 0,15 W (sampling times of about 1 or 2 minutes, so not high precision data!)
@Hans_van_Schoot I am actually on kernel 6.0.15 right now. My machine is also an i7-1260p. Happy to see that your power usage has dropped into comparable ranges. I am actually excited to do an extended battery usage test this weekend to see what my new average is. Previously I was getting 8.5-10 hours with my usual browser, mail client, music player, and terminal (or multiple terminals) workload. My guess is I will see something closer to the upper end of that range now.
fwupdmgr seems to have successfully updated the BIOS. But the update for Retimer23 does not seems to fail. Running fwupdmgr update does the reboot, boots into framework firmware updater for a second (shows the Framework logo and fwupdmgr efi version at the top left) but the laptop immediately shuts down afterwards.
fwupdmgr get-history currently shows this in the corresponding firmware update stanza: