AMD Ryzen 7040 Series BIOS 3.03 and Driver Bundle Release

[Alessandro_Renzi]

@SuperTux88

I have a similar problem, when I close the lid while it’s still connected to the charger and it goes to suspend, and I then unplug the charger, it then also wakes up again (I can also see the screen light turning on through a thin gap). It’s only the charger connected and then unplugged, not a dock.

I’m still on the old BIOS, and I can also reproduce your wake-on-close problem there, so that’s both nothing really related to the new BIOS version (I assume that the wake-on-unplug also still happens with the new BIOS?). But both shouldn’t happen, the laptop shouldn’t wake up when closed.

Noticed this today too on ubuntu22.04 oem kernel.
(also,resuming from suspend lead to a white screen, no way to recover from it, only the cursor is visible)

[Enzious]

@Enzious

Alright, this one is probably easy to fix, low priority, but driving me crazy.

Closing the lid triggers a wake-up. If you put the computer into suspend and close it on something thin so you can see past the screen gasket… the screen turns on.

The lid close event/signal is waking the computer. I think that’s incorrect behavior. I’ve disabled all ACPI wake-up devices but it’s still doing this, it makes sense that this is probably being handled by the BIOS. No DE/WM, at a plain vt, it’s still doing this behavior.

I think two changes would help here and honestly all machines where Framework is customizing BIOSes:

• Only wake-up on lid open and ignore lid close while suspended (if it’s possible with the BIOS)
• Ability* to disable the lid completely as a wake-up source via BIOS

Please

Alright, status update. It’s an EC bug. I thought I read once that the Framework EC firmware was/would-be open-source? I think the EC should be more configurable.

This fixes the problem but then you can’t wake the PC up again

echo "Y" | sudo tee /sys/module/acpi/parameters/ec_no_wakeup

Disabling everything in /proc/acpi/wakeup doesn’t prevent wakeups, only ec_no_wakeup but that disables everything including the power button

[Matt_Hartley]

We’re getting ready to pull this out of beta, so I need to make sure I have everything straight.

• Those seeing suspend wakeups (as I am not on either of my AMD Ryzen 7040 laptops), what is attached and what was running? On my test machines, lid close is suspend to RAM (on our tested and recommended distributions) and resume takes place on lid open events.

Thanks

[SuperTux88]

@Matt_Hartley

We’re getting ready to pull this out of beta, so I need to make sure I have everything straight.

Any news about the multiple people who reported that the steamdeck charger stopped working with the framework after the update?

@Matt_Hartley

Those seeing suspend wakeups

I don’t think that’s related to the new version, as I already have this problem with the old BIOS.

[Matt_Hartley]

@Enzious

I’m sorry, but just to be clear… you expect that after suspending the laptop while it is open… and then closing the laptop… you expect that the laptop wake itself back up?

Sorry, allow me to be clear.

We expect default behavior for the default config. The default config and the config we test is lid close suspend, lid open resume.

You indicated you changed the default behavior. You changed the behavior to lid close null and are experiencing the new behavior if lid close resume when you have suspended this laptop using the non-default method. Is this not correct?

While I understand this isn’t ideal behavior and certainly not what is intended. The default action and purpose of the lid is to suspend it at this time unless it has been changed. In this case, it has.

Ideally, this would not be the case and it’s certainly valuable feedback on having the ability to disable the lid behavior entirely.

But, at this time, we are focused on default expected out of the box behavior at this time. Not custom tweaks made to HandleLidSwitch=.

Moving on, feedback received and appreciated.

Does anyone have feedback on other issues that they are experiencing?

Overall, for out of the box behavior, this appears to be a significant improvement over 3.02 and we will be releasing this out of beta tomorrow.

[mikeymop]

@Matt_Hartley

Does anyone have feedback on other issues that they are experiencing?

Is the issue with the graphical artifacting on resume resolved in the release version of the firmware?

In the event this was not yet tracked, I was able to capture a dmesg log today, and can share it if it can be of any assistance.

[Zalgo]

Only issue I’ve encountered is suspend seeming to break entirely with the kernel param “nvme.noacpi=1” set. Fedora 39 beta, 64GB DDR5-5600,WD SN850x, kernel version 6.5.8. This isn’t particularly surprising given this kernel option disables a workaround for suspend related to nvme drives, but as far as im aware it worked fine on the intel boards.

[Jonathan_Foucher]

Updating via EFI, it’s been stuck like this for a while now, does that mean it’s done ?

Sorry for the dumb question and thanks for any answer

[Bumblebee]

@Matt_Hartley

We’re getting ready to pull this out of beta, so I need to make sure I have everything straight.

@Matt_Hartley @Kieran_Levin Any feedback on the charging issues with BIOS 3.03? Not only about the Steam Deck Chargers not working at all, but also about showing a battery full LED when the battery isn’t completely charged.

[Chris2]

@Jonathan_Foucher

Updating via EFI, it’s been stuck like this for a while now, does that mean it’s done ?

I had the same issue earlier in the thread, as long as you have the 4 green checkmarks in the bottom right, you can press the power button to turn off. You will want to re-run the BIOS update to properly downgrade the PD firmwares, which didn’t work for me until I used the official Framework charger during the BIOS update.

For some reason, when using my apple charger, the BIOS update would hang at that exact spot.

[Jonathan_Foucher]

Strange though, because I did use the framework charger. Everything seems to be working fine so far anyway. Thanks for the reply

[Matt_Hartley]

While it should charge with compatible chargers, my focus is does it work as expected with Framework chargers with this particular release. It does with Framework chargers.

If there issues with other compatible chargers, feel free to open or add to a thread and we can get this to the engineering team.

[Matt_Hartley]

@Zalgo

Only issue I’ve encountered is suspend seeming to break entirely with the kernel param “nvme.noacpi=1” set. Fedora 39 beta, 64GB DDR5-5600,WD SN850x, kernel version 6.5.8. This isn’t particularly surprising given this kernel option disables a workaround for suspend related to nvme drives, but as far as im aware it worked fine on the intel boards.

Per our guide and per AMD, no, this is not to be used. This is for Intel only.
If it’s set on AMD it’s going to cause major problems for suspend.

[Matt_Hartley]

With the overwhelming benefits seen in upgrading 3.02 to 3.03, I am pleased to announce we are releasing 3.03 as a release and is no longer beta.

Feedback given on this release has been cataloged and passed on.

[Shijikori]

@Matt_Hartley

With the overwhelming benefits seen in upgrading 3.02 to 3.03, I am pleased to announce we are releasing 3.03 as a release and is no longer beta.

Does this mean the current 3.03 is now considered stable or will there be a different release of 3.03 as stable? This is a little ambiguous to me.

[Azure]

@Shijikori

This is a little ambiguous to me.

As with previous BIOS updates that have gone from beta to release, there is no change to the BIOS update file, it will just be linked as release on the BIOS/Drivers page on the support site. If you have already updated to 3.03 you don’t have to do anything else, and you can even recommend others come to this thread to get the installer file (otherwise they can go here: Framework Laptop BIOS and Driver Releases (AMD Ryzen™ 7040 Series) though it seems this page has yet to be updated with the new release as of the writing of this response).

[Andrew_Kahn]

It’s updated.

[Matt_Hartley]

@Shijikori

Does this mean the current 3.03 is now considered stable or will there be a different release of 3.03 as stable? This is a little ambiguous to me.

Correct. Today was the last day of beta. 3.03 is the stable release - we want folks off of 3.02.