12th Gen Intel Core BIOS 3.08 Release

[Lauren_Thomas]

My primary drive is 4 terabytes (3.64 formatted) - which I believe is too large for MBR. It is encrypted with FAT32, ext4, and btrfs partitions and gparted reports GPT. Thanks again.

[Lauren_Thomas]

Also I edited the other post with more information

[JRLarsen]

I just updated my Intel 12th Gen Framework 13 from BIOS 3.04 to the latest 3.08 then tried to update the retimers as well which I don’t believe I’ve ever done before. However, after running the updateretimers.nsh it gives the following errors:

Get Boot Next Data Fail. Status = Not Found
CapsuleApp: connot find a valid file system on boot devices. Status = Not Found
CapsuleApp: failed to update capsule = Not Found

I have a fresh install of Fedora 41 on my NVMe drive

[TheTRUEAsian]

You’re welcome to post any feedback or thoughts on the forums however, you need to keep things on track. This thread is mainly focused on troubleshooting issues with updating to BIOS 3.08 and any off-topic replies will be deleted or split off into another thread.

[JRLarsen]

I had engaged customer support who was very responsive with this issue.
After updating to 3.06 I was then able to update to 3.08 without issue

BIOS 3.06
http://community.frame.work/t/12th-gen-intel-core-bios-3-06-beta/25726​

BIOS 3.08

Framework Laptop BIOS and Driver Releases (12th Gen Intel® Core™)

[Joey_Boon]

After having this tab open on my phone for a very long time and checking back every now an then I gave up and installed Windows on a spare NVME drive and updated the bios. Since I want to replace the battery very soon (and hopefully with the 61wh model) I wanted to update now. This worked like charm, but took way to much time because installing Windows 11 takes ages. Hopefully the update mechanism for Linux users gets some more love in the future

[a_framework_owner]

I would feel dumb to buy an extra nvme drive just for this and I don’t want to backup all my data, install Windows then reinstall my linux set up just for a better battery nor do I have the time to, this my work machine and I have a life to live. I want framework to love me. When we were young and had just met, they said official linux support. This is the part where the community support can’t really help so I make a point of having framework communicate with me in order to save our marriage.

The battery is in the marketplace basket (with other stuff). I will only proceed to checkout when there is a proper non-beta release (or a clear message on why it can’t happen). Blackmail is how you get your marriage back on track.

[Seneca]

I have been following this thread for a while now and wanted to chime in. I can happily add a successful EFI method BIOS update report to this thread. Details below:

• SUCCESS SKU# and SYS SERIAL NUMBER: Omitting for privacy, IIRC it was a batch 4 or 5 board.

• SYS CONFIG: i5-1240p

• RAM: 16GB 3200MHz (2x8GB) Samsung I think.

• SSD: WD BLACK SN850X 500GB

• Wi-Fi: Stock Intel AX210

• External Devices/Other: None.

• EXPANSION CARD TYPES: 2x USB-A 1x USB-C, 4th bay was empty.

• BIOS VERSION: 3.05

• OS VERSION: Fedora Silverblue 41 (Secureblue)

• STEP TO REPRODUCE: EFI Shell method:
  – Formatted USB2 drive as MBR/FAT32
  – Copied the contents of the .zip to the root of the drive.
  – Rebooted, disabling secure boot, and then let startup.nsh run.
  – First round updated the CSME firmware but nothing else as I forgot to connect AC power and was wondering why it was not proceeding for a while, plugged in and it proceeded as normal. BIOS and related firmware versions (sans SI and TXT as I am unsure how to check those from BIOS or Linux) were as expected.
  – Proceeded to also update the retimers by escaping from startup.nsh and running updateretimers.nsh manually as currently instructed. Confirmed that both were successfully updated to 310 after the first run.
  – Also updated the fingerprint reader firmware through LVFS testing for good measure.

• OBSERVED RESULT: Successful BIOS and firmware update through the current 3.08d EFI installer method. This is the expected result.

• EXTERNAL DEVICE MODE or NAME: Some model of PNY 32GB USB2 drive was used.

I am happy that I can report a successful use of the EFI method to update the firmware when using Linux, however I feel I must also mirror what many others have been saying in this thread so far. I feel like Framework has not been handling firmware updates for this board in a proper and timely manner. I admit that this has caused me as well to be hesitant to suggest Framework products to others, as timely BIOS/firmware updates are crucial to maintaining security in our ever-digitizing world today.

I recognize that the issue with the CSME firmware being unavailable for 11th and 12th gen Intel boards through LVFS is an Intel caused problem and is not Framework’s fault. However, I think that Framework has a responsibility to accept this shortcoming and put in a good faith effort to work around it for the support of the community, especially for the enterprise, for as long as Intel supports Alder Lake. In my opinion, the best step forward for firmware support is to validate the factory-installed CSME version or versions against all future BIOS updates to ensure compatibility so that the rest of the components can be automatically updated through LVFS for Linux customers. In the worst case, if this is somehow not possible, the updates should still be provided to LVFS-testing with an update note left letting customers know that they will need to update the CSME firmware through the EFI method as well since Intel does not provide LVFS updates for this platform. This would significantly simplify, and likely stabilize the update process, resolving most of the issues brought up in this thread, as the CSME EFI updater has itself not been an issue. This would go a long way into restoring customer confidence in the company and would show responsibility and transparency in good faith, but I also feel this is the minimum that can be done to restore mine and many other’s faith in the company. Anything less is frankly unacceptable at this point, as it has been nearly a year with no stable Linux/EFI installer. This is not the Linux support I expect from a company advertising as such, and it makes me cautious to trust similar claims for current and future products.

I hope my words help the community feel confident in updating their BIOS, but more importantly that they ring with the team at Framework to get proper support for Linux firmware updates out in the immediate future.

[Patrick_Baker]

I have just updated my BIOS from 3.04 to 3.08 and am now experiencing a really bad issue when the machine resumes from sleep. Every time the machine wakes up the display is corrupted. I can’t switch to a different TTY (linux/debian) and eventually the fans turn on and the display goes black with some backlight still showing. I have to hard reset the machine each and every time. I have ruled out the usually suspects (KDE, Wayland, etc.) and suspect that there is an issue with kernel/i915 drivers and this BIOS release.

I found a few open issues that might be related/similar:

• Resuming from suspend results in crash and display flickering on and off on Alder Lake laptop (#9400) · Issues · drm / i915 / kernel · GitLab
• https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/7402
• no resume or bad resume after suspend (#5470) · Issues · drm / i915 / kernel · GitLab

For now, I am going to see if I can build/apply a newer kernel which might have better error handling for this issue. In the mean time I thought I would post here to see if anyone else ran into similar problems and knows of an easier work-around. My next option (of last resort) will be to roll back to BIOS 3.06 and hope that the issue doesn’t exist in that version. Hibernation continues to work and is my current work-around.

Here are some diagnostics:

System Information

System:
  Host: XXXXXX Kernel: 6.1.0-28-amd64 arch: x86_64 bits: 64
    Desktop: KDE Plasma v: 5.27.5 Distro: Debian GNU/Linux 12 (bookworm)
Machine:
  Type: Laptop System: Framework product: Laptop (12th Gen Intel Core) v: A4
  Mobo: Framework model: FRANMACP04 v: A4
    UEFI: INSYDE v: 03.08 date: 12/25/2023
CPU:
  Info: 12-core (4-mt/8-st) model: 12th Gen Intel Core i5-1240P bits: 64
Graphics:
  Device-1: Intel Alder Lake-P Integrated Graphics driver: i915 v: kernel
  Device-2: Realtek Laptop Camera type: USB driver: uvcvideo
  Display: wayland server: X.Org v: 1.22.1.9 with: Xwayland v: 22.1.9
    compositor: kwin_wayland driver: X: loaded: modesetting unloaded: fbdev,vesa
    dri: iris gpu: i915 resolution: 1: 3944x2632~60Hz 2: 3840x2160~30Hz
  API: OpenGL v: 4.6 Mesa 22.3.6 renderer: Mesa Intel Graphics (ADL GT2)

Likely Related Journal Entry

Dec 12 18:34:26 XXXXXX kernel: ------------[ cut here ]------------
Dec 12 18:34:26 XXXXXX kernel: i915 0000:00:02.0: drm_WARN_ON(intel_dp->pps.vdd_wakeref)
Dec 12 18:34:26 XXXXXX kernel: WARNING: CPU: 0 PID: 255 at drivers/gpu/drm/i915/display/intel_pps.c:595 intel_pps_vdd_on_unlocked+0x2a8/0x2c0 [i915]
Dec 12 18:34:26 XXXXXX kernel: Modules linked in: uas usb_storage scsi_mod scsi_common i915(+) crc32_pclmul crc32c_intel drm_buddy i2c_algo_bit drm_display_helper hid_multitouch hid_sensor_hub ghash_clmulni_intel cec hid_generic sha512_ssse3 rc_core sha512_generic ttm>
Dec 12 18:34:26 XXXXXX kernel: CPU: 0 PID: 255 Comm: (udev-worker) Tainted: G     U             6.1.0-28-amd64 #1  Debian 6.1.119-1
Dec 12 18:34:26 XXXXXX kernel: Hardware name: Framework Laptop (12th Gen Intel Core)/FRANMACP04, BIOS 03.08 12/25/2023
Dec 12 18:34:26 XXXXXX kernel: RIP: 0010:intel_pps_vdd_on_unlocked+0x2a8/0x2c0 [i915]
Dec 12 18:34:26 XXXXXX kernel: Code: 4c 8b 67 50 4d 85 e4 75 03 4c 8b 27 e8 b1 e4 2c c8 48 c7 c1 18 fc 09 c1 4c 89 e2 48 c7 c7 28 2d 0b c1 48 89 c6 e8 b8 8b c8 c7 <0f> 0b e9 e7 fd ff ff e8 6c c2 61 c8 66 66 2e 0f 1f 84 00 00 00 00
Dec 12 18:34:26 XXXXXX kernel: RSP: 0018:ffffa22a809bb3b0 EFLAGS: 00010282
Dec 12 18:34:26 XXXXXX kernel: RAX: 0000000000000000 RBX: ffff8dc3727dc170 RCX: c0000000ffffefff
Dec 12 18:34:26 XXXXXX kernel: RDX: 0000000000000000 RSI: 00000000ffffefff RDI: 0000000000000001
Dec 12 18:34:26 XXXXXX kernel: RBP: ffff8dc3652e8000 R08: 0000000000000000 R09: ffffa22a809bb228
Dec 12 18:34:26 XXXXXX kernel: R10: 0000000000000003 R11: ffffffff8a6d4488 R12: ffff8dc341d253a0
Dec 12 18:34:26 XXXXXX kernel: R13: 0000000000000005 R14: ffff8dc3652e9c20 R15: 0000000000000000
Dec 12 18:34:26 XXXXXX kernel: FS:  00007fc4b221c8c0(0000) GS:ffff8dc6df800000(0000) knlGS:0000000000000000
Dec 12 18:34:26 XXXXXX kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Dec 12 18:34:26 XXXXXX kernel: CR2: 0000561fcd07e0f8 CR3: 000000010d9d8000 CR4: 0000000000750ef0
Dec 12 18:34:26 XXXXXX kernel: PKRU: 55555554
Dec 12 18:34:26 XXXXXX kernel: Call Trace:
Dec 12 18:34:26 XXXXXX kernel:  <TASK>
Dec 12 18:34:26 XXXXXX kernel:  ? __warn+0x7d/0xc0
Dec 12 18:34:26 XXXXXX kernel:  ? intel_pps_vdd_on_unlocked+0x2a8/0x2c0 [i915]
Dec 12 18:34:26 XXXXXX kernel:  ? report_bug+0xe2/0x150
Dec 12 18:34:26 XXXXXX kernel:  ? handle_bug+0x41/0x70
Dec 12 18:34:26 XXXXXX kernel:  ? exc_invalid_op+0x13/0x60
Dec 12 18:34:26 XXXXXX kernel:  ? asm_exc_invalid_op+0x16/0x20
Dec 12 18:34:26 XXXXXX kernel:  ? intel_pps_vdd_on_unlocked+0x2a8/0x2c0 [i915]
Dec 12 18:34:26 XXXXXX kernel:  ? __intel_display_power_get_domain.part.0+0x52/0x70 [i915]
Dec 12 18:34:26 XXXXXX kernel:  ? intel_display_power_get+0x4e/0x60 [i915]
Dec 12 18:34:26 XXXXXX kernel:  intel_dp_aux_xfer+0x127/0x7a0 [i915]
Dec 12 18:34:26 XXXXXX kernel:  ? psi_task_switch+0xb3/0x1f0
Dec 12 18:34:26 XXXXXX kernel:  ? __switch_to_asm+0x3a/0x60
Dec 12 18:34:26 XXXXXX kernel:  intel_dp_aux_transfer+0x201/0x320 [i915]
Dec 12 18:34:26 XXXXXX kernel:  drm_dp_dpcd_access+0xb8/0x150 [drm_display_helper]
Dec 12 18:34:26 XXXXXX kernel:  drm_dp_dpcd_write+0x89/0xd0 [drm_display_helper]
Dec 12 18:34:26 XXXXXX kernel:  intel_dp_sink_set_decompression_state+0x67/0xc0 [i915]
Dec 12 18:34:26 XXXXXX kernel:  intel_disable_ddi+0x12b/0x1e0 [i915]
Dec 12 18:34:26 XXXXXX kernel:  ? __synchronize_hardirq+0x87/0xc0
Dec 12 18:34:26 XXXXXX kernel:  intel_encoders_disable+0x8e/0xb0 [i915]
Dec 12 18:34:26 XXXXXX kernel:  hsw_crtc_disable+0x5a/0x70 [i915]
Dec 12 18:34:26 XXXXXX kernel:  intel_old_crtc_state_disables+0x38/0xa0 [i915]
Dec 12 18:34:26 XXXXXX kernel:  intel_atomic_commit_tail+0x390/0xe40 [i915]
Dec 12 18:34:26 XXXXXX kernel:  intel_atomic_commit+0x34f/0x390 [i915]
Dec 12 18:34:26 XXXXXX kernel:  drm_atomic_commit+0x93/0xc0 [drm]
Dec 12 18:34:26 XXXXXX kernel:  ? drm_plane_get_damage_clips.cold+0x1c/0x1c [drm]
Dec 12 18:34:26 XXXXXX kernel:  intel_modeset_init+0x19c/0x280 [i915]
Dec 12 18:34:26 XXXXXX kernel:  i915_driver_probe+0x5eb/0xe20 [i915]
Dec 12 18:34:26 XXXXXX kernel:  local_pci_probe+0x3e/0x80
Dec 12 18:34:26 XXXXXX kernel:  pci_device_probe+0xc3/0x240
Dec 12 18:34:26 XXXXXX kernel:  really_probe+0xdb/0x380
Dec 12 18:34:26 XXXXXX kernel:  ? pm_runtime_barrier+0x50/0x90
Dec 12 18:34:26 XXXXXX kernel:  __driver_probe_device+0x78/0x120
Dec 12 18:34:26 XXXXXX kernel:  driver_probe_device+0x1f/0x90
Dec 12 18:34:26 XXXXXX kernel:  __driver_attach+0xce/0x1c0
Dec 12 18:34:26 XXXXXX kernel:  ? __device_attach_driver+0x110/0x110
Dec 12 18:34:26 XXXXXX kernel:  bus_for_each_dev+0x84/0xd0
Dec 12 18:34:26 XXXXXX kernel:  bus_add_driver+0x1ae/0x200
Dec 12 18:34:26 XXXXXX kernel:  driver_register+0x89/0xe0
Dec 12 18:34:26 XXXXXX kernel:  i915_init+0x1f/0x7f [i915]
Dec 12 18:34:26 XXXXXX kernel:  ? 0xffffffffc083f000
Dec 12 18:34:26 XXXXXX kernel:  do_one_initcall+0x56/0x220
Dec 12 18:34:26 XXXXXX kernel:  do_init_module+0x4a/0x1f0
Dec 12 18:34:26 XXXXXX kernel:  __do_sys_finit_module+0xac/0x120
Dec 12 18:34:26 XXXXXX kernel:  do_syscall_64+0x55/0xb0
Dec 12 18:34:26 XXXXXX kernel:  ? vm_mmap_pgoff+0x103/0x180
Dec 12 18:34:26 XXXXXX kernel:  ? ksys_mmap_pgoff+0xe8/0x1f0
Dec 12 18:34:26 XXXXXX kernel:  ? exit_to_user_mode_prepare+0x40/0x1e0
Dec 12 18:34:26 XXXXXX kernel:  ? syscall_exit_to_user_mode+0x1e/0x40
Dec 12 18:34:26 XXXXXX kernel:  ? do_syscall_64+0x61/0xb0
Dec 12 18:34:26 XXXXXX kernel:  ? syscall_exit_to_user_mode+0x1e/0x40
Dec 12 18:34:26 XXXXXX kernel:  ? exit_to_user_mode_prepare+0x40/0x1e0
Dec 12 18:34:26 XXXXXX kernel:  ? syscall_exit_to_user_mode+0x1e/0x40
Dec 12 18:34:26 XXXXXX kernel:  ? do_syscall_64+0x61/0xb0
Dec 12 18:34:26 XXXXXX kernel:  ? exit_to_user_mode_prepare+0x40/0x1e0
Dec 12 18:34:26 XXXXXX kernel:  ? syscall_exit_to_user_mode+0x1e/0x40
Dec 12 18:34:26 XXXXXX kernel:  ? do_syscall_64+0x61/0xb0
Dec 12 18:34:26 XXXXXX kernel:  ? __rseq_handle_notify_resume+0xa9/0x4a0
Dec 12 18:34:26 XXXXXX kernel:  ? kmem_cache_free+0x15/0x310
Dec 12 18:34:26 XXXXXX kernel:  ? exit_to_user_mode_prepare+0x40/0x1e0
Dec 12 18:34:26 XXXXXX kernel:  ? syscall_exit_to_user_mode+0x1e/0x40
Dec 12 18:34:26 XXXXXX kernel:  ? do_syscall_64+0x61/0xb0
Dec 12 18:34:26 XXXXXX kernel:  ? exit_to_user_mode_prepare+0x40/0x1e0
Dec 12 18:34:26 XXXXXX kernel:  ? syscall_exit_to_user_mode+0x1e/0x40
Dec 12 18:34:26 XXXXXX kernel:  ? do_syscall_64+0x61/0xb0
Dec 12 18:34:26 XXXXXX kernel:  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
Dec 12 18:34:26 XXXXXX kernel: RIP: 0033:0x7fc4b292d799
Dec 12 18:34:26 XXXXXX kernel: Code: 08 89 e8 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 37 06 0d 00 f7 d8 64 89 01 48
Dec 12 18:34:26 XXXXXX kernel: RSP: 002b:00007ffe9ca2f2b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
Dec 12 18:34:26 XXXXXX kernel: RAX: ffffffffffffffda RBX: 0000561fcd06d480 RCX: 00007fc4b292d799
Dec 12 18:34:26 XXXXXX kernel: RDX: 0000000000000000 RSI: 0000561fcd0711f0 RDI: 0000000000000012
Dec 12 18:34:26 XXXXXX kernel: RBP: 0000561fcd0711f0 R08: 0000000000000000 R09: 0000561fcd0501b0
Dec 12 18:34:26 XXXXXX kernel: R10: 0000000000000012 R11: 0000000000000246 R12: 0000000000020000
Dec 12 18:34:26 XXXXXX kernel: R13: 0000000000000000 R14: 0000561fcd04e6a0 R15: 000000000000001a
Dec 12 18:34:26 XXXXXX kernel:  </TASK>
Dec 12 18:34:26 XXXXXX kernel: ---[ end trace 0000000000000000 ]---

[GhostLegion]

I’m using KDE and Wayland but do not have this issue. Might be a Debian thing but it might be your kernel as you suggest as I’m on 6.11 on Bazzite which is a Fedora derivative.

Just checked, I’m using i915 as well

[Patrick_Baker]

Yes. Thanks for the additional info. The pattern seems to be:

• BIOS 3.04 w/ Kernel 6.1 = No Problem
• BIOS 3.08 w/ Kernel 6.1 = Problem
• BIOS 3.08 w/ Kernel 6.11/12 = No Problem

Unfortunately with Debian, switching kernels is not straight forward. I tried both building 6.12 and patching 6.1. This was my first attempt at building the kernel and things didn’t go so well. I’m going to give it another try later today. Unfortunately this is my wife’s laptop, so switching distros is not an option.

[pierce]

@Patrick_Baker

with Debian, switching kernels is not straight forward

In your case (looks like you’re on current stable Debian 12 “bookworm”) you can install linux-image-amd64 6.11.5 from bookworm-backports, see Instructions

[Patrick_Baker]

Thanks. That link helped out a lot. I tried to use the backports earlier, but it wanted to upgrade 2000 packages. Clearly I was doing it wrong. Following those linked instructions I was able to just install the newer kernel and that solved the problem.

Note for anyone else experiencing the same issue: I did run into an additional problem using the new kernel. The wifi drivers would not load because the firmware was now too old. The error message in the journal is straight forward in this case. I just had to get a newer firmware file from the sources listed in the error message and copy it into my /lib/firmware folder. One reboot later and I was back in business.

[Simon84]

Note that the file in /lib can be overwritten by the next update.
It is more consistent with the package manager, if you check which package the file belongs to and also install that package from backports.

[Patrick_Baker]

Thanks. I did look for the file and try and install the package it was located in, but the apt insisted it was the latest version. I didn’t look any closer, just assumed not all packages are newer in the backports repro. I did save the file elsewhere in case it got overridden.

[gms]

@Seneca

BIOS and related firmware versions (sans SI and TXT as I am unsure how to check those from BIOS or Linux) were as expected.

The TXT component version is stored in the DMI table and you can decode it like this:

https://gist.github.com/gsauthof/030852d24c2825006636276ab3252346

Which prints 1.18.13.0 on my 12th gen Framework laptop, after the update, and thus matches the version specified in the announcement.

(I couldn’t include that small shell one-liner in this post because of a misconfigured discourse filter: Discourse forum somewhat broken, I can't post the command to show the linux kernel version)

---

I have no idea what ‘SI’ even stands for.
Web-searching that version turns up some references to Intel firmware-support-package (FSP) versions - but who knows …

---

@Seneca

I recognize that the issue with the CSME firmware being unavailable for 11th and 12th gen Intel boards through LVFS is an Intel caused problem and is not Framework’s fault.

Hm, there are a few sources that counter this argument in another thread:

[RESPONDED] Framework firmware on the LVFS?

@inffy can you provide a reference for your “because of lvfs” assertion? I was pretty sure that I’d installed plenty of Intel-proprietary blob firmware updates on a thinkpad via LVFS, but first I asked Richard Hughes, who created LVFS, and he confirmed my understanding: If you have a reference for “because of lvfs” to share here, that might help clear up confusion.

(see also the few follow-ups after comment post)

[GhostLegion]

So! We are about a year with this release! It appears to be out of beta, great! When is the next release? Seriously. I mean that. A new update could help unify the UX/UI with navigating the BIOS by bringing the same graphical look to 11/12th gen. Furthermore, I’d still realllly like to have ReBAR support officially implemented.

Given that it is no longer in beta…did the EFI capsule problems get worked out? I don’t recall there being a definitive announcement from Framework but I also don’t see any mention of it in the top-post

If not…would be uber cool to get that fixed, extra brownie points if pushed out via LVFS. I’m certain others can chime in with feature requests/bug fixes for an updated BIOS for our aged 12th gen boards.

News on the rollout of that new and awesome process for future firmware updates that was promised (last year? I think?) would also be appreciated by the community I think.

[CodeAsm]

@Kieran_Levin

Linux/LVFS

Please note that for this platform LVFS will not update the CSME firmware. so we only recommend updating using the EFI updater. This is a limitation of LVFS which does not ship the binary blobs from Intel necessary to update the CSME.

I understand your questions, but i remember reading the above post by Kieran about LVFS. also, 3.08 for windows was release, only the EFI updater part was still in beta. the internal files where the same for windows, so basically the bios itself is release. the updater itself might be whats interesting if now final release, or better question: is it considered stable enough? meanwhile many folks have succesfully (or after some guidance) updated their bioses (and other firmware parts)

[Brendan]

I updated successfully. Only after trying many times and checking the forum often for tips and updates. A less stressful LVFS supported update mechanism would be best for most users, especially non-technical users.

[Anthony_Garrett_Guil]

• FAILURE SKU# and SYS SERIAL NUMBER: FRANDACP04, FRANDACPA42403002X

• SYS CONFIG: i5-1240P

• RAM: 32GB (2x16GB Crucial CT16G4SFRA32A.C16FN DDR4-3200)

• SSD: Patriot P310P240GM28 (240GB)

• Wi-Fi: None.

• External Devices/Other: Standalone install in Cooler Master case with known-good 100W USB-C PD adapter; no battery connected. HDMI-over-USB-C display connection and USB-A keyboard in the opposite ports.

• EXPANSION CARD TYPES: 2x USB-A, 2x USB-C; one of each on left and right side, USB-C on bottom slots

• BIOS VERSION: 3.05

• OS VERSION: Fedora Workstation 41 (KDE)

• STEP TO REPRODUCE: EFI Shell method:
  – Formatted USB3 drive as MBR/FAT32 and copied the contents of the BIOS update .zip to the root of the drive.
  – Connected USB-C PD and USB3 drive to right-side ports.
  – Rebooted, then let startup.nsh run.
  – First round updated CSME firmware but skipped the left-side PD firmware updates since I couldn’t swap PD to that side without a battery installed. BIOS update did not continue.
  – Proceeded to also update the retimers by escaping from startup.nsh and running updateretimers.nsh manually as currently instructed. Confirmed that both were successfully updated to 310 after the first run.
  – Shutdown, swapped PD and USB drive to left-side ports.
  – Rebooted, then let startup.nsh run.
  – Second round updated left-side PD firmware, then threw Error 331: Full FW Update using same version is not allowed. Include -allowsv in command line to allow it. and proceeded with BIOS upgrade attempt.

• OBSERVED RESULT:

  The BIOS updater halts and immediately powers the system off after reporting success writing firmwarehdr.cap.

  Loading BIOS updates in 4 seconds
  CapsuleApp: creating capsule descriptors at 0x3F087798
  CapsuleApp: capsule data starts          at 0x37C00018 with size 0xA5422
  CapsuleApp: capsule block/size              0x37C00018/0xA5422
  CapsuleApp: creating capsule descriptors at 0x3F087B18
  CapsuleApp: capsule data starts          at 0x3598B018 with size 0x2274DC4
  CapsuleApp: capsule block/size              0x3598B018/0x2274DC4
  Found EFI system partition on Boot0001: Fedora
  FS0:;HD0b:;BLK1: PciRoot(0x0)/Pci(0x6,3x0)/Pci(0x0,0x0)NVMe(0x1,00-00-00-00-00-34-68-48)/HD(1,GPT,D9BDF3C6-EA59-4F1D-8914-6865A172C442,0x800,0x12C000)
  Succeed to write winux.bin
  Succeed to write firmwarehdr.cap
  

  

  The system then immediately shuts down. Rebooting into the OS works, and I can confirm there that the BIOS update did not take.

  I re-attempted by rotating PD and USB drive from left to right side, then rotating USB-C and USB-A ports from bottom to top, then again from right to left side. All result in the same behavior.

  I then wiped the USB drive, unzipped the 3.06 BIOS update onto it, and rebooted into the updater. The upgrade worked without error or issue.

  I then wiped the USB drive, unzipped the 3.08 BIOS update onto it, and reattempted the above steps to reproduce, including iterating on port usage and expansion card placement. All halt at the same point and fail to upgrade the BIOS.

  I am now on BIOS 3.06 and have stopped attempting to upgrade to 3.08.

• EXTERNAL DEVICE MODE or NAME: SanDisk Corp. Ultra Fit 16GB USB3 thumb drive connected to USB-A expansion card