Framework Laptop 16 Ryzen 7040 BIOS 3.06 Release BETA -Held

Framework Laptop 16
,
41

it seems like putting it to sleep with the cable attached is what triggers the CPU to enter this low power state. But reapplying the BIOS after downgrading to 3.0.5 and then upgrading seems to have resolved the battery charge state…. maybe.

EDIT: Setting amdgpu.runpm=0 seems to prevent this from happening. I’ll keep monitoring this.

42

For those interested what EC device introduction means, these are Linux kernel boot logs from before and after upgrade accordingly:

Aug 08 09:53:28 fw16 kernel: cros_ec_lpcs cros_ec_lpcs.0: Chrome EC device registered
Aug 09 11:21:12 fw16 kernel: cros_ec_lpcs FRMWC004:00: Chrome EC device registered

It seems that it all boils down to a ACPI entry, functionality wise there’s likely no difference:

    Scope (_SB)
    {       
        Device (CREC)
        {       
            Name (_HID, "FRMWC004")  // _HID: Hardware ID
            Name (_UID, One)  // _UID: Unique ID
            Name (_DDN, "EC Command Device")  // _DDN: DOS Device Name
            Method (_STA, 0, NotSerialized)  // _STA: Status
            {           
                Return (0x0F)
            }               
        }                   
    }
2 Likes
43

I think I’m just going to downgrade back to 3.05 as this beta is very broken. My laptop is again stuck in the 500MHz after simply sleeping it since last night. I was using the official 180W PSU all evening, then disconnected it to be on battery for about an hour, then closed the lid to sleep. Open it the following morning and stuck in 500MHz,

While on 3.05 I could reliably trigger the 500MHz with one of my chargers and could therefor avoid it, this 3.06 beta will trigger from everything and all the time, even on battery apparently.

Plus the removal of being able to set the battery charge level on the fly (from the OS) is a huge reduction in usability.

I don’t see how this made it past alpha or any qa testing.

1 Like
44

You can still set the battery charge limit via the framework tool ( linux ).

$ sudo framework_tool --driver cros-ec --charge-limit 80

45

Thank you, that does work. I didn’t realize that tool had battery options. Shame the /sys stuff is gone though.

46

As far as I remember/understood, the sysfs entries are not gone forever, rather that when the functionality of croc module was added to the kernel, they had to black list framework specifically because their charging logic was too different from stock chromeEC. You can see it reported during boot in dmesg.

I think DHowett’s kmod still exposes sysfs option if you really need it.

1 Like
47

Have you tried a bios reset?

Since doing that, I have not had the 500mhz issue happen at all

48

Yes. I did that as explained in my first post in this thread.

49

Thats not quite what I meant.

I mean:

  1. Take off the input cover
  2. Push down the “intrusion detection” switch for 2 seconds
  3. Repeat step 2 10 times
  4. Boot into bios, make changes that are needed

Not sure if itll help you, just sharing what I did.

50

What you are describing is a motherboard reset. I’ll give that a try if it worked for you and report back.

Thanks.

1 Like
51

I wish that FW would update the github with the latest EC source code changes here:

2 Likes
52

Are you sure it doesn’t have all the changes? I see the 5% float range being implemented in the commit from Feb 18th.

if (old_charger_limit != charging_maximum_level) {
		old_charger_limit = charging_maximum_level;
		battery_sustainer_set(MAX(20, (charging_maximum_level - 5)),
			MAX(20, charging_maximum_level));
	}
1 Like
53

Reporting back that I did the motherboard reset and it did not fix the 500MHz issue. Slept my laptop and upon waking it, 500MHz bug. I think sleeping the laptop causes this issue 100% of the time with this bios version.

54

Can you provide more details about the issue? Does it only happen when the system resumes from sleep? What Linux distribution and kernel version are you using?

55

have you seen this thread Clock speeds limited to ~500 MHz ?

1 Like
56

If I’ll do a motherboard reset, will it clear the TPM or affect my ability to boot thd existing Windows install that has SecureBoot enabled?

57

I can’t say for TPM yet as I’ve not used that but UEFI secureboot keys, they remain after reset

1 Like
58

I’d take a pic of the key to BitLocker to be on the safe side if I were you. It should also be backed up to your MS account as well.

1 Like
59

When FW customer service had me try everything under the sun (including mb reset) for the cpu throttle issues I was still able to boot into OS Win11 secure boot without having to utilize bitlocker code. However, your mileage may vary. To be on the safe side, I would still get your key from your MS account just in case.

1 Like
60

Happens for me when I plug in the laptop when I’m booted up it throttles to 500mHz, same thing vice versa if I booted unplugged then plugged in the laptop it will also throttle, sometimes when sleeping too, etc, didn’t happen for me in previous versions.

1 Like