I found another tiny issue: in the version table you published, you show the PD controller version using hex-format. The BIOS shows it this way as well. But the new EFI updater / framework_tool lists it with decimal numbers, making it more complicated for people to understand that 0.1.2C and 0.1.44 are the same. Was that not already a problem for 11th gen with the big version jump from 3.09 to 3.16?
Maybe numbers should only be hexadecimal, when they are actually shown prefixed with 0x.
If you abort the startup.nsh you can look at the various filesystems āfs0:ā and up. And ālsā the root contents.
Funnily enough the script itself searches for the filesystem of the USB stick itself by looking for the one with the startup.nsh file in it. But it hardcodes āfs0ā to use for the capsule update.
I am not sure what the EFI shell uses to order the filesystems, i.e. how likely it is that the EFI system partition of the single installed NVMe should always be fs0.
Edit: better yet āmapā lists all filesystems and their sources.
Edit2: for me, fs0 is the first partition on the USB stick that the installer is on. the partition of the updater is fs2 and only then follows fs3, the EFI system partition of my NVMe.
So hardcoding fs0 seems not at all reliable to find the internal EFI system partition. It seems more likely to find the stick you booted from, which would not match Kierans description of what the updater should do. And it also seems like another big oversight with those updates, given that the previous EFI updater hat loops in multiple places looking for the filesystem of the updater, just like in the first few lines of the current updater.
Edit3:
uhh, fascinating. A USB3 stick will be recognized as fs1 to the internal EFI System Partition being fs0 (as long as your internal disk does not have other FAT volumes on it, that EFI will recognize as filesystems).
So seems to be linux like, following an internal order of the PCIe topology / different controllers. And USB2 controller is before the internal NVMe port. And the USB3 controller of the CPU after.
@Stewart_Webb1 I did not even look at your photo showing the mapping table. FS1 would be the correct volume for you. If you wanted to edit the startup.nsh file if you use that it should work as expected. As long as you connect the USB drive via the same way so it does not change up orders on you again.
Hi Ray,
I modified the script, swapping FS0 for FS1 and it ran.
Mid way through the second reboot installation bar, the laptop shut down. When powered back on it booted to the OS.
When I retried, it reboots before finishing the progress bar, and the OS boots.
Iāve reverted the script so i get the no bootable volume on FS0 error again, so i can see the green screen, looks to me itās only installed the update for the Left Retimer, which has a value of 0x146 (310) - where previously it had 0xCF (207)
Edit1: it appears my USBC dock is no longer functioning with the laptop for whatever reason, Iāll power the laptop off for a short while to see if that makes any difference.
Your left ReTimer was updated. But nothing else. The ports wont work as long as the versions are out of sync.
Looks like you might have hit the same bug as I reported for the Windows installer. Just in a different order.
(where the 2nd ReTimer does not update until you unpower the device for a while and retry. With Windows updates the order seems to be BIOS, retimer01 [right], retimer23 [left] with left failing).
Now that the EFI updater is also using the Capsule updates and using all 3 together, maybe it is just as affected by that issue as the Windows installer, where that problem is not solved, in contrast to FW listing this as fix 6 of the 3.08 update. But that would require an official response to any of it.
I decompressed these contents onto an empty FAT32 USB thumb drive, rebooted, started the EFI shell, and everything seemed to work. It said that it was updating my FW and it rebooted twice with green progress bars.
But now that I have booted back into Ubuntu it still shows 3.05.
$ sudo dmidecode
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 3.3 present.
55 structures occupying 4030 bytes.
Table at 0x3F085000.
Handle 0x0000, DMI type 0, 26 bytes
BIOS Information
Vendor: INSYDE Corp.
Version: 03.05
Release Date: 08/23/2022
Address: 0xE0000
Runtime Size: 128 kB
ROM Size: 16 MB
Characteristics:
PCI is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
8042 keyboard services are supported (int 9h)
CGA/mono video services are supported (int 10h)
ACPI is supported
USB legacy is supported
BIOS boot specification is supported
Targeted content distribution is supported
UEFI is supported
BIOS Revision: 3.5
Of note I have the model with the i5-1240P.
I might well have messed myself up - I tried using something similar to the windows userās manual updating of left ReTimer
but using CyPDADlt1.efi -P pd23.rom
and now none of my usb ports work at allā¦ so i canāt even boot into the update shell.
CyPDAdl is the PD controller updater. It is not used for the ReTimers at all.
Also, USB2 on the left side might still work, because that does not go through the ReTimer.
But you also might want to cut your losses and not experiment furtherā¦
Edit2: you used the left side PD controller firmware on the right side. And updating the PD controllers is only done by that new EFI update when the board is in standalone mode. Under normal operation, just like with the Windows update, this is part of the main BIOS update.
I have no idea how using the wrong PD controller firmware might screw things up. Since there are separate firmwares this might include unique / addressing info, so that now both PD controllers talk over each other etcā¦
ok - left, bottom of keyboard usb2 works.
Iāll stop and wait for an updated updater.
If it runs, you might want to try to run
āCyPDADLt1.efi -P pd01.romā. The normal command from the script to update the left right PD controller back to a firmware designed for the left right controller. Either that or contact support ASAP, trying to change as little as possible to not make things worse.
While this is no rollback to the previous state, because we do not have the original PD firmware as a file available, it should still work, because the updater does update the PD controllers independent and before the main bios (and the old EFI updater even did it all unconditionally).
Edit: switched left and right. directions are hard^^
Thanks for correcting my idiocy Ray.
Iāve run the suggested command, and now all usb ports are back working.
Iāll hold fire on anything further until thereās an update on this retimer updater with CapsuleApp.efi
Edit1: USBC dock is even back working on the right sideā¦ so i guess i lucked out.
Glad it worked.
In case you wanted to complete your update (ReTimer downgrade was said to be impossible by FW. So only one way forward),
you would run
āCapsuleApp.efi winux.bin retimer01.cap firmwarehdr.cap -OD FS1ā
This is the line your previous attempt aborted on. I removed the first retimer23.cap, as that is the one that went through already. And already included the change to FS1 as you previously needed.
This would be expected to basically continue where you left off. And if both go through you should actually be up-to-date.
Powersupply ideally on the right. Because that has the already updated PD controller.
Donāt think that had the desired effect:
Pretty sure the PD Controllers, Right (01) version is from my previous cockup.
Update 1:
So, after this. I had the idea to try the standard install script (using FS1) with the power supplied from the Top Left USBC.
And it did something different. Laptop seems functional, but it seems to have updated all but the Right Retimer now:
I also tried a (slightly wacky attempt) at providing power to both top left and right usbc ports - but the outcome is the same as this screenshot
Is there a way we can get CapsuleApp.efi running in a non-graphical mode? so itāll show us more the just a generic updating progress bar.
Itād be nice to know what firmware file is being applied by each updateā¦ or even better if it can log to screen as it goes, then we might be able to describe at which point itās failing.
Iāve put the contents of the Framework_Laptop_13_12th_Gen_Intel_Core_3.08b_EFI.zip file in a FAT32 drive, booted on it (lower right USB port), and let the thing run:
However dmidecode still tells me Iām on 03.05 (i7-1280P board).
So I tried again and got the following, this time capturing the bottom:
I was plugged on the upper right, and the power indicator became violet instead of orange.
Plugging on the upper left didnāt charge.
After unplugging for 90 seconds as advised in case of āport not workingā, none of the upper ports charge anymore.
This update doesnāt seem at all ready for release and I now have a semi-bricked device that doesnāt charge by just following instructions and without having run any custom command.
EDIT:
I tried changing the EFI Boot Order to have the EFI USB on second position and booting on it using F12, hoping it would get registered as FS1 instead of FS0, but it didnāt change anything.
EDIT 2:
Putting the USB drive on the lower left port didnāt change anything either.
EDIT 3:
Changing FS0 to FS1 in the Startup.nsh script DID give me two āPlease wait while we install a system updateā screens, and then everything shut down (in an unannounced fashion).
Normal users shouldnāt be expected to do this.
EDIT 4:
I restarted, got another āsystem updateā screen and another shutdown.
Charging still doesnāt work at this stage even after unplugging for 90s.
EDIT 5:
Putting back FS0 allowed me to see different versions of the Retimers in the green screen, exactly as Stewart_Webb1 experienced above.
EDIT 6:
These commands in the EFI shell did not update the āRetimer 23ā that needed to be updated according to the last green screens.
FS0:
CapsuleApp.efi winux.bin retimer23.cap -OD FS1
EDIT 7:
I tried that one with the USB key on the right side:
FS0:
CyPDADLt1.efi -P23 pd23.rom
No change either.
EDIT 8:
Also doing this gave me on the green screen the new 0.1.44 version for both PD Controllers.
FS0:
CyPDADLt1.efi -P pd01.rom
It looks like the left part was the one needing an update, which is the opposite to what the updater said.
Itās progress I guess, but retimers are still off and I still canāt charge, and my experiments slowly drain the now unchargeable battery.
EDIT 9:
Just to make sure I did everything:
FS0:
CapsuleApp.efi winux.bin retimer01.cap -OD FS1
This one had the green indicator moving for a while (unlike the retimer23 one that crashed at the beginning).
Still no charging, and still different versions on the green screen.
So I did the last one:
FS0:
CapsuleApp.efi winux.bin firmwarehdr.cap -OD FS1
Got the āPlease wait while we installā¦ā and the shutdown.
Still no charging, and still different versions on the green screen.
At this point I seem to have tried independently every command of the script.
EDIT 10:
I booted up a Hiren Boot CD on a Ventoy USB drive to try the Windows .msi from itā¦ but guess whatā¦ it refuses to run because āPlease plug your system into a power source and run the installer againā.
Yeah thanks, but the issue is that no pluggable power source is recognized now.
Current status:
EDIT 11:
Retrying the BIOS part didnāt change anything, itās still stuck at 03.05:
FS0:
FwUpdlcl.efi -F FWupdate.bin -Y -allowsv
Just curious, have you tried non-USB PD power sources, like a 5V2A USB-A to C cable?
I let it unplugged overnight and charging ācame backā the day after, on both top ports.
I was still in 03.05 and with different retimers versions though (as the last screenshot of my last post).
So I rechanged the script to have both āFwUpdlcl.efi -F FWupdate.bin -Y -allowsvā (the last option to redo the BIOS part) and FS1 as drive for the CapsuleApp.efi calls, let it run/restart twice (maybe once was enough, but I wasnāt quick enough to stop it on time), and now I have this:
So I guess if the drive letter isnāt set properly from the start in the script, everything gets screwed up in some way.
Iāll redo the process again with the drive and power on the left side, hoping for the right-side retimer to get updated this time, and edit this post with the results.
EDIT:
It didnāt change anything, the right side is still 0xCF/207.
I am pretty sure, that the FS1/FS0 should not affect how that update runs. It just tells the executable where to place its files that are loaded on next reboot.
Maybe that process has a problem with a plugged in USB stick or something, but simply choosing FS1 makes no sense to be the cause for broken updates, outside of other bugs.
I hoped, completely unpowering the device would solve your problems, as I had it once before that my FW would not charge at all (completely separate from any update of it). And my default procedure of selecting battery disconnect in BIOS and powering back up with an external power supply solved it, as it did all my ReTimer update hangs (essentially a stronger version of the let it sit disconnected for 90sec, that guarantees power is cut, as can be checked by the device not powering back up on power button presses until a power supply is connected again).
But since I do not know how exactly the device would wake itself back up from a power supply, I was not sure of the risk that it would not turn on again, so I did not want to recommend that. Especially after you went nuts and tried to update anything and everything without solving the failure first.
āCapsuleApp.efi winux.bin retimer01.cap -OD FSxā would be the command to only launch the right ReTimers capsule update, much like Windows would do it, whenever it was still outstanding. And if that update silently fails, try going through a battery disconnect and then retry. The last time you posted about trying that, you were still affected by charging not working on any port, which sounds like another failure / hang independent of mismatched firmwares, which could also affect the ReTimer update.
Edit:
according to your earlier posts, the ME firmware was already updated. And the only thing that -allowsv does is force it to reinstall the same firmware once again. It should not be needed. The updater should simply refuse with that red line shown by others, that the ME firmware is already up-to-date. And then the regular script would even continue on, like nothing happend, because it does not check for success/failure of the ME udpate.
Well, intried all kinds of things, apparently my earlier updating dint went well and im basicly at the same situ, bios, pd, ans me is updated even the 01 retimer, but 23 dint get updated. I had a support ticket that suggested trying this latest efi update, ill reply intel me got updated, somehow. But the retimer is still nogo
Edit, added a image from the updater, it thinks its complete, but the version check makes it clear it is not. (Ive commented out any flashing commands. Even if i let the retimer update go, it will not update. Manually typing that retimer update also gets a bit stuck at the end and then reboots
I tried again to launch the .msi in HBCD PE (now that the power input is recognized again), but got this message:
āThere is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor.ā
So I guess Linux users canāt go this route either.
Back in the EFI shell, āCapsuleApp.efi winux.bin retimer01.cap -OD FS1ā (with everything plugged on the left side) still led to ā0xCF/207ā on the right side after a reboot.
Trying with FS0 (the USB drive) still gives off the āāFS0ā is not a EFI System Partitionā error, so the requirement to use the capsule is not only that the FS is writeable but that itās also a EFI System Partition.
Iāve been having the same issue. It shows a few errors and then doesnāt update at all from 03.04.
During my update I could see the FS0 EFI error:
FS0 is not a EFI System Partition
There is also a bug in version 3.04 that causes the laptop to hang when pressing F12.
Quiet Boot=true and Quick Boot=true in BIOS helps see:
Do you also change your boot order manually? Maybe there is error if NVME is not selected first
