Thank you for the information, Daniel! I will add my experience to the thread once I update.
I did manage to update. Since Iāve upgraded to 3.17 the led lights between the expansion cards have been blinking red, those indicate that the input cover is off the case.Iāve checked that the black foam square is still on the top of the input cover and I donāt think itās moved. Itās hard to tell if itās making contact. Is anyone else having this issue? The laptop is working normally otherwise.
Question :
I have not done any BIOS update since I have my 12th gen system.
My system is very stable under Linux Ubuntu mate 22 LTS.
I am specially wondering if I could potentialy get the infamous ā400mhzā problem after updating ?
The idea of an update is usually to improve the user experience, reading threads make me wonder, if it might not get worse
Updated my 1240 dualboot W11/Mint from 3.09 to 3.17 without any issue. I did not have the issue of being stuck to 400 MHz. The quiet fan under W11 was nice⦠I hope weāll have a custom fan curve in the future.
See also [RESPONDED] Changing the fan temperture points with ectool for a way to modify the fan curves in the embedded controller. Then no userspace daemon is needed.
(I havenāt tried 3.17 yet but I except that this will still work after the update.)
Updated to 3.17 from original BIOS on my machine (3.04) using the Windows executable. Everything went smooth, but now noticing the fan noise ramp up from nothing to loud quite often.
Thanks for the new BIOS! Updated via EFI.
Fan isnāt nerfed like on 3.09 anymore. Ran a full load test, and the CPU maintains a satisfactory sustained boost
Pre-Boot external display also works well! Looking forward to have that also enabled on Core Ultra and other systems.
One quirk, I think some other users also mentioned, is the fan became actually more responsive compared to 3.08, the previous stable version. The fan immediately goes to work when CPU load hits, while 3.08 kind of āwait and seeā for a few seconds.
I donāt think this is an urgent āproblemā, and definitely miles better than 3.09 which the laptop just bakes. Iām staying on 3.17 if this is the only quirk, but ramp-up/ramp-down could indeed be smoothed out more. Perhaps we can further fine-tune this later down the road, or/and add a āResponsive/Smoothā fan curve option in BIOS.
Thanks again for the update.
Update 1: Is the fan speed tied to real-time CPU utilization? Trying to find a pattern in Windows 11, and that seems to be the case at least from appearance.
Fwiw, these are the fan defaults for 3.04:
$ sudo ectool thermalget
sensor warn high halt fan_off fan_max name
0 0 361 371 324 342 F75303_Local
1 0 361 371 324 342 F75303_CPU
2 0 360 370 313 342 F75303_DDR
3 0 323 333 313 323 Battery
4 388 393 400 376 378 PECI
5 0 361 371 324 342 F75397_VCCGT
You could try setting these on 3.17:
$ sudo ectool thermalset 0 0 361 371 324 342
...
Sorry for the late reply due to a event over the last two weeks. After debugging and reviewing the prior EC code changes, I found a problem with the fan curve settings in the pass 2 EC versions when implementing the virtual temperature sensor. Even with the virtual temperature sensor disabled, it still impacts the fan curve. On a positive note, disabling the virtual temperature sensor does seem to allow the system to leave the 0.4GHz state a bit quicker. Iām now working with the thermal team to revise the fan curve and analyze the thermal performance after the correction.
Currently, we still plan to release 3.17 to stable but will release the new version to fix this problem asap once the thermal test and fan curve are confirmed.
Here are the defaults on 3.17 (edit: fixed, thanks to Framework Laptop 13 - 12th Gen Intel Core BIOS 3.17 Release BETA - #54 by Ryan_Martens):
sensor warn high halt fan_off fan_max name
0 0 361 371 324 342 F75303_Local
1 0 361 371 328 353 F75303_CPU
2 0 360 370 313 342 F75303_DDR
3 0 323 333 313 323 Battery
4 388 393 400 333 363 PECI
5 0 361 371 324 342 F75397_VCCGT
(all temps in degrees Kelvin)
What has changed is sensor 4 (PECI), and I think the new fan behavior is (mostly) due to this change. Now, on 3.17 BETA, fan_off
and fan_max
are in a reasonable range for the CPU temperatures. Previously, they were set at 103 °C and 105° C, respectively, which seem a bit strange: Theyāre very close to each other, and very high. Perhaps these were just ālast resortā values for when sensor 1 reports wrong values? Anyway, it appears that the PECI sensor is much more responsive than the F75303 sensors (which makes sense because itās on-die), and so the fans are also much more responsive.
This was changed in commit fwk update temp limits, revert _mk Ā· FrameworkComputer/EmbeddedController@c706510 Ā· GitHub @Kieran_Levin Perhaps you can comment on this reason for the change since you were involved in the commit? Could it make sense to raise the PECI values a bit (at least the fan_off
)?
edit: @Quin_Chou Oh, my post was concurrent to yours.
Yes, you are correct. That is what I found.
I finally took a change and tried an update to the 3.17 BETA here. (I was still on 3.04). Hereās my long and frightening journey:
- I tried the EFI update on a USB stick. The CSME updated worked, but the rest didnāt. The laptop restarted into Linux, and I was still on 3.04. (I didnāt get a chance to look at the screen before the reboot, so I missed any error messages.)
- When I tried it again, I got āFull FW update using same version is not allowedā from the CSME updater, which confirmed that the CSME update worked. I also got the ācannot find a valid file system on boot devicesā message. I googled this and found the 3.08 thread (12th Gen Intel Core BIOS 3.08 Release - #497 by NF117).
- I tried various suggestions found in this thread. First, I checked if thereās enough free space on the EFI partition. I have > 800 MB, so this should be fine. Then, I tried
CapsuleApp.efi -F
, which correctly showed the NVME drive asfs1:
. Following 12th Gen Intel Core BIOS 3.08 Release - #509 by Kieran_Levin, I switched manually tofs0:
and runCapsuleApp.efi winux.bin firmwarehdr.cap -OD FS1
. Okay, it couldnāt findfirmwarehdr.cap
. Tried again withCapsuleApp.efi winux.bin Framework_Laptop_13_12th_Gen_Intel_Core_capsule_signed_allsku_3.17.cap -OD FS1
. This brought me a step further, but the laptop just rebooted into Linux. - After figuring out that others had the same problem when updating from 3.04 to 3.08, I tried to update to 3.06 first (12th Gen Intel Core BIOS 3.08 Release - #596 by dormando) This didnāt really work, and I got the same shell redirect error as in the post. Then charging didnāt work anymore, and so I went to the BIOS setup, soft-disconnected the battery, let it sit for a few seconds, and charging worked again. Puhā¦
- I decided to try the LVFS method because CSME was already updated. I tried to be careful and trigger the updates one by one: first FW, then one retimer, then the other retimer. This worked fine. (I should have done this instead of 3.06).
tl;dr: If youāre on Linux, and the EFI method fails with āFull FW update using same version is not allowedā and ācannot find a valid file system on boot devicesā after retrying, I recommend switching to the LVFS method to finish the update.
Weird, I got slightly different values on 3.17
sensor warn high halt fan_off fan_max name
0 0 361 371 324 342 F75303_Local
1 0 361 371 328 353 F75303_CPU
2 0 360 370 313 342 F75303_DDR
3 0 323 333 313 323 Battery
4 388 393 400 333 363 PECI
5 0 361 371 324 342 F75397_VCCGT
For CPU: my fan_off
and fan_max
are slightly higher (328 and 353 respectively) than both your 3.04 and 3.17.
For PECI: my fan_off
and fan_max
are both 10 degrees lower (333, 363).
Why might that be?
Oh, sorry, your values are correct. Iāll edit my post.
For PECI: my
fan_off
andfan_max
are both 10 degrees lower (333, 363).
Oops, I had adjusted this one already before copying the tableā¦
For CPU: my
fan_off
andfan_max
are slightly higher (328 and 353 respectively) than both your 3.04 and 3.17.
Hm, yeah, it turns out that this line (and the others?) seems to persist across reboots. Iāve been playing with the curve for a long time, so donāt count on my values. But judging from the mentioned commit, my table for 3.04 was correct, but yours is correct for 3.17. Both the thresholds for CPU and PECI have changed.
More updates in this vein please. This level of transparency is greatly appreciated.
Ran into my first issue upgrading my framework bios, and it was an error on my part.
Using the EFI method.
āError: Cannot find a EFI system partition!ā
Iāve been using EFI for a while so I suppose years ago I converted from bios boot to EFI and forgot to change my efi partition type from āBios Bootā to āEFI Systemā.
Update worked just fine after changing the partition type.
Thank you very much!!
Iām developing feelings we might actually hunt down and fix this issue once and for all. This is very good. Iād appreciate further updates like this a lot as well (as written by somebody else already).
Best,
Stefan
I can confirm the fan behavior and Iām 99% sure itās linked to PECI temperature.
The fan ramps up every time PECI temperature spikes, which can be caused by things like opening a website.
While stress testing, I have noticed something concerning though: When I hit both CPU and GPU, the PECI temp reads as ERROR (as it did before the update), but the fan speed actually drops way down to ~3000RPM.
Iām still not entirely sure what exactly the PECI temperature indicates, but that behavior doesnāt seem right.
Successfully upgraded from 3.08 to 3.17 via the EFI method after two restarts.
The upgrade itself went smoothly, but I immediately noticed the fan making more aggressive bursts of activity after starting like the other reports in this thread. The fan activity can be distracting when browsing the web.
I was able to update from 3.05 to 3.17 with no incident using the EFI method on Ubuntu 24.04. I followed the instructions, and it went pretty much as advertised. Everything shows the right version now, according to the table at the top. The retimers are both version 310. No problems. Re: other comments - I have not noticed any big problem with fan noise, but the noisy fan on my Dell thunderbolt dock probably drowns it out in any case. Thanks to Framework for sticking with it, and thanks to everyone on this thread for information, particularly Daniel Hall.