Is there any work being done so that the firmware update can one day be done through LVFS ?
I have been waiting for it since I want to get my hands on the newer battery because I don’t want to meddle with a potentially messy beta update procedure but if that’s never going to happen, I’d like to know.
1 Like
Btw. Everything, except ME firmware could / is already updated through LVFS.
Framework could make 3.08 available via LVFS. And the only thing missing would be that you need to manually run an executable for the ME firmware update (maybe even the one used on the EFI installer that we already have). They could do that immediately if they wanted.
The Windows updater essentially already does this, it can just automate both of those steps together, while LVFS does not allow this (shipping the update through Windows update like most vendors do might also not be available for the same reasons as for LVFS).
And the ME problem seems solved for 13th gen that can update ME firmware with capsules, so that additional installer is no longer needed. Whether it is sensible to backport those fixes to 12th gen and how it updates itself I do not know. It is most likely possible, but there may be technical reasons to discourage touching this, depending on whether that is part of a recovery solution to recover from interrupted/broken updates.
4 Likes
Thank you for providing this info. I ran into the same problem. I’m now good to go.
I am having what I think is the same issue. I am running Fedora 40 (single boot but formerly dual-booted with Windows 11). My main partition is LUKS encrypted, but that shouldn’t affect boot or efi, right?
I’ve tried the official way, and I have tried your suggestions, so they may influence the result. I deleted OsIndications, but it appears to have regenerated.
It’s worth noting I got the usb-PD updates by running Startup.nsh after I typed FS1:, but the firmware wouldn’t install because Framework_Tool was not found (presumable because it is on FS0, the USB drive). When I ran FS0: and then CapsuleApp.efi winux.bin firmwarehdr.cap -OD FS1, I got some messages indicating that the UpdateCapsule contents were transferred to /boot/efi, and in fact there is a new /boot/efi/EFI/UpdateCapsule folder (yes, EFI is repeated, first lowercase, then capital), and it contains firewarehdr.cap and winux.bin, but after it transferred them, without any visible error, it would just boot my computer into grub. I don’t know how to finish the firmware install.
Anways, answers to your questions:
- efivars (I don’t know what piping to xxd. file is)
/sys/firmware/efi/efivars:
AcpiGlobalVariable-c020489e-6db2-4ef2-9aa5-ca06fc11d36a
ArbSvnInfo-643d5856-c4f9-4abe-9c27-331ae36639aa
BoardInfoSetup-1e785e1a-8ec4-49e4-8275-fbbdeded18e7
Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0001-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0002-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot2001-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot2002-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot2003-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootOptionSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c
BRDS-42780dd5-9a7d-404c-80e4-7f7094360394
BugCheckCode-ba57e015-65b3-4c3c-b274-659192f699e3
BugCheckParameter1-ba57e015-65b3-4c3c-b274-659192f699e3
BugCheckProgress-ba57e015-65b3-4c3c-b274-659192f699e3
certdb-59d1c24f-50f1-401a-b101-f33e0daed443
certdbv-59d1c24f-50f1-401a-b101-f33e0daed443
COMPAL-b697de83-1ab6-42c4-9dee-a806c637818b
ConIn-8be4df61-93ca-11d2-aa0d-00e098032b8c
ConInCandidateDev-59d1c24f-50f1-401a-b101-f33e0daed443
ConInDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
ConOut-8be4df61-93ca-11d2-aa0d-00e098032b8c
ConOutCandidateDev-59d1c24f-50f1-401a-b101-f33e0daed443
ConOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
CpuSetup-b08f97ff-e6e8-4193-a997-5e9e9b0adb32
CpuSetupVolatileData-b08f97ff-e6e8-4193-a997-5e9e9b0adb32
CrConfig-7ec07b9f-66e3-43d4-9b52-38fbb46390cc
CrConfigDefault-7ec07b9f-66e3-43d4-9b52-38fbb46390cc
CrDevVar0-7ec07b9f-66e3-43d4-9b52-38fbb46390cc
CrDevVar1-7ec07b9f-66e3-43d4-9b52-38fbb46390cc
CrDevVar2-7ec07b9f-66e3-43d4-9b52-38fbb46390cc
CrPolicy-7ec07b9f-66e3-43d4-9b52-38fbb46390cc
CurrentPolicy-77fa9abd-0359-4d32-bd60-28f4e78f784b
Custom-4570b7f1-ade8-4943-8dc3-406472842384
Custom-5432122d-d034-49d2-a6de-65a829eb4c74
Custom-72c5e28c-7783-43a1-8767-fad73fccafa4
Custom-a04a27f4-df00-4d42-b552-39511302113d
Custom-aaf8e719-48f8-4099-a6f7-645fbd694c3d
Custom-b08f97ff-e6e8-4193-a997-5e9e9b0adb32
Custom-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
CustomPlatformLang-59d1c24f-50f1-401a-b101-f33e0daed443
CustomSecurity-59d1c24f-50f1-401a-b101-f33e0daed443
db-d719b2cb-3d3a-4596-a3bc-dad00e67656f
dbDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c
dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f
dbxDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c
ErrOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
EWRD-92daaf2f-c02b-455b-b2ec-f5a3594f4aea
FeData-1f2d63e1-febd-4dc7-9cc5-ba2b1cef9c5b
FirstBootAfterFlash-59d1c24f-50f1-401a-b101-f33e0daed443
FullReset-59d1c24f-50f1-401a-b101-f33e0daed443
GPC-42780dd5-9a7d-404c-80e4-7f7094360394
GPC-92daaf2f-c02b-455b-b2ec-f5a3594f4aea
H2OFormDialogConfig-98ae8272-ce5a-46be-9f5d-d9f9cbbb99f2
IhisiParamBuffer-92e59835-5f42-4e0b-9a84-47c7810ea806
InitSetupVariable-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
IntelVmdOsVariable-61a14fe8-4dab-4a19-b1e3-97fb23d09212
IP6_CONFIG_IFR_NVDATA-02eea107-98db-400e-9830-460a1542d799
KEK-8be4df61-93ca-11d2-aa0d-00e098032b8c
KEKDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c
Kernel_Lsa_Ppl_Config-77fa9abd-0359-4d32-bd60-28f4e78f784b
Lang-8be4df61-93ca-11d2-aa0d-00e098032b8c
LangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c
MebxCfg-ed6d18b3-16bd-40d8-8950-f0c592f6fa16
MemoryOverwriteRequestControl-e20939be-32d4-41be-a150-897f85d49829
MemoryOverwriteRequestControlLock-bb983ccf-151d-40e1-a07b-4a17be168292
MemoryTypeInformation-4c19049f-4137-4dd3-9c10-8b97a83ffdfa
MeSetup-5432122d-d034-49d2-a6de-65a829eb4c74
MeSetupStorage-5432122d-d034-49d2-a6de-65a829eb4c74
MeSetupStorageCustom-5432122d-d034-49d2-a6de-65a829eb4c74
MokListRT-605dab50-e046-4300-abb6-3dd810dd8b23
MokListTrustedRT-605dab50-e046-4300-abb6-3dd810dd8b23
MokListXRT-605dab50-e046-4300-abb6-3dd810dd8b23
MotherBoardHealth-ea1fcaee-3a77-4bb8-9b98-518e75d29a99
MsdmAddress-fd21bf2b-f5d1-46c5-aee3-c60158339239
MTC-eb704011-1402-11d3-8e77-00a0c969723b
NetworkSetup-a04a27f4-df00-4d42-b552-39511302113d
NhltEndpointsTableConfigurationVariable-a1d89a3a-4a90-429d-4365-1f64c3a29614
OfflineUniqueIDEKPubCRC-eaec226f-c9a3-477a-a826-ddc716cdc0e3
OfflineUniqueIDEKPub-eaec226f-c9a3-477a-a826-ddc716cdc0e3
OsIndications-8be4df61-93ca-11d2-aa0d-00e098032b8c
OsIndicationsSupported-8be4df61-93ca-11d2-aa0d-00e098032b8c
PasswordConfig-f72deef6-13ef-4958-b027-0e45ce7fa45e
PchSetup-4570b7f1-ade8-4943-8dc3-406472842384
PciBusSetup-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
PhysicalBootOrder-59d1c24f-50f1-401a-b101-f33e0daed443
PK-8be4df61-93ca-11d2-aa0d-00e098032b8c
PKDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c
PlatformLang-8be4df61-93ca-11d2-aa0d-00e098032b8c
PlatformLangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c
RestoreFactoryDefault-59d1c24f-50f1-401a-b101-f33e0daed443
S3MemoryVariable-973218b9-1697-432a-8b34-4884b5dfb359
SADS-42780dd5-9a7d-404c-80e4-7f7094360394
SADS-92daaf2f-c02b-455b-b2ec-f5a3594f4aea
SaSetup-72c5e28c-7783-43a1-8767-fad73fccafa4
SbatLevelRT-605dab50-e046-4300-abb6-3dd810dd8b23
SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c
SecureBootData-aa1305b9-01f3-4afb-920e-c9b979a852fd
SecureBootEnforce-59d1c24f-50f1-401a-b101-f33e0daed443
SecureFlashInfo-382af2bb-ffff-abcd-aaee-cce099338877
SetPcrBanks-8376bdca-5e03-4735-951a-4a74141e5886
Setup-a04a27f4-df00-4d42-b552-39511302113d
SetupCpuFeatures-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
Setup-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
SetupMode-8be4df61-93ca-11d2-aa0d-00e098032b8c
SignatureSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c
SiSetup-aaf8e719-48f8-4099-a6f7-645fbd694c3d
SPLC-92daaf2f-c02b-455b-b2ec-f5a3594f4aea
TbtRetimer1Version-567ce681-487d-42ff-b875-38c963e5bb4c
TbtRetimer2Version-125622a2-2aeb-4930-a5a4-e2b9955b6d9e
TbtSetupVolatileData-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
Tcg2ConfigInfo-07a66697-d400-4903-b3da-67a61d2b7058
Tcg2PhysicalPresence-aeb9c5c1-94f1-4d02-bfd9-4602db2d3c54
Tcg2PhysicalPresenceFlags-aeb9c5c1-94f1-4d02-bfd9-4602db2d3c54
Timeout-8be4df61-93ca-11d2-aa0d-00e098032b8c
UnlockIDCopy-eaec226f-c9a3-477a-a826-ddc716cdc0e3
VarErrorFlag-04b37fe8-f6ae-480b-bdd5-37d98c5e89aa
VendorKeys-8be4df61-93ca-11d2-aa0d-00e098032b8c
WAND-92daaf2f-c02b-455b-b2ec-f5a3594f4aea
WGDS-92daaf2f-c02b-455b-b2ec-f5a3594f4aea
WIFI_MANAGER_IFR_NVDATA-3441803e-5a88-4941-82f0-858a1085276c
WRDD-92daaf2f-c02b-455b-b2ec-f5a3594f4aea
WRDS-92daaf2f-c02b-455b-b2ec-f5a3594f4aea
- Contents of ESP partition:
/boot/efi/EFI/:
Boot fedora UpdateCapsule
/boot/efi/EFI/Boot:
BOOTIA32.EFI bootx64.efi fbia32.efi fbx64.efi
/boot/efi/EFI/fedora:
BOOTIA32.CSV gcdx64.efi grubia32.efi mmx64.efi shimx64.efi
BOOTX64.CSV grub.cfg grubx64.efi shim.efi
gcdia32.efi grubenv.rpmsave mmia32.efi shimia32.efi
/boot/efi/EFI/UpdateCapsule:
firmwarehdr.cap winux.bin
- There is NOT a folder on the usb drive
/EFI/CapsuleUpdate/
Something strange happened here. These files should not be coped with these names to this folder.
The CapsuleApp will copy these, and name them to UpdateCapsule000x, so was this a manual attempt? Can you try to remove these two files and try again?
2 Likes
I deleted them (along with the OsIndications efivar) and tried again. Same as before. When the computer rebooted, I was still on 3.04, and the firmwarehdr.cap and winux.bin files were recreated. Linking a video to show what happened. Like before, there were no error messages. Just a near-instantaneous reboot.
Could the issue be some sort of interruption? Is it possible they have been copied over, but not yet renamed when it reboots? For your information, I pressed no other buttons. I would think if it had to stop because of an error or lack of space, it would show a panic message before the reboot, but while it goes by quickly, I don’t think I see an error message.
2 Likes
Please keep this thread on topic. The aim of this thread is for people to report successes/issues with updating to this BIOS release through the various updating methods. This will allow the team to make improvements if necessary and allow others to receive support.
4 Likes
I’m using GDP G1 and it was working fine with 3.06. It doesn’t work with 3.08. There were many NixOS updates before I got to this eGPU after 3.08 update, so I’m not absolutery sure that the BIOS update is the reason.
Updated with 3.08d through UEFI + updated retimers. eGPU still doesn’t work.
framework tools
framework_tool --versions
UEFI BIOS
Version: 03.08
Release Date: 12/25/2023
EC Firmware
Build version: "hx30_v0.0.1-4ea1c89 2023-12-11 14:15:35 runner@fv-az1124-221"
RO Version: "hx30_v0.0.1-4ea1c89"
RW Version: "hx30_v0.0.1-4ea1c89"
Current image: RO
PD Controllers
Right (01)
Main App: 0.1.44 (Notebook)
Backup App: 0.1.44 (Notebook)
Left (23)
Main App: 0.1.44 (Notebook)
Backup App: 0.1.44 (Notebook)
Retimers
Left: 0x136 (310)
Right: 0x136 (310)
CSME
Enabled: true
Version: 0:16.1.30.2269
Recovery Ver: 0:16.1.30.2269
Original Ver: 0:16.0.15.1810
dmesg
[ 5.010315] pcieport 0000:00:07.3: pciehp: Slot(6): Link Down
[ 5.010324] pcieport 0000:00:07.3: pciehp: Slot(6): Card not present
[ 5.010335] pcieport 0000:7e:04.0: Unable to change power state from D3hot to D0, device inaccessible
[ 5.010959] pcieport 0000:7e:04.0: Runtime PM usage count underflow!
[ 5.010987] xhci_hcd 0000:82:00.0: remove, state 1
[ 5.010996] usb usb6: USB disconnect, device number 1
[ 5.011000] usb 6-1: USB disconnect, device number 2
[ 5.011654] xhci_hcd 0000:82:00.0: USB bus 6 deregistered
[ 5.011663] xhci_hcd 0000:82:00.0: xHCI host controller not responding, assume dead
[ 5.011730] xhci_hcd 0000:82:00.0: remove, state 1
[ 5.011735] usb usb5: USB disconnect, device number 1
[ 5.011737] usb 5-1: USB disconnect, device number 2
[ 5.012150] xhci_hcd 0000:82:00.0: Host halt failed, -19
[ 5.012153] xhci_hcd 0000:82:00.0: Host not accessible, reset failed.
[ 5.012547] xhci_hcd 0000:82:00.0: USB bus 5 deregistered
. . . Disconnecting device
[ 459.567079] thunderbolt 1-0:3.1: retimer disconnected
[ 459.568183] thunderbolt 1-3: device disconnected
. . . Plugging it back in
[ 576.786862] thunderbolt 1-0:3.1: new retimer found, vendor=0x8087 device=0x15ee
[ 577.428496] thunderbolt 1-3: new device found, vendor=0x8086 device=0x11
[ 577.428504] thunderbolt 1-3: Intel Tapex Creek
[ 583.949613] usb usb2-port4: attempt power cycle
[ 592.405478] usb usb2-port4: unable to enumerate USB device
1 Like
I tried to execute the command manually but no success. The laptop restarts and boot directly into Ubuntu
I send you my efivars via pm
/boot/efi/EFI/:
BOOT
ubuntu
UpdateCapsule
/boot/efi/EFI/BOOT:
BOOTX64.EFI
fbx64.efi
mmx64.efi
/boot/efi/EFI/ubuntu:
BOOTX64.CSV
grub.cfg
grubx64.efi
mmx64.efi
shimx64.efi
/boot/efi/EFI/UpdateCapsule:
firmwarehdr.cap
retimer01.cap
retimer23.cap
winux.bin
no CapsuleUpdate folder:
/media/xxx/Transcend/:
CapsuleApp.efi
CyPDADlt1.efi
efi
firmware.cap
firmwarehdr.cap
Framework_Laptop_12th_Gen_Intel_Core_Retimer_port01_310.cap
Framework_Laptop_12th_Gen_Intel_Core_Retimer_port23_310.cap
Framework_Laptop_13_12th_Gen_Intel_Core_3.08d_EFI.zip
framework_tool.efi
FWupdate.bin
FWupdate.txt
FWUpdLcl.efi
h2offt.efi
pd01.rom
pd23.rom
updateretimers.nsh
winux.bin
/media/xxx/Transcend/efi:
boot
/media/xxx/Transcend/efi/boot:
Bootx64.efi
Startup.nsh
I try 1 and 2 but no but no success. The laptop always restarts and boots directly into Ubuntu
1 Like
Could you try going to the F2 bios setup menu, and go to save and exit, apply optimal defaults, and then try again? This should reset all BIOS settings to default. There may be some strange state held that this could reset and allow your update to work correctly.
1 Like
I did this before I recorded the video and reported my results.
Is secure boot enabled???
Did the update including retimers. I’m not sure how to check retimer version, but bios version did update correctly. When updating the bios, I originally had my laptop unplugged but at 100% battery. It updated the firmware fine, but then when it went to update BIOS, it would give me the Framework bootup splash screen with a message akin to “Applying system upgrades” (I don’t remember the exact words) and immediately turn off.
I had to make sure the laptop was plugged in for the bios updates to work. It sure got REALLY HOT when updating the bios I gotta say, and it took a long time, but eventually it did finish.
Updating the retimers was considerably less dramatic 
Thanks guys!
Now that FW has officially released the Windows driver for the Fingerprint Sensor in the FW13 AMD driver package (dated 2024-04-02 ), can we get that as well for 11-13th gen boards?
As per Framework it fixes security issues and the fingerprint sensor to our knowledge is exactly the same across all FW13 variants and as a USB device is independent of which CPU/mainboard you have in the system.
13th gen driver package has remained on .180
12th gen driver package has remained on .170
11th gen driver package has remained on .140
3 Likes
Hello, can somebody help me with updating the bios?
I run a single boot Arch linux. I’ve formatted an usb drive to fat32 on another Windows laptop and extracted the zip contents. Both Windows on the other laptop and Arch recognized the drive. The drive is also recognized in the bios of the Framework laptop. However, when booting the system and pressing F12, the usb with the update files doesn’t show up! Whatever I do, it’s not there. What can I do?
If the drive is just FAT32, then there probably isn’t any EFI partition or system files to boot from on that partition. Creating an EFI partition and placing files for EFI booting on that partition would be the first step in allowing it to become bootable, I believe. Others would have to chime in with further details, since I’ve not updated a Framework’s BIOS through Linux.
There does not need to be an EFI System partition. Not on external USB drives.
If it’s not recognized as bootable the BIOS does not like sth. about it. Maybe the folder structure, maybe the way it is partitioned, maybe the stick itself.
That’s interesting, I didn’t know that. I thought either an EFI partition or an older style BIOS boot configuration would be required in order to boot from USB media. If there’s no boot partitions, I’d think it wouldn’t be bootable unless a boot loader on the SSD is preset to boot from the USB media as one of its options.
My understanding is that the F12 boot menu would search for bootable media appropriately set up to be bootable, though I could be wrong.
I disabled it.