Cpufreq drivers not working on T480S

User Support Hardware Issues
21

So an update to this, I put in a issue on the Heads git: T480S Heads firmware lack ACPI P-state tables. · Issue #2120 · linuxboot/heads · GitHub then rebuilt Heads pulling that fix:

git clone https://github.com/linuxboot/heads
cd heads
./docker_repro.sh make BOARD=EOL_t480s-maximized
cd build/x86/coreboot-25.09/
git fetch https://review.coreboot.org/coreboot refs/changes/73/91173/2 && git format-patch -1 --stdout FETCH_HEAD > ../../../patches/coreboot-25.09/0013-sklkbl_thinkpad-Enable_ACPI_P-state_table_generation.patch
cd ~/heads
./docker_repro.sh make BOARD=EOL_t480s-maximized real.remove_canary_files-extract_patch_rebuild_what_changed
./docker_repro.sh make BOARD=EOL_t480s-maximized
[...]
INFO: Applying patch file: patches/coreboot-25.09/0013-sklkbl_thinkpad-Enable_ACPI_P-state_table_generation.patch
Checking patch build/x86/coreboot-25.09/src/mainboard/lenovo/sklkbl_thinkpad/devicetree.cb...
Applied patch build/x86/coreboot-25.09/src/mainboard/lenovo/sklkbl_thinkpad/devicetree.cb cleanly.

I made sure that those messages came up during the build, But… Sadly that has not fixed the cpu_freq issue. My next step would be to compile Coreboot / Seabios with this fix to see if that works (Heads overall is using an older Coreboot version 25.09 so it could be dependent on something else that I didn’t pull). @fb2043 did you ever get that to work?

This does seem to be a Qubes problem, as OP said, other OS’s run fine.

22

Sadly by the time the corebot 91173 patch was posted, my T480s died, so I never got the chance to test it.

I agree that compiling a recent coreboot would be a good idea. I would also suggest checking whether in your heads firmware the info is in the ACPI tables using the instructions in Cpufreq drivers not working on T480S - #10 by fb2043

FWIW I don’t think it’s accurate to call it a qubesOS issue. As explained in Cpufreq drivers not working on T480S - #12 by fb2043 it’s due to Xen itself lacking drivers for native frequency scaling (unlike e.g the linux kernel).

23

Thanks for you feedback, sorry to hear your laptop died. :disappointed_relieved: Yes, agreed , its all 3: Xen / Qubes / Coreboot, and as you said, other OS’s seemed to work fine. So I don’t know really if the fix lies in coreboot or a Xen driver issue as of yet. Its a real shame as you said because this could be a really great Qubes machine. When I get a moment to go through the long coreboot build process and reflash I will still nevertheless post here, as I think most people who have this particular issue would be looking here first.
Oh ps. Mods, This subject should be linked to the HCL

24

Imo xen is unlikely to get a driver. Xen devs have helped to troubleshoot and identify the problem. However they didn’t offer to mitigate it on their end. My guess is that it would fall outside the scope of a microkernel.

The bottom line is that Xen needs the info to be in the ACPI tables. That means it must be provided by the firmware (i.e coreboot).

25

An update.
I have found that that Pr on git actually worked :grinning:
It was not showing the states when I followed the initial bug but when I tried
sudo xenpm get-cpufreq-para
I can now see

base [2100000] max [4200000]
scaling_driver: hwp
turbo mode : enabled

I cannot understand why but last time I checked it was stuck at base.

26

So you’re saying that https://review.coreboot.org/c/coreboot/+/91173
only fixes the issue of xenpm not showing anything at all, but leaves
the actual issue of the CPU frequency not being regulated?