12th Gen Intel Core BIOS 3.08 Release

Framework Laptop 13
391

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
392

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
393

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.

image
image1920×1440 334 KB

(IF YOU ARE READING THIS DO NOT RUN THIS COMMAND)

1 Like
394

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
395

ok - left, bottom of keyboard usb2 works.
I’ll stop and wait for an updated updater.

396

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
397

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
398

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
399

Don’t think that had the desired effect:

image
image1920×2560 638 KB

(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:

image
image1920×2560 602 KB

From OS:
image
image928×155 27.3 KB

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.

400

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:

20240503_235548
20240503_2355481920×1440 170 KB

(the screen changed too fast to the following green one so I couldn’t capture the bottom correctly)
20240503_235617
20240503_2356171920×1170 316 KB

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:

20240504_001250
20240504_0012501920×2049 302 KB

20240504_001302
20240504_0013021920×1225 315 KB

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:

20240504_024443
20240504_0244431920×1249 228 KB

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
401

Just curious, have you tried non-USB PD power sources, like a 5V2A USB-A to C cable?

402

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:

20240504_153426
20240504_1534261920×1268 148 KB

If it’s useful, I kept the USB drive on the right side.

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.

2 Likes
403

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.

404

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

IMG_20240504_200924
IMG_20240504_2009241920×2560 419 KB

1 Like
405

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.

1 Like
406

I’ve been having the same issue. It shows a few errors and then doesn’t update at all from 03.04.

407

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

408

Update 2:
Since this update, charging has not been behaving well.
Whilst the machine is booted, I get warnings from the OS:

image
image1282×144 39.9 KB

This is via a Dock.
I’ve also tried directly plugging in a power supply, and the port LED lights up - but doesn’t seem to start charging.

Update 3:
Charge accepted from at least Left Top USBC port via official adapter after a “Disconnect Battery” from BIOS.
Pretty sure this won’t get me 100% out-of-the-woods, though.

I’ve opened a ticket with Framework support to see if they can help me get this charge issue resolve and/or help me get this Retimer update applied.

3 Likes
409

I am having a similar issue. Updated and now my HDMI doesn’t work but only on the right side. HDMI still works on the left side. Which is strange because USB-C works just fine on the right side. Just not HDMI.

1 Like
410

What versions did your PD and retimers get updated to? if they did? I eh, only tested my right side for Hdmi. Oddly, the retimer didnt get updated for that side (I dont have anything inserted when I ran the updates).

Maybe a partial update for some reason?