Thank you for progress on this stuff. I’m not a good test as I had already upgraded including manually upgrading the CSME, but I did try it. It ran just fine and was very clear that the bios was up to date and I liked the clear instructions to just power off and remove the thumb drive. I didn’t see anything in the output about the CSME version though…
1 Like
I try to update form 3.04 to 3.08b with the new EFI shell script.
At the end was a green screen (see picture) with the txt
COMPLETE your Bios is up to date.
UEFI BIOS
Version 3.04
Looks to me like something went wrong. It should say 3.08 there or?
3 Likes
Just checking if you used the latest version from this post:
I can share a video of my update progress if this helps. You should have 2 other update screens after the first update before the whole process is complete
1 Like
Only the new updater has that green-background result screen.
The script just runs top to bottom. First it checks if things are out of date. If anything is out-of-date it executes the separate updater executables that may include a reboot (not sure if the Capsule Updates of ReTimers & Main BIOS will automatically reboot). And the script falls through to that success screen.
Presumably, the updater should attempt a reboot and install the updates just like when doing this from Windows. Because otherwise it makes no sense that the script would always end in a success screen.
If the device does not reboot before showing the success screen, then presumably, the Capsule Update process failed somehow. As Kieran mentioned it is supposed to stage the update on the NVMe disk using hardcoded partition “fs0”. So my guess would be, that is where things are going wrong. And since the script does not check for error codes from that part of the update process it simply goes on to the success screen.
Fair enough, I don’t remember seeing a green screen but i guess i could be wrong
Thanks,
Successfully updated from 3.06 Beta to 3.08b today using the new EFI method.
I used to have issues with the 3.06 Beta Update, probably caused by my NVME drive being self encrypted using SED/OPAL PBA (see 12th Gen Intel Core BIOS 3.06 Beta - #22 by janekt)
The new method worked fine with my setup. Had to unlock the encrypted drive on every reboot of the updater, but the updated continued without issues.
UPDATE 1: looks like after the update, the right PD controller’s version is different from the version of the left controller. The script also didn’t asked me to change port of power cable/usb stick.
Is this to be expected?
UPDATE 2: After poweroff for 90 seconds + reboot into EFI updater, the “Backup App” for the right PD controller was suddenly on “0.1.44”. “Main App” stayed on 0.1.33.
Even after several reboots, 90sec without power, restart of EFI updater etc:
I then manually called the PD updater for the Right controller in EFI Shell, which successfully updated the Right PD controller to 0.1.44 (while having PD power on top-left, usb drive on bottom-left port):
To me it looks like something went wrong during PD Controller update in the startup script and the startup script doesn’t retry updating the PD controller firmware.
1 Like
Mine went the same as NF117
First attempt i didn’t capture the error, but it performed some sort up update that took a minute or so, then reported the same error as the second attempt. It did not reboot during this whole process.
First attempt green screen:
Second attempt work screen and error:
I’ve got separate /boot and /boot/efi partitions if that makes the difference:
stewart@muh04 ~ % lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
nvme0n1 259:0 0 931.5G 0 disk
├─nvme0n1p1 259:1 0 244M 0 part /boot/efi
├─nvme0n1p2 259:2 0 488M 0 part /boot
└─nvme0n1p3 259:3 0 930.8G 0 part
└─luks_root 254:0 0 930.8G 0 crypt /
1 Like
Correct. The script only checks the PD firmware when the board is in standalone mode. When not in standalone mode, like with the Windows updater, the PD firmware is part of the BIOS capsule and should be updated after the reboot, together with the BIOS.
And the EFI updater only checks for the main BIOS version to confirm to not try that again.
So technically, the Capsule update of the BIOS failed. And it does not retry to complete the update. And it does not signal that it was partially installed. Question is, if this could happen with the Windows updater as well, as the Capsule itself is identical.
Though I have no idea if the way the Capsule update is started with the EFI installer is similar to what Windows does.
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.
2 Likes
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.
4 Likes
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.
(IF YOU ARE READING THIS DO NOT RUN THIS COMMAND)
1 Like
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…
1 Like
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^^
3 Likes
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.
1 Like
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.
1 Like
Don’t think that had the desired effect:
(this is from a run with config FS0 after i’ve run the suggested CapsuleApp.efi)
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:
From OS:
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.