Framework Desktop Ryzen AI MAX 300 BIOS 3.06 Release STABLE

Framework Desktop
, ,
1

We have moved this BIOS to stable, if you have update 3.06 in beta phase, no need to do any action.

Highlights

  1. Update AMD PI to 1.0.0.2c.
  2. Modified the F2 key in the F12 Boot Menu to go to the setup menu instead of the settings menu to allow easier navigation to secure boot settings.
  3. Added support for the single-ROM BIOS Crisis Recovery feature.
  4. Implemented a delay in sending the 3A profile to prevent incomplete UCSI PPM command resets during S0 boot transitions.
  5. Added validation logic to reject invalid USB PD index values.
  6. Fixed a boot hang issue occurring with specific video encoder cards.
  7. Resolved an issue where an unidentified UART device appeared in the BIOS, and fixed a bug causing console support to be lost following a BIOS update.
  8. Fixed an issue where the system was unable to boot from partially locked self-encrypting drives (SEDs)
  9. Resolved an issue where the iGPU memory size was incorrectly capped at 24 GB on systems populated with 96 GB of system memory
  10. Security Fixed - CVE-2024-36345, CVE-2024-36343, CVE-2025-54502, CVE-2025-62626

Please note: With BIOS 3.06, you can downgrade to a previous version.

You can check your current BIOS version following the steps here to determine if you are on the latest release.

Subscribing to release notifications

If you want to subscribe to new release notifications you can now opt in through this link to receive an email when we release a new BIOS or driver update for your Framework Desktop.

BIOS Crisis Recovery

At the end of POST, the BIOS hands control off to your operating system. Crisis Recovery is a special alternative mode: instead of booting an OS, the BIOS looks for a firmware update file and re-flashes itself.

This lets the system repair its own firmware after a failed or corrupted BIOS flash, for example if a BIOS update was interrupted by a power loss and the machine no longer boots normally.

When To Use BIOS Crisis Recovery

Use these steps if your system fails to power on to the OS after a BIOS update, shows no display, or you were instructed to perform a BIOS recovery. If your system still boots normally, you do not need this procedure.

How Recovery Is Triggered

If the BIOS detects that its own code in flash memory has been corrupted, it automatically enters Crisis Recovery and begins searching attached storage for a recovery file. You do not need to press anything.

Prepare the Recovery Drive

On a working system:

  1. Insert the USB flash drive and format it as FAT32. (This erases the drive)
  2. On the drive, create the folder path \EFI\FWK (an EFI folder, and inside it an FWK folder).
  3. Copy the recovery file into that FWK folder.(The CAP file can be got from the EFI updater package) The full path should be: \EFI\FWK\Desktop_AMD_Ryzen_AI_Max_300_RECOVERY.fd (The file name is case-sensitive and must match exactly.)
  4. Double-check the file name is spelled exactly and with the same capitalization as shown above, ending in .fd.
  5. Safely eject the drive.
Perform the Recovery

On a target system:

  1. Power off the affected system completely.
  2. Insert the prepared recovery drive into a USB port on the affected system.
  3. If the BIOS is corrupted it may enter recovery automatically at power-on.
  4. The BIOS scans all attached storage (USB and NVMe) for the recovery file in \EFI\FWK, then begins re-flashing. Do not power off or remove the drive during this process. (It may take a few minutes to scan and enter the recovery.)
  5. Wait for the update to complete and the system to restart. The system should then boot to the operating system normally.

Important!! Once flashing begins, keep the system powered and do not remove the recovery media until the process finishes. Interrupting a BIOS flash can leave the system unbootable.

Downloads

Windows

Download Link SHA256
Framework_Desktop_Ryzen_AI_MAX_300_BIOS_3.06.exe 1D91EDB92766D9252AC0E185C94729B5234935FFA21056DFCCDE9592BCD817C1

Please do not interrupt power to your desktop while the update is in progress.

Instructions for Windows Installer:

  1. Run the .exe.
  2. Click yes to reboot.
  3. Wait for the firmware progress bar to complete, and then the system will reboot.

Linux/LVFS

Please note that you must update with a charger attached, then run::

fwupdmgr refresh --force

then

fwupdmgr get-updates

then

fwupdmgr update

Linux/Other/UEFI Shell update

Download Link SHA256
Framework_Desktop_Ryzen_AI_MAX_300_BIOS_3.06_EFI.zip 68C251BF20B98C9D0928DDAD51DD920A3B073AA4E1C8BE55FF43454B8B38C013

Note that if you use the EFI shell update with Windows, you should suspend Bitlocker if enabled before updating using the EFI updater.

Please do not interrupt power to your desktop while the update is in progress.

Instructions for EFI shell update:

  1. Extract contents of zip folder to a FAT32 formatted USB drive. Cleanly unmount the drive before physically removing it, otherwise the BIOS update may not function correctly.
  2. Set the ESP flag for the FAT32 partition.
  3. Boot your system while pressing F12 and boot from the thumb drive.
  4. Let startup.nsh run automatically.
  5. Follow the instructions to install the update.

Security Fixes

CVE Note Score (CVSS Version 4.0)
CVE-2026-6726 An information leakage vulnerability was reported in the TCG TPM 2.0 reference code that could allow a local attacker with elevated privileges to obtain a credential from a TPM-aware CA for a falsified TPM key (such as an Attestation Key, DevID Key or TLS authentication key) and falsify other TPM 2.0 attestations with this key. See also TCG VRT0010. 7.9
CVE-2025-62626 Improper handling of insufficient entropy in the AMD CPUs could allow a local attacker to influence the values returned by the RDSEED instruction, potentially resulting in the consumption of insufficiently random values. 7.2
CVE-2025-54502 Incorrect use of boot service in the AMD Platform Configuration Blob (APCB) SMM driver could allow a privileged attacker with local access (Ring 0) to achieve privilege escalation potentially resulting in arbitrary code execution. 7.1
CVE-2026-6727 A timing side-channel vulnerability exists in the RSA OAEP decryption implementation. A privileged local attacker with access to the TPM command interface may be able to exploit timing differences to recover information that could allow decryption of ciphertexts encrypted to TPM-managed RSA keys, including the RSA Endorsement Key (EK), including import blobs, credential blobs, and session salts. Under certain conditions, this may also enable the forgery of TPM 2.0 attestations. Refer to TCGVRT0011. 5.9
CVE-2024-36345 Improper input validation in the AMD OverDrive (AOD) System Management Mode (SMM) module could allow a privileged attacker to perform an out-of-bounds read, potentially resulting in loss of confidentiality. 4.6
CVE-2024-36343 libmodbus v3.1.6 was discovered to contain a heap overflow via the modbus_mapping_free() function. N/A

Enhancements

  1. Update AMD PI to 1.0.0.2c.
  2. Added support for the single-ROM BIOS Crisis Recovery feature.
  3. Modified the F2 key in the F12 Boot Menu to go to the setup menu instead of the settings menu to allow easier navigation to secure boot settings.
  4. Implemented a delay in sending the 3A profile to prevent incomplete UCSI PPM command resets during S0 boot transitions.
  5. Added validation logic to reject invalid USB PD index values.

Fixes

  1. Fixed a boot hang issue occurring with specific video encoder cards.
  2. Resolved an issue where an unidentified UART device appeared in the BIOS, and fixed a bug causing console support to be lost following a BIOS update.
  3. Fixed an issue where the system was unable to boot from partially locked self-encrypting drives (SEDs)
  4. Resolved an issue where the iGPU memory size was incorrectly capped at 24 GB on systems populated with 96 GB of system memory

Component Versions

This BIOS update is a bundle of updates to multiple embedded components in the system.

Not all of them use the same version number.

Firmware Version Updated?
BIOS 3.06 Updated
EC ec_306_bb3566e Updated
PD 0.0.0E Same
AMD PI StrixHaloPI-FP11 1.0.0.2c Updated

Reporting Issues

To report issues we have created a public issue tracker on github. Issues · FrameworkComputer/SoftwareFirmwareIssueTracker · GitHub We hope that this is a better way to track issues with community involvement moving forward as we have found it difficult to both gather relevant information about issues people are reporting on the forums, and track the issues through their lifecycle in a transparent way.
If you do experience an issue with the update that is related to your system firmware, please post as complete a description as you can, including relevant system information, and external peripherals. Please note that we do not currently have a SLA for responding to issues on github, but we will be reviewing them through the bios release process, and will review them for future updates as well.

If you have an issue regarding hardware, broken devices, returns, etc, this is not the place, please contact support.

Known Issues

  • Certain USB-C peripherals may exhibit intermittent compatibility issues during the PD or DisplayPort Alt Mode handshake.
2 Likes
2

i have updated 3.04 – > 3.06. trying out mx-linux 25.2/debian13.

i will find some bench mark stuff to crunch and update here again. used usb efi update.

did some short sanity check test on kdisk, 2 nvme drives > 5xxxmb/s

setting powersave/performance mode. looks ok

plug in usb, looks ok. will try some external ssd test later.

off topic , flircam check on 400w psu, at idle, the insides indicated 50C. :face_with_peeking_eye: i suppose this is the norm?

what other quirky things should i try? :zany_face: timespy?

4

Also tried connecting TBU405 on the USB-C back port.

It should appear as a /dev/nvme device, but comes up as /dev/sda.

How does yours appear?

Same thing happens with TBU401 and Terramaster D4 SSD.

That means a drop in speed from 5000 MB/s to 1250 MB/s.

5

TBU405 should be JHL7440, i have not yet read into details of TB stuff so im not sure

@ EU47, to max out the speed, you need JHL9480 stuff inside

my last use of NVME>USB>system = linux display the drive as dev/sdx (9210c chipset) 0.5GB/s

TB3 = USB4 = 2+GB/s =JHL7440, JHL9480 = TB5 = 6+GB/s

7

Thanks, you confirm my suspicions.

Exactly the same thing is happening in FreeBSD: the OS shows the drives connected to USB4 ports as SCSI instead of NVME.

The fact the two completely different operating system behave the same way logically indicates that there is the problem with the machine. Also, exactly the same kernels work perfectly fine for me on an Intel machine.

I suspect that it is not a hardware problem, but a BIOS problem, because there are many other machines based on AMD Ryzen AI 300 Series that behave correctly.

I also have an open ticket with Framework, hopefully they will fix the BIOS as this is a very bad advertisement for their product.

8

it looks like JHL7440 during boot tells the system it is TB4 and the system could process it, but during live plug unplug event, the TB4 enumeration message is lost, or something to that effect ? :melting_face:

9

When plugged in, the negotiation between the chipset inside the SSD enclosure and the Framework machine establishes the communication protocol to be used. If PCIe tunneling is detected to be working, then it will be USB4 or Thunderbolt, if not it will be downgraded to USB 3.1. I was told this by two manufacturers of Thunderbolt hubs, CalDigit and Sabrent.

My Terramaster D4 SSD is a newer product than the ACASIS enclosures that I have, it has an ASMedia ASM2464PDX controller chipset and works the same way when plugged in.

11

When you try SSD enclosures under three different operating systems - Linux, FreeBSD and Windows - or different distributions and they all behave the same way, when you tell them it’s not only one enclosure but four of them, when you tell them that those same enclosures work perfectly fine on different machines under the same operating systems, you simply can’t reason with these people as they ignore any technical or logical argument that goes against their work assignments.

Not only that the response is strange and disappointing, it is the typical response of manufacturers that simply wash their hands and put the blame on third parties.

I’m sure that their support staff can find a USB4 / Thunderbolt enclosure or two and do the necessary tests in one hour, but they will never do that, it’s much easier for them to give you that kind of answer that masks their indifference under fake politeness.

I bought the Framework Desktop because of their supposedly very good Linux support compared to other manufacturers of similar machines. That proved to be utterly false.

2 Likes
12

Somehow after this BIOS update I started getting the ancient unfamous GPU page fault when trying to load any model with ROCm 7.14:

314.734058] amdgpu 0000:c1:00.0: [gfxhub] page fault (src_id:0 ring:153 vmid:8 pasid:60)
[ 314.734068] amdgpu 0000:c1:00.0: Process llama-server
pid 10961 thread llama-server pid 10961
[ 314.734071] amdgpu 0000:c1:00.0: in page starting at
address 0x0000774b3141c000 from client 10
[ 314.734073] amdgpu 0000:c1:00.0: GCVM_L2_PROTECTION_FAULT_STATUS:0x00800932
[ 314.734074] amdgpu 0000:c1:00.0: Faulty UTCL2 client ID: CPF (0x4)
[ 314.734076] amdgpu 0000:c1:00.0: MORE_FAULTS: 0x0
[ 314.734077] amdgpu 0000:c1:00.0: WALKER_ERROR: 0x1[ 314.734078] amdgpu 0000:c1:00.0: PERMISSION_FAULTS: 0x3
[ 314.734079] amdgpu 0000:c1:00.0: MAPPING_ERROR: 0x1
[ 314.734080] amdgpu 0000:c1:00.0: RW: 0x0

I updated kernel from 7.0.0-28 to 7.0.0-29 too before noticing this, so I tried reverting to the kernel which I was sure worked previously (-28) and it did not work. I’m on Ubuntu 26.04, newest default kernel (-29).
I feel like this is the 10th time either the XDNA or GPU path breaks completely randomly on an update, which is super annoying. Previously XDNA was completely broken 2 months after it started getting properly supported for another 2 month until a random kernel update fixed it. Strix Halo is a huge mess for how relatively popular it seems to be.

Did not observe the same issue with a -29 kernel on another Halo device from another vendor, so it’s either Divine Intervention or something unique about Framework’s firmware update

Edit: I tried a bunch of stuff, in case anyone stumbles into this when googling the only thing that helped me was adding amdgpu.sched_policy=2 to GRUB
Edit2: nvm that’s a terrible idea unless you only ever have a single instance llama server

13

regarding firmware update. i had a quick scan here sometime back, since there is a chance of things going wrong. i installed the OS after the update. so there was no problem

17

systemd died. and i was looking for secureboot switch. its missing too. where do i switch the secureboot?

18

as far as I remember you just need to press F2 during boot and it wil open you menu were you can mmanage secure boot

19

yep i know, you can select init/sysd in the drop menu. but i think somewhere, 1 of my installs must have screwed something. so on 1 occasion, i noticed it wasn’t there anymore. sudo apt install blabla all the sysd stuff didnt quite work. which is really really amusing. did a new usb iso install, its blank … wait wads this goin on here :laughing: . it decide not to install sysd as well ? :rofl: i then tried zorin, its sysd no problem but the ui sux :squinting_face_with_tongue:

i have to try some more interesting scenarios :thinking:

maybe, i try bios 3.04 :laughing: , i

20

ok still on 3.06. now i have installed linux mint 22.3 xfce for testing. dumped my bash to auto install. tuned/ryzenadj done. for comparison, on mxlinux sysinit default boots. on mint 22.3, also defaults to sysinit. after editting grub to init= … systemd. it appear to have no problems unlike mx.

before installing my pile of required junk, furmark =150fps. i have no monitoring stuff on to see wattage. post tuned/ryzenadj, it also produced 170fps. unfortunately i don’t know how many watts/temp(tctl) lm-sensor did not fully work :sweat_smile: . will update with some llama bench later

** update : after the same string of bash auto installs to lead to llama bench, the sysd on mint also died. so it is 1 of the update/install things. back to mxlinux to try