I appreciate the confirmation. My guess is that I received an automatic message that hadnt been updated yet. Time to open up my laptop and get a longer battery life. 
We would like to get feedback on a new updater for 3.08. This updater changes the way we deploy the bios update. So We would consider it be a alpha release at the moment until we get additional feedback from the community.
There are no changes to the bios itself in this release. Just changes to how the update is applied from the EFI shell script.
This change fixes several issues:
- It checks firmware versions before running any portion of the update. And removes tag files that were used to track if each portion of the update was complete or not. This should fix issues that several users were reporting that they would get script errors during the update which we traced to the fat32 partition becoming read only.
- This moves the update out of the wrapper application that was preventing the CSME update to run successfully. We do not know why the h2offt tool was not able to run this step internally when wrapped.
- This update changes the update process from running each update step 1 at a time with a reboot each time, to staging the updates together on the internal NVME drive. This should improve the ability to complete all steps of the update without having to manually reboot into the update drive after each step. Which some users experienced.
https://downloads.frame.work/bios/Framework_Laptop_13_12th_Gen_Intel_Core_3.08b_EFI.zip
Troubleshooting notes:
- If you experience ports not working after your update. Please shutdown, unplug all power sources, wait 90 seconds, and then power on again.
After we get some positive feedback from the community, we will update the top post with this new version.
18 Likes
I gave it a shot just now, super exciting to see progress on the updater.
Unfortunately, since I already used the old 3.08 updater, running this one quits early and just says the updated is already complete.
Checking my CSME version with intelās tool still shows 16.0.15.1810, along with a warning reminding me that this version is vulnerable.
So it seems like the new updater wonāt help users who have already āupdatedā but are missing the CSME update.
5 Likes
That would be because the new script, does not in fact rely on any H2OFFT to execute the ME update, but simply tries to execute the respective command line manually (āFwUpdlcl.efi -F FWUpdate.binā). But whether it does or not is tied to the main BIOS version not being 3.08. So yes, the 3.08b EFI updater was designed to not fix what went wrong with the 3.08a EFI updater.
But on the other hand, the ME updater that is called, is binarily identical to the previous EFI updater. Proving that running the command line some in this thread have already figured out in January is all it takes to make that update and that FW themselves has always considered the ME EFI updater safe to executeā¦
Edit: fascinatingly, the ME updater does its own check for up-to-date firmware and with the used arguments would decline to update if already up-to-dateā¦
2 Likes
I was unable to drop into a shell from the EFI updater to execute the ME updater, but I edited the script like this just now (compare to a version higher than 3.08 so it updates, and then donāt set pendingbios so we avoid re-updating the bios):
set -v pendingbios 0
framework_tool.efi --compare-version 03.09 --device bios
if "%lasterror%" == "1" then
echo "Updating bios"
FwUpdlcl.efi -F FWupdate.bin -Y
#set -v pendingbios 1
endif
And that was successful, my CSME version is up to date now.
2 Likes
If you want a more normal updater, than you should be able to pull the command out of the if entirely. Then the rest should run unaltered. You would just always get the updaters message if up-to-date.
2 Likes
Just finished updating using the windows 11 updater, no issues updating here. My laptop is a batch 1.
1 Like
thats not how public beta testing works but ok
2 Likes
@Kieran_Levin Iād like to report that the EFI update on my FW13 1260p running Fedora 39 went without a hitch. I was using the factory bios prior(3.05) Just some additional pointers to anyone using this method:
- The initial update process is quite fast however there will be 2 or 3 steps of updates after that.
- The waiting time in between each step took almost a minute on my laptop. It may be more on others. At this point the screen will be blank. Do not do anything and let the update complete
- The whole process took slightly over 8 minutes on my FW13.
- On my FW13, I knew it was done when the fedora unlock drive encryption screen came on
Bios readout from Fedora before and after:
I hope this encourages more people to try this method now.
edit - had a curious issue where the HDMI expansion card wasnāt working today when i plugged it in to my usual HDMI cable / monitor. The only difference would have been this bios update. Unplugging and replugging the HDMI expansion card fixed it. Just want to share in case anyone else faces this issue.
1 Like
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.