# Framework Laptop 16 Ryzen 7040 BIOS 4.03 Release STABLE **URL:** \ **Category:** Framework Laptop 16\ **Tags:** bios-announcement, graphics-module-nvidia-5070, graphics-module-amd-rx7700s, framework-laptop-16-amd-7040\ **Created:** [December 30, 2025, 6:54am UTC](https://community.frame.work/t/framework-laptop-16-ryzen-7040-bios-4-03-release-stable/79274 "2025-12-30T06:54:20Z")\ **Posts on this page:** 4\ **Page:** 6
**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:** [March 24, 2026, 1:36am UTC](https://community.frame.work/t/framework-laptop-16-ryzen-7040-bios-4-03-release-stable/79274/102 "2026-03-24T01:36:21Z")
Laptop was in sleep connected to a charger all day. Just woke it up (so it’s cold), and it’s stuck in throttle status. EDC\_CPU status shows while steam is compiling some shaders and the laptop is pretty sluggish. Pleading again for Framework to finally fix these issues. ![image](https://us1.discourse-cdn.com/flex001/uploads/framework3/original/3X/6/0/601a25b60fab90ffa0a37fe350de0be17baef000.png) ---
**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:** [March 24, 2026, 7:13pm UTC](https://community.frame.work/t/framework-laptop-16-ryzen-7040-bios-4-03-release-stable/79274/103 "2026-03-24T19:13:28Z")
I was able to identify that most issues related to throttling are in fac in partt related to the AMD SMU firmware behaving rather oddly, and i was able to solve some by changing entries in the BIOS AMD CBS setup config (thanks to Smokeless UMAF, that allows access to hidden PBS & CBS config). First, the PROCHOT\_CPU & PROCHOT\_GPU. These flags are not directly tied to the status of the physical prochot pin, but are internally set by the SMU firmware when the prochot pin is asserted during a possible overheating event. During normal use, it happens mostly when the EC transiently (\< 1 second) activates the pin when an external power source is connected or disconnected, for a reason. Then, after the prochot pin is released, the SMU is supposed to clear those flags after a predefined duration, to resume normal operation. Unfortunately, the default delay seems to be set to infinite with the default SMU configuration. This issue is solved by manually setting a delay: Set `[AMD CBS] / [SMU Common Options] / [PROCHOT Control]` to `` (`` by default) Then set `[PROCHOT Deassertion Ramp Time]` that just appeared below to `<1000>` (`<0>` by default). This will set the timeout to 1 seconds (1000 ms), which may be enough. You might find this interesting @jared_kidd ---
**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:** [March 24, 2026, 7:45pm UTC](https://community.frame.work/t/framework-laptop-16-ryzen-7040-bios-4-03-release-stable/79274/104 "2026-03-24T19:45:12Z")
I’m syncing the post with the github issue: [FW16 7040 BIOS 4.03 - CPU power locked at 35W (45W with 240w PSU) max when dGPU is asleep · Issue #146 · FrameworkComputer/SoftwareFirmwareIssueTracker · GitHub](https://github.com/FrameworkComputer/SoftwareFirmwareIssueTracker/issues/146) > ~~I discovered that the AMD SMU completely ignores the EC-adjusted SPL cap by default. It just applies its own caps, that are a lot more conservative.~~ > > ~~To force the SMU to take into account the EC-driven settings:~~ > ~~Set [AMD CBS] / [SMU Common Options] / [STAPM Control] to ( by default)~~ > ~~Then set below:~~ > > - ~~[System Temperature Tracking] to \<0\> (the default). This is mandatory to prevent the SMU from overriding custom SPL values (EC or manual).~~ > > - ~~[STAPM Boost Override] to \<1\> so that changes to [STAPM Boost] will have an effect.~~ > > - ~~[STAPM Boost] to \<0\> (the default). IIRC setting it to \<1\> will allow the CPU to run at 45W anytime (with annoying spurious throttle during power transitions), which is probably not what you want…~~ > > - ~~[Tskin Time Constant (STAPM)] to \<0\> (I don’t remember if changing it makes a difference tho).~~ EDIT: I identified the root cause of this issue. When System Temperature Tracking is enabled, the AMD SMU uses the temperature sensors to dynamically adjust the `STAPM LIMIT` to control power consumption. By default, the sensors count `STT_PCB_SENSOR_COUNT` is set to 3, with the 3rd one attached to the dGPU (if you set `STT_PCB_SENSOR_COUNT` to 2, then the dGPU temp is ignored and the issue disappears). However, when the dGPU is off, the temperature limit for the dGPU skin temperature sensor `STT LIMIT dGPU` is set to 0°C, while the measured value `STT VALUE dGPU` continues to stay at ambient 30-35°C. So the AMD SMU believes that the dGPU is overheating, and reduces the `STAPM LIMIT` accordingly, thus limiting the APU to 35W. When the dGPU turns on, `STT LIMIT dGPU` is set to 51°C, which clears the overheating signal as `STT VALUE dGPU` becomes lower than `STT LIMIT dGPU`, so the AMD SMU is able to rise the `STAPM LIMIT` to reach the rated 54W for the APU. To test if i could replicate it even when the dGPU is off, I first reverted back to default bios settings (to be sure that there were no interference from my specific settings), then i launched a CPU+iGPU stress test and compared the APU power limit/consumption while `STT LIMIT dGPU` is set to the default 0°C VS 51°C via `ryzen_adj`, and the results are pretty clear: `STT LIMIT dGPU == 0°C` =\> 35W /VS/ `STT LIMIT dGPU == 51°C` =\> 54W. Then i wanted to identify which part of the firmware is responsible for controlling the `STT LIMIT dGPU` parameter of the AMD SMU PM table. So i tried to see if the EC was able to alter `STT LIMIT dGPU`, however no AMD PMF command with the current AMD SMU firmware allows the EC to perform this specific operation (and i tested all the possible commands). The next target is the ACPI firmware. Using acpi\_call to call the method `\_SB.PCI0.GP17.VGA.PX02` with a parameter 0/1 to turn the dGPU off/on, results in the `STT LIMIT dGPU` value changing accordingly (e.g. `# echo '\_SB.PCI0.GP17.VGA.PX02 0' >/proc/acpi/call; cat /proc/acpi/call`). So far I’ve been able to track it down to a single method call, nicknamed `KER-ASL-CpmWriteGpio`, which presumably changes a Gpio pin: `# echo '\M010 9 1' >/proc/acpi/call` =\> `STT LIMIT dGPU = 51°C` `# echo '\M010 9 0' >/proc/acpi/call` =\> `STT LIMIT dGPU = 0°C` This write seems to trigger logs in the EC, so maybe there is something else to look for in there… ---
**Author:** ![system](https://us1.discourse-cdn.com/flex001/uploads/framework3/original/1X/64c81a89f963ddb07633887baceb642a4b056046.png) [@system](https://community.frame.work/u/system)\ **Post date:** [September 20, 2026, 7:45pm UTC](https://community.frame.work/t/framework-laptop-16-ryzen-7040-bios-4-03-release-stable/79274/105 "2026-09-20T19:45:20Z")
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed. [Previous page](https://community.frame.work/t/framework-laptop-16-ryzen-7040-bios-4-03-release-stable/79274.md?page=5)