Framework Laptop 13 Ryzen 7040 BIOS 3.09 Release

Framework Laptop 13
,
124

I also have the issue that ryzenadj reports only nans on many of the sensors that were available on 3.0.5. This stopped working right after installing 3.0.7. Setting --fast-limit for example does still work (didn’t test others).

Example output of ryzenadj -i just now:

CPU Family: Phoenix Point
SMU BIOS Interface Version: 15
Version: v0.16.0 
PM Table Version: 4c0009
|        Name         |   Value   |     Parameter      |
|---------------------|-----------|--------------------|
| STAPM LIMIT         |    30.000 | stapm-limit        |
| STAPM VALUE         |     3.740 |                    |
| PPT LIMIT FAST      |    30.000 | fast-limit         |
| PPT VALUE FAST      |     9.609 |                    |
| PPT LIMIT SLOW      |    25.000 | slow-limit         |
| PPT VALUE SLOW      |     3.808 |                    |
| StapmTimeConst      |       nan | stapm-time         |
| SlowPPTTimeConst    |       nan | slow-time          |
| PPT LIMIT APU       |       nan | apu-slow-limit     |
| PPT VALUE APU       |       nan |                    |
| TDC LIMIT VDD       |       nan | vrm-current        |
| TDC VALUE VDD       |       nan |                    |
| TDC LIMIT SOC       |       nan | vrmsoc-current     |
| TDC VALUE SOC       |       nan |                    |
| EDC LIMIT VDD       |       nan | vrmmax-current     |
| EDC VALUE VDD       |       nan |                    |
| EDC LIMIT SOC       |       nan | vrmsocmax-current  |
| EDC VALUE SOC       |       nan |                    |
| THM LIMIT CORE      |       nan | tctl-temp          |
| THM VALUE CORE      |       nan |                    |
| STT LIMIT APU       |       nan | apu-skin-temp      |
| STT VALUE APU       |       nan |                    |
| STT LIMIT dGPU      |       nan | dgpu-skin-temp     |
| STT VALUE dGPU      |       nan |                    |
| CCLK Boost SETPOINT |       nan | power-saving /     |
| CCLK BUSY VALUE     |       nan | max-performance    |

FW13 AMD 7840
Opensuse Tumbleweed
Kernel 6.14.6

Here is an old example of the output:

CPU Family: Phoenix Point
SMU BIOS Interface Version: 14
Version: v0.15.0 
PM Table Version: 4c0008
|        Name         |   Value   |     Parameter      |
|---------------------|-----------|--------------------|
| STAPM LIMIT         |    53.000 | stapm-limit        |
| STAPM VALUE         |    11.126 |                    |
| PPT LIMIT FAST      |    53.000 | fast-limit         |
| PPT VALUE FAST      |    11.977 |                    |
| PPT LIMIT SLOW      |    35.000 | slow-limit         |
| PPT VALUE SLOW      |    11.071 |                    |
| StapmTimeConst      |     0.000 | stapm-time         |
| SlowPPTTimeConst    |     0.000 | slow-time          |
| PPT LIMIT APU       |    41.000 | apu-slow-limit     |
| PPT VALUE APU       |       nan |                    |
| TDC LIMIT VDD       |    54.000 | vrm-current        |
| TDC VALUE VDD       |     7.850 |                    |
| TDC LIMIT SOC       |    16.000 | vrmsoc-current     |
| TDC VALUE SOC       |     2.645 |                    |
| EDC LIMIT VDD       |   105.000 | vrmmax-current     |
| EDC VALUE VDD       |    16.980 |                    |
| EDC LIMIT SOC       |    23.000 | vrmsocmax-current  |
| EDC VALUE SOC       |     4.661 |                    |
| THM LIMIT CORE      |   100.000 | tctl-temp          |
| THM VALUE CORE      |    48.840 |                    |
| STT LIMIT APU       |    43.500 | apu-skin-temp      |
| STT VALUE APU       |    38.807 |                    |
| STT LIMIT dGPU      |     0.000 | dgpu-skin-temp     |
| STT VALUE dGPU      |     0.000 |                    |
| CCLK Boost SETPOINT |       nan | power-saving /     |
| CCLK BUSY VALUE     |       nan | max-performance    |

EDIT:

Just tested setting --apu-skin-temp, and it seems to work. At least ryzenadj reports success and I can see the value at register | 0x0058 | 0x42480000 | change to the value I set, when looking at the output of --dump-table. I didn’t stress the machine to see if functionally there was an effect. Weird that the value is not reported by ryzenadj -i, though.

125

I saw that there was a new commit to the ryzenadj repo - something about support for the 7840U. If you’re on v0.16.0 you won’t be using it, you would need to build it from source. Not sure if that’s relevant to the issue you’re facing.

Here

126

The values of --dump-table and -i are the same, but shown in a different way. The -i has a bug and therefore does show only the first 6 values of the --dump-table. You can get all offsets and its meanings from the code here:

Look for the get_ functions and the 0x004C0009 table versions. Example offsets for dump-table:

stapm_limit 0x0000
stapm_value 0x0004
fast_limit 0x0008
fast_value 0x000C
slow_limit 0x0010
slow_value 0x0014
apu_slow_limit 0x0018
apu_slow_value 0x001C
tctl_temp 0x0040
tctl_temp_value 0x0044
apu_skin_temp_limit 0x0058
apu_skin_temp_value 0x005C

1 Like
127

Thanks for the info! So if I understand correctly, the fact that the bug in ryzenadj appeared at the same instance as the firmware update on my machine is a coincidence. Or did the update trigger the bug which was there before? Anyway, if it’s a known issue I guess that will be sorted out in due course, so that’s good to know.

128

It might be the new version of ryzenadj where this bug was introduced, your old working output is with version 0.15, the new not working is with version 0.16. You could give version 0.15 a try to see if this fixes it.

129

The old output of ryzenadj I posted above was very old - it’s just that this was the only saved output of the command I could find on my machine. I just checked, the output of v0.15.0 is identical to v0.16.0 (missing values on my new BIOS version), so the BIOS update changed something. And it’s fixed in the latest git of RyzenAdj (see below). I think the reason for the difference is here:

PM Table Version: 4c0009

This used to be 4c0008 before the BIOS update. Output of ryzenadj compiled from the current git:

CPU Family: Phoenix Point
SMU BIOS Interface Version: 15
Version: v0.16.0 
PM Table Version: 4c0009
|        Name         |   Value   |     Parameter      |
|---------------------|-----------|--------------------|
| STAPM LIMIT         |    53.000 | stapm-limit        |
| STAPM VALUE         |    11.529 |                    |
| PPT LIMIT FAST      |    53.000 | fast-limit         |
| PPT VALUE FAST      |    29.747 |                    |
| PPT LIMIT SLOW      |    35.000 | slow-limit         |
| PPT VALUE SLOW      |     9.885 |                    |
| StapmTimeConst      |    68.640 | stapm-time         |
| SlowPPTTimeConst    |    32.230 | slow-time          |
| PPT LIMIT APU       |    41.000 | apu-slow-limit     |
| PPT VALUE APU       |     0.000 |                    |
| TDC LIMIT VDD       |    54.000 | vrm-current        |
| TDC VALUE VDD       |    10.828 |                    |
| TDC LIMIT SOC       |    16.000 | vrmsoc-current     |
| TDC VALUE SOC       |     2.580 |                    |
| EDC LIMIT VDD       |   105.000 | vrmmax-current     |
| EDC VALUE VDD       |   105.000 |                    |
| EDC LIMIT SOC       |    23.000 | vrmsocmax-current  |
| EDC VALUE SOC       |     4.679 |                    |
| THM LIMIT CORE      |   100.000 | tctl-temp          |
| THM VALUE CORE      |    62.243 |                    |
| STT LIMIT APU       |    43.500 | apu-skin-temp      |
| STT VALUE APU       |    38.703 |                    |
| STT LIMIT dGPU      |     0.000 | dgpu-skin-temp     |
| STT VALUE dGPU      |     0.000 |                    |
| CCLK Boost SETPOINT |       nan | power-saving /     |
| CCLK BUSY VALUE     |       nan | max-performance    |
1 Like
130

Looks like there are multiple 0.16 versions around, one broken, one working. And indeed, the first 6 values of dump table have no PM table version check.

131

The release 16 version got nans, get git main “16” version doesn’t.

132

Are you sure this fan behaviour is a regression from 3.09? I posted about a year ago about the slow ramp up time of the fan and your graphs in the GitHub issue look very similar to what I observed. There was also a response by Kieran that shed a bit more light into the issue, which appears to stem from where the driving thermal sensors is, and hinted towards a potential workaround coming up as a backport from the FW16 (not sure how far this has progressed).

I upgraded from 3.05 to 3.09 a couple of weeks back and have had no issues or observed any regression so far, incl. fan behaviour.

133

The original incident that made me open the bug report seemed more “serious” (much more delay), but I wasn’t recording temperatures that time. I’ll do so next time I run a large workload like a kernel build.

But you’re right, your curves and Kieran’s explanation suggest this may not be new.

134

Been running 3.09 since they marked it as stable and I haven’t run into any issues with it yet. Thanks Framework for persevering through that difficult development process.

4 Likes
135

Question: Have folks noticed a change in the frequency of usci_acpi errors? This has been an issue for me for months, but it does not seem to affect the functionality so I haven’t really looked into it. I am curious if anyone has noticed an improvement with 3.09 on their machine, or if they still show up in dmesg when plugging/unplugging peripherals.

1 Like
136

Mine have gone, but also a) I changed my USB-A to an SD card reader recently, b) the amount of these errors I get wildly vacillates between kernel versions. At one point I was getting four of them. So I have no real idea why it is how it is.

137

Today, what happens if you plug in a charger, or a HDMI monitor? Do you see the errors?

138

Ah, yes I do. Charging specifically (don’t have HDMI adapter). I guess I’ve been restarting it off battery more recently, which is why I stopped noticing.

1 Like
139

Upgrading my firmware resets gaming mode back to “auto”. If I set it to gaming again, I get 8 GB of VRAM instead of the documented 4 GB. (Not complaining, more is better. But the docs in the BIOS are wrong). An update shouldn’t change that BIOS setting.

2 Likes
140

I have been running 3.09 since it came out to get off 3.07.

I have the charge limit set to 90% in BIOS & battery extender enabled.

Running on the framework charger, my battery charges to 90% as expected, and holds at that point.

I have re-read the feature description a couple of times, and I think the expected behaviour is to see float feature cause the battery drop down under load to 85% while on AC before charging is engaged.

I expect not to see the the charge state change from off to on in upower until 85% is hit.

Is this correct?

It would be super helpful if framework published some test procedures on these BIOS features to give the community testers some idea of what the method of procedure & expected results should be.

Anyway, after reaching 90% charge, starting stress & upower, what I observe is the upower history reporting the charge state toggling on & off. (Also noticed the fan delay issue while the CPU hits 100C). I also observe that the charge level never goes below 90%.

So, is this the correct behaviour or not?

1 Like
141

Sorry not a reply to your question, but I would like to add to your comment.

I have tried very hard to follow the thread and understand what the proper behavior of the new BIOS should be but, I’m kinda lost.

Also looking forward for some step by step instructions, on how I can test if the new settings are working correctly.

Does something like this hold true?

  1. In Bios, charge limit set to 90% and battery extender enabled.
  2. Plug the charger on and wait until laptop charges.
  3. It should reach 90% charge and stop there.
  4. While still connected to the charger, run prime95 (or something to stress the system)
  5. The battery should start droping
  6. Once charge reaches 85%, it should start charging again.
  7. Depending on your charger, and if it can produce more juice that what prime95 consumes, eventually the laptop should charge to 90% again
  8. It should start discharging again down to 85%
  9. Loops between 85 and 90 until you stop the test.

EDIT: I Have not run this yet, but is this what I would expect to get?

Does something like this describe an accurate list of events on 3.09 Bios?

Thanks

142

A possible explanation is that your charger is powerful, you can use an underpowered charger, stress test it and watch the % drop. Then stop stressing, the charge % should remain the same as long as it’s higher than 5% below the charge limit

143

@Stratos_Gerakakis yes, that is my understanding as well. Well stated, thank you. I don’t know if my understanding is correct.

@Charlie_6 thanks for all your excellent posts. I was using the 60W framework power adapter. I’ll give it a try with a lesser charger and report back.

But should I see upower report the charging flip on and off for brief periods with a 60W charger? This is what I don’t understand about the expected behaviour of the feature.