# Framework Laptop 16 Ryzen 7040 BIOS 4.04 Release STABLE **URL:** \ **Category:** Framework Laptop 16\ **Tags:** bios-announcement, framework-laptop-16-amd-ai-300, bios, graphics-module-amd-rx7700s, framework-laptop-16-amd-7040, graphics-module-nvidia-5070\ **Created:** [April 10, 2026, 7:04am UTC](https://community.frame.work/t/framework-laptop-16-ryzen-7040-bios-4-04-release-stable/81740 "2026-04-10T07:04:14Z")\ **Posts on this page:** 20\ **Page:** 2
**Author:** ![Adrian\_Joachim](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/adrian_joachim/32/9949_2.png) [@Adrian\_Joachim](https://community.frame.work/u/Adrian_Joachim)\ **Post date:** [May 6, 2026, 8:52am UTC](https://community.frame.work/t/framework-laptop-16-ryzen-7040-bios-4-04-release-stable/81740/21 "2026-05-06T08:52:50Z")
> [@James3](#): > > Symptom is, the EC can get into a state where it thinks the AC is on, when the power adapter is actually removed. > Inserting and removing the power adapter does not fix it. It’s the pd controller firmware again isn’t it? Man I wish we also got access to source and documentation for that. Imagine how polished an implementation that would eventually become with the community working on it. ---
**Author:** ![jared\_kidd](https://avatars.discourse-cdn.com/v4/letter/j/91b2a8/32.png) [@jared\_kidd](https://community.frame.work/u/jared_kidd)\ **Post date:** [May 6, 2026, 3:47pm UTC](https://community.frame.work/t/framework-laptop-16-ryzen-7040-bios-4-04-release-stable/81740/22 "2026-05-06T15:47:25Z")
@Quin_Chou can we get an update on progress? It’s been almost another month since this buggy release. I’m really tired of my ports not accepting charging, the battery draining too fast in sleep mode, and CPU limited low power while dGPU is off. It would be really nice if framework showed us they actually care by fixing these long standing issues. ---
**Author:** ![James3](https://avatars.discourse-cdn.com/v4/letter/j/b5e925/32.png) [@James3](https://community.frame.work/u/James3)\ **Post date:** [May 6, 2026, 9:35pm UTC](https://community.frame.work/t/framework-laptop-16-ryzen-7040-bios-4-04-release-stable/81740/23 "2026-05-06T21:35:20Z")
Regarding the “frequency lock low” problem. Can you describe the problem a bit better by raising an Issue over here: > **[Issues · FrameworkComputer/SoftwareFirmwareIssueTracker](https://github.com/FrameworkComputer/SoftwareFirmwareIssueTracker/issues)** > > Public Issue Tracker for Firmware Issues related to Framework Products - Issues · FrameworkComputer/SoftwareFirmwareIssueTracker I would like to understand how to reproduce the problem, as I don’t see it currently. So, if you put enough details in that a new Issue there, we might be able to make progress. ---
**Author:** ![Guillaume\_C](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/guillaume_c/32/39715_2.png) [@Guillaume\_C](https://community.frame.work/u/Guillaume_C)\ **Post date:** [May 6, 2026, 10:21pm UTC](https://community.frame.work/t/framework-laptop-16-ryzen-7040-bios-4-04-release-stable/81740/24 "2026-05-06T22:21:24Z")
Framework is already aware of this issue, and has claimed to have “solved” it since at least 3 updates. Triggering it is quite easy, although probabilistic, so maybe you’d have to adjust the timings. A reliable procedure is as follow (note that you need a dGPU plugged and in D3 mode for this to happen): - Plug the laptop; wait (at least) 5 seconds. - Put the laptop to sleep (s2idle), e.g. with `systemctl suspend` - Wait exactly 2 seconds immediately after the previous command was entered. - Unplug the power cable. - Wait exactly 2 seconds. - Wake the computer by pressing a key on the keyboard. - And voilà, we get 544-545MHz on all cores, with SPPT\_APU as the throttling reason (which is nonense given the various thresholds). The only way out of this state without rebooting is power cycling the dGPU (any adjustment using either the RMI or the PSMU/MP1 interfaces has no effect (from what i can tell at least)): ```auto # echo on > /sys/bus/pci/devices/0000\:03\:00.0/power/control # echo auto > /sys/bus/pci/devices/0000\:03\:00.0/power/control ``` ---
**Author:** ![James3](https://avatars.discourse-cdn.com/v4/letter/j/b5e925/32.png) [@James3](https://community.frame.work/u/James3)\ **Post date:** [May 6, 2026, 10:32pm UTC](https://community.frame.work/t/framework-laptop-16-ryzen-7040-bios-4-04-release-stable/81740/25 "2026-05-06T22:32:22Z")
Hi, I do not have a dGPU, so I cannot reproduce it. Maybe this info might help you. > > > \## Device Information > > \### System Model or SKU > > Please select one of the followi…ng > > \- \[x\] Framework Laptop 16 (AMD Ryzen™ 7040 Series) > > \### BIOS VERSION > Framework Laptop 16 Ryzen 7040 BIOS 4.03 Release BETA > Linux: > dmidecode --string bios-version > 04.03 > > \### DIY Edition information > If you are experiencing an issue on a DIY system, Please also fill out the memory and storage devices you are using. > > Memory: F5-5600S4040A32G > G.SKILL Ripjaws DDR5 SO-DIMM Series DDR5 SO-DIMM Memory Kit, Model: F5-5600S4040A32GX2-RS > 64GB total capacity kit containing 2x32GB modules, rated for up to DDR5-5600 CL40-40-40-89 at 1.10V > > Storage: S6B0NU0W434824E, A7SIB34602WR3Z > /dev/nvme0n1 /dev/ng0n1 S6B0NU0W434824E Samsung SSD 980 PRO 2TB 0x1 1.97 TB / 2.00 TB 512 B + 0 B 5B2QGXA7 > /dev/nvme1n1 /dev/ng1n1 A7SIB34602WR3Z Corsair MP600 CORE MINI 0x1 2.00 TB / 2.00 TB 4 KiB + 0 B ELFMC1.0 > > \### Standalone Operation > Are you running your mainboard as a standalone device. Is standalone mode enabled in the BIOS? > \- \[\] Yes > \- \[x\] No > > \## Describe the bug > With official 180W power connected and dGPU still sleeping, running a CPU stress on all 16 cores throttles to 35W (45W with 240W PSU), temp only hitting about a max 74C. > > \## Steps To Reproduce > Steps to reproduce the behavior: > 1. Ensure dGPU is in "D3cold" mode (sleeping), and FW 180w PSU is connected. > 2. Start s-tui and set it to stress mode (or start separate stress tool). > Note: Package power is limited to 35w. > > Further testing: > 3. Wake up the dGPU (Launch "DRI\_PRIME=1 glxgears", for example). > Note: CPU is now allowed full power and will go to thermal throttling as expected. > 4. close s-tui and glxgears, wait for dGPU to enter sleep (D3cold) > 5. Then re-launch s-tui and stress. > Note: See the package power is limited back down to 35w. > > \## Expected behavior > CPU should ALWAYS be given the max power allowed by the internal battery and/or the connected AC supply. Full power never happens on BIOS 4.x while the dGPU is turned off. Problem also exists with different wattage PSU, 100w, 140w, etc, but is limited to even lower watts such as 10w or 20w. Linux has the "performance" profile set for every test so there should be no throttling below the max power the hardware can support. This is a serious bug that is limiting the performance we paid for. > > \## Screenshots > > \Image > > \Image > > \## Operating System (please complete the following information): > - OS/Distribution: Linux/Fedora 43 > - Version: 43 > \- Linux Kernel Version: 6.17.9-300.fc43.x86\_64 > > \## Additional context > This has been a bug in a few versions of the BIOS. At least all the 4.x versions have had this bug. If you are using Linux, from that item, try: `sudo echo '\_SB.ALIB 0x0c {0x07,0x00,0x23,0x00,0x3a,0x00,0x00}' >/proc/acpi/call` Summary: When the dGPU goes to sleep, the temp threshold is accidentally set to 0 C. So on wakeup, it thinks the dGPU is overheating, and backs everything off. That echo command sets the threshold back to a normal value. ---
**Author:** ![Guillaume\_C](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/guillaume_c/32/39715_2.png) [@Guillaume\_C](https://community.frame.work/u/Guillaume_C)\ **Post date:** [May 6, 2026, 10:50pm UTC](https://community.frame.work/t/framework-laptop-16-ryzen-7040-bios-4-04-release-stable/81740/26 "2026-05-06T22:50:56Z")
I’m actually the guy who wrote the quoted post 👀 The 545MHz issue is a different one, it is not solved by the command i mentioned in the post. ---
**Author:** ![James3](https://avatars.discourse-cdn.com/v4/letter/j/b5e925/32.png) [@James3](https://community.frame.work/u/James3)\ **Post date:** [May 6, 2026, 11:31pm UTC](https://community.frame.work/t/framework-laptop-16-ryzen-7040-bios-4-04-release-stable/81740/27 "2026-05-06T23:31:25Z")
What about if one also takes into account this: > [@How to compile the FW16 EC from open source code](https://community.frame.work/t/how-to-compile-the-fw16-ec-from-open-source-code/82342/2): > > Well, I have tracked down and fixed another EC bug. It was a really difficult one to track down. The EC i2c\_transfer() transactions were unreliable. This resulting in, for example, UCSI PPM\_RESET failing and other odd behavior. Its a guess, but it might also be causing some of the stuck in 544 Mhz problems. The reason it was so difficult to track down is because some transactions worked and some did not. They just silently fail. No indication of failed transaction. The problematic ones w… Summary: The EC might fail to send the PMF SPL, sPPT, fPPT, p3T, ao\_sppt settings to the APU/CPU. In your analysis, are you able to read the current PMF settings from the APU/CPU side? e.g. `ryzenadj` On BIOS 4.0.4 The EC console setting of SPL, sPPT, fPPT do not actually match the ryzenadj output. sPPT, fPPT match, but the ryzenadj view of STAPM LIMIT is about 5000mW above the EC PMF SPL one. I don’t know what is adjusting the SPL up above what the EC console outputs. In BIOS 3.0.5, STAPM from ryzenadj matches the EC SPL console output. ---
**Author:** ![Guillaume\_C](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/guillaume_c/32/39715_2.png) [@Guillaume\_C](https://community.frame.work/u/Guillaume_C)\ **Post date:** [May 7, 2026, 1:07am UTC](https://community.frame.work/t/framework-laptop-16-ryzen-7040-bios-4-04-release-stable/81740/28 "2026-05-07T01:07:11Z")
It’s because the settings programmed via the different interfaces are handled by a common endpoint: the AMD SMU. The AMD SMU (or at least its latest version) seems to ignore SPL changes sent via the I2C RMI interface that the EC uses. In fact, this interface is extremely limited in the ways it can directly influence the SMU behavior. On the other hand, the direct PCI access to the PSMU/MP1 that ryzenadj uses (via ryzen\_smu), and that are also used by an ACPI ALIB callback in response to some EC events, allows to dump/edit the real current PM table values used by the SMU. ---
**Author:** ![jared\_kidd](https://avatars.discourse-cdn.com/v4/letter/j/91b2a8/32.png) [@jared\_kidd](https://community.frame.work/u/jared_kidd)\ **Post date:** [May 7, 2026, 3:29am UTC](https://community.frame.work/t/framework-laptop-16-ryzen-7040-bios-4-04-release-stable/81740/29 "2026-05-07T03:29:20Z")
I tried several times to reproduce this following your steps, but I was unable to. I even disabled my LED matrix monitoring software just in case it was interfering with the power states. dGPU in D3cold, using the framework 240w psu. In all this testing, I was actually able to get it ino the 545MHz mode once while I kept the dGPU awake using glxgears though…but it came right out of that mode as soon as I reconnected the power cable. ---
**Author:** ![James3](https://avatars.discourse-cdn.com/v4/letter/j/b5e925/32.png) [@James3](https://community.frame.work/u/James3)\ **Post date:** [May 7, 2026, 7:45am UTC](https://community.frame.work/t/framework-laptop-16-ryzen-7040-bios-4-04-release-stable/81740/30 "2026-05-07T07:45:34Z")
Where is the “APU SMU” logic stored? If you know please point me to it. Is it the a particular ACPI table or is it an AMD binary blob. I have access to advanced reverse engineering tools, so if it is an AMD binary blob, i can reverse it, and at least maybe document the logic it is currently using. Another aspect, do we know all the input parameters that the logic uses to make it decisions. I.e. which PMF, watt, temp, prochot gpios it uses as input, power mode, pmf tables. If we get all the input values, and the SMU logic, we should be able to track the bug down. ---
**Author:** ![Guillaume\_C](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/guillaume_c/32/39715_2.png) [@Guillaume\_C](https://community.frame.work/u/Guillaume_C)\ **Post date:** [May 7, 2026, 8:08am UTC](https://community.frame.work/t/framework-laptop-16-ryzen-7040-bios-4-04-release-stable/81740/31 "2026-05-07T08:08:02Z")
Well, due to its probabilistic nature it’s possible that subtle setup variations affect the steps that can trigger it… ---
**Author:** ![Guillaume\_C](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/guillaume_c/32/39715_2.png) [@Guillaume\_C](https://community.frame.work/u/Guillaume_C)\ **Post date:** [May 7, 2026, 8:08am UTC](https://community.frame.work/t/framework-laptop-16-ryzen-7040-bios-4-04-release-stable/81740/32 "2026-05-07T08:08:38Z")
It’s inside the AMD AGESA firmware. ---
**Author:** ![James3](https://avatars.discourse-cdn.com/v4/letter/j/b5e925/32.png) [@James3](https://community.frame.work/u/James3)\ **Post date:** [May 9, 2026, 9:40am UTC](https://community.frame.work/t/framework-laptop-16-ryzen-7040-bios-4-04-release-stable/81740/33 "2026-05-09T09:40:28Z")
I have found that some of the PMF settings are read only from the cpu side. But work from the EC-\>SMU I2C interface. I should also mention that i recently found a bug in the EC I2C source code that caused some of the settings from the EC to SMU to simply not get through. The bug was causing i2c writes being silently lost. I have fixed the bugs in my EC code. The current EC code only adjusts watts limits of the SMU. I don’t think it adjusts temp limits. ---
**Author:** ![jared\_kidd](https://avatars.discourse-cdn.com/v4/letter/j/91b2a8/32.png) [@jared\_kidd](https://community.frame.work/u/jared_kidd)\ **Post date:** [May 19, 2026, 3:50pm UTC](https://community.frame.work/t/framework-laptop-16-ryzen-7040-bios-4-04-release-stable/81740/34 "2026-05-19T15:50:59Z")
I have noticed the 544mhz throttle will pretty reliably occur if the laptop is simply left on for a couple days connected to the 240w psu in my case. Can anyone else confirm this issue? I know it’s a laptop and leaving it on without sleep for long times is not a common use case. But in my case, I just have it connected to the PSU and HDMI out, that’s it. After a day or two, it will end up in the locked 544mhz throttle. ---
**Author:** ![TechPriestNhyk](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/techpriestnhyk/32/27853_2.png) [@TechPriestNhyk](https://community.frame.work/u/TechPriestNhyk)\ **Post date:** [May 19, 2026, 3:52pm UTC](https://community.frame.work/t/framework-laptop-16-ryzen-7040-bios-4-04-release-stable/81740/35 "2026-05-19T15:52:25Z")
Yeah, that happens to me. I got around it by not leaving it on. Not ideal, but it’s mitigated the issue for me. I’m personally not interested in spending my own time troubleshooting this particular issue. ---
**Author:** ![Guillaume\_C](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/guillaume_c/32/39715_2.png) [@Guillaume\_C](https://community.frame.work/u/Guillaume_C)\ **Post date:** [May 20, 2026, 7:56pm UTC](https://community.frame.work/t/framework-laptop-16-ryzen-7040-bios-4-04-release-stable/81740/36 "2026-05-20T19:56:58Z")
Yes, it happens quite often. I’m still trying to track it down, but the fact that it happens randomly (and especially when i cannot work on it) really does not help. @TechPriestNhyk FYI if you have a dGPU, you can recover from this state by toggling the dGPU on/off, e.g. `# echo on > /sys/bus/pci/devices/0000\:03\:00.0/power/control` `# echo auto > /sys/bus/pci/devices/0000\:03\:00.0/power/control` It’s still very annoying tho. ---
**Author:** ![TechPriestNhyk](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/techpriestnhyk/32/27853_2.png) [@TechPriestNhyk](https://community.frame.work/u/TechPriestNhyk)\ **Post date:** [May 20, 2026, 8:29pm UTC](https://community.frame.work/t/framework-laptop-16-ryzen-7040-bios-4-04-release-stable/81740/37 "2026-05-20T20:29:56Z")
Well, that could be more convenient than a reboot. Thanks for sharing! ---
**Author:** ![Guillaume\_C](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/guillaume_c/32/39715_2.png) [@Guillaume\_C](https://community.frame.work/u/Guillaume_C)\ **Post date:** [May 20, 2026, 11:15pm UTC](https://community.frame.work/t/framework-laptop-16-ryzen-7040-bios-4-04-release-stable/81740/38 "2026-05-20T23:15:31Z")
Well, i already have more info, and a repro for the 545(/544)MHz bug. It seems to be due to a race condition between consecutive calls of `\_SB_.PCI0.GPP0.M241(1)`, the matching EC PMF handler, and `\_SB_.PCI0.GPP0.M241(0)`. The easiest way to trigger it is: `# echo '\_SB_.PCI0.GPP0.M241 0x01' >/proc/acpi/call; cat /proc/acpi/call; sleep 0.1; echo '\_SB_.PCI0.GPP0.M241 0x00' >/proc/acpi/call; cat /proc/acpi/call` It still is probabilistic, so it won’t always happen (and also sometimes it locks the freq to 1400 MHz instead), but it happens roughly 60% of the time, which is a great step towards identifying the underlying cause. ---
**Author:** ![jared\_kidd](https://avatars.discourse-cdn.com/v4/letter/j/91b2a8/32.png) [@jared\_kidd](https://community.frame.work/u/jared_kidd)\ **Post date:** [May 20, 2026, 11:17pm UTC](https://community.frame.work/t/framework-laptop-16-ryzen-7040-bios-4-04-release-stable/81740/39 "2026-05-20T23:17:45Z")
> [@Guillaume\_C](#): > > /proc/acpi/call Interesting. How do you get /proc/acpi/call? It’s not on my system. ---
**Author:** ![Guillaume\_C](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/guillaume_c/32/39715_2.png) [@Guillaume\_C](https://community.frame.work/u/Guillaume_C)\ **Post date:** [May 20, 2026, 11:20pm UTC](https://community.frame.work/t/framework-laptop-16-ryzen-7040-bios-4-04-release-stable/81740/40 "2026-05-20T23:20:25Z")
`sudo modprobe acpi_call`, but you need to install it first, as it’s not an in-tree module. On archlinux it is available as the acpi\_call package (or acpi\_call-dkms), on debian derivatives as acpi-call-dkms, … [Previous page](https://community.frame.work/t/framework-laptop-16-ryzen-7040-bios-4-04-release-stable/81740.md?page=1) [Next page](https://community.frame.work/t/framework-laptop-16-ryzen-7040-bios-4-04-release-stable/81740.md?page=3)