Framework Laptop 13 - 12th Gen Intel Core BIOS 3.18 Release BETA

Highlights

  1. Update Microcode to 0x437.
  2. Reverted fan set points to prevent the CPU from throttling to 400Mhz

Please note that if you update to 3.06 or higher, you will not be able to downgrade to version lower than 3.06, as it will cause left side ports to stop functioning correctly.

You can check your current BIOS version following the steps here to determine if you are on the latest release.

After the beta release, we will monitor community feedback, and publish this release to our stable release channel after approximately one week if no major issues are reported.

Subscribing to release notifications

If you want to subscribe to new release notifications you can now opt in through this link to receive an email when we release a new BIOS or driver update for your Framework Laptop.

Battery Extender functionality

With the high energy density on the 61Wh battery, leaving it at 100% state of charge for an extended period of time can shorten the lifetime of the battery. To prevent this, we have added a new feature that automatically limits the maximum state of charge if the system is left plugged into power for more than 5 days. The timer is reset after the system is disconnected from a power adapter for more than 30 minutes.

Battery Extender Duration Battery State of Charge
0-5< Days 99% → 100%
5-7 Days 90% → 95%
>7+ Days 85% → 87%

This functionality also reduces cycling of the battery by allowing the battery to discharge by several percent before charging again. Note that in addition to this automatic setting, you can also manually set a lower charge limit on your battery in BIOS to further preserve battery longevity.

This feature can be disabled or enabled in the BIOS Advanced menu.

Battery Extender: This option is enabled by default. If disabled, the system will always keep the battery fully charged.

Battery Extender Trigger: This option sets the number of days that must pass before the battery state of charge is reduced automatically to extend the battery life.

Battery Extender Reset: This option sets the number of minutes that the system is running on battery before the extender is reset, causing the system to charge to 100% when attached to power again.

Battery Charge Limit Functionality

This release modifies the battery charge limit functionality to add a 5% float range. This allows us to reduce the number of microcycles on the battery when the CPU turbos.
Previously to the change in 3.07, the battery would be held at the target state of charge, so if a large power draw happened for a short time, such as when the CPU turbos, the battery would drain slightly and then charge again.
Introduced in this version, the battery will not start to charge until the battery has dropped 5% below the charge limit.

As an example, if the user sets the battery charge limit to 80%, the battery will maintain a state of charge between 80% and 75%. And will not charge up to 80% until it has discharged to 75% while the system is on.
If this is activated while the battery state of charge is above the limit, the battery will discharge without drawing power from the adapter until the upper limit is reached.

Downloads

Windows

Download Link SHA256
Framework_Laptop_13_12th_Gen_Intel_Core_BIOS_3.18.exe 9CD9B9D1022B8D44A8EEC968DAD3CD4DE6B6ECDFD73BEF401457860EFDBAA259

Instructions for Windows Installer:

  1. Run the .exe.
  2. Click yes to reboot.
  3. Wait for the firmware progress bar to complete, and then the system will reboot.
  4. If you are updating a system in standalone mode, please pay careful attention to the standalone update process below.

Please note that you must update with a charger attached.

Please note that the windows update does not support updating retimer firmware. There is not a functional impact to port functionality if you do not choose to update your retimer firmware.

Windows retimer updates

Updating the retimer will update to a signed retimer firmware that is Thunderbolt certified. There is no change to port functionality if you do not choose to update your retimer firmware. To perform the retimer update, you will need to follow the instructions twice using the following executable files, as there are two sets of retimers on the system, and each pair needs to be updated separately.

Download Link SHA256
Framework_Laptop_13_12th_Gen_Intel_Core_Retimer_port_01_310.exe f4a9315376eb73c4c6c8e380e0540afc5adef2da5b787443188befebc50e4f51
Framework_Laptop_13_12th_Gen_Intel_Core_Retimer_port_23_310.exe 4c6c78c552d016b69009025beb0540c582a03bba3a581afa42320403b6584801

Retimer update instructions.

  1. Update the BIOS first.
  2. Boot into Windows after BIOS update.
  3. Run the .exe and wait for firmware update tool to stage the update.

  1. After initialization, the system will restart and and update the retimer firmware.
  2. Repeat step 3 after rebooting to update the second set of retimers.

Please note that you must update with a charger attached.

Linux/LVFS

Please note that for this platform LVFS will not update the CSME firmware. so we only recommend updating using the EFI updater. This is a limitation of LVFS which does not ship the binary blobs from Intel necessary to update the CSME.

Updating via LVFS is available in the testing channel during the beta period.

You can enable updates from testing by running

fwupdmgr enable-remote lvfs-testing

Please note that you must update with a charger attached, then run:

fwupdmgr refresh --force

then

fwupdmgr get-updates

then

fwupdmgr update

Please note that you must update with a charger attached.

LVFS may not update if the battery is 100% charged. LVFS uses the battery status to determine if it is safe to apply updates. However if our battery is at 100% and the charger is off, we set the battery charging status to false. In this case you can discharge your battery a few percent, then plug in AC again and run fwupdmgr update.

Linux/Other/UEFI Shell update

Please note, you need to update to 3.05 or later to update using EFI, as this is needed to support capsule on disk.

Download Link SHA256
Framework_Laptop_13_12th_Gen_Intel_Core_BIOS_3.18_EFI.zip 63B67EF91D78609D2F5CC1CD26F37037BEC43A8C05F42748BDF3C4F51A5A9D2F

We have rewritten the update process for EFI. This new version will stage the bios and retimer updates onto your internal SSD and run them all together in sequence. This is to avoid issues with usb devices disconnecting and disappearing during subsequent updates during the update process, which would cause partial updates to be applied.
Troubleshooting:
If you experience ports not working after your update. Please shutdown, unplug all power sources, wait 90 seconds, and then power on again.

Note that if you use the EFI shell update with Windows, you should suspend Bitlocker if enabled before updating using the EFI updater.

Instructions for EFI shell update:

  1. Extract contents of zip folder to a FAT32 formatted USB drive. Cleanly unmount the drive before physically removing it, otherwise the BIOS update may not function correctly.
  2. Boot your system while pressing F12 and boot from the thumb drive.
  3. Let startup.nsh run automatically.
  4. Follow the instructions to install the update.

Updating retimers

After the bios update completes, press F12 after restarting to again enter the boot menu, and boot from your thumb drive. Let startup.nsh run again to confirm or update your retimer firmware. If retimers need updating, the update will be staged to perform an update on both retimers.

If doing a standalone update, the display output will not work during the retimer update. Please note that retimer updates take 2 minutes to complete. So please wait at least 5 minutes before attempting to power off or reset the device.

Updating a Mainboard outside of a laptop

This release supports standalone updates without a battery attached only when updating using the EFI shell method only. After rebooting, please follow the onscreen instructions to update your BIOS when in standalone mode, which will require moving the power source between both sides of the Mainboard to allow PD firmware to update correctly.

Please note that the power and display output must be connected to the same side during standalone updates. Failure to do this may result in no display output during the update process.

We recommend the following update flow for standalone updates:

Part 1

Ensure that standalone operation is enabled in the bios advanced setup menu.

Display connected to upper left port.
Power connected to the lower left port.
Run the updater from EFI shell. Please follow the ā€œInstructions for EFI shell updateā€ to run the updater.

Select the EFI USB Boot Device.

The Updater will update the PD controller from right side. Press any key to continue updating.

Part 2

Plug the AC to the left side, then boot to EFI updater. The Updater will update the PD controller from left side. Press any key to continue updating.

After PD updates, it will reboot automatically, then start the BIOS capsule update.

Then, the EC will update after BIOS section finishes.

After this, the system will reboot. Please press F12, and select your thumb drive as the boot device. And run the update again to update retimers if necessary.

If the retimer update is finished, the system will reboot automatically. Please press F12 again, and select your thumb drive as the boot device. You will see the screen that shows all the firmware versions.

If the retimer update is not needed, you will see the screen that shows all the firmware versions.

Security Fixes

CVE Note Score (CVSS Version 3.x)
CVE-2025-20109 Improper isolation in some IntelĀ® Processors stream cache mechanism may allow an authenticated user to potentially enable escalation of privilege via local access. 7.8
CVE-2025-20054 Potential security vulnerabilities in some IntelĀ® Processors may allow denial of service. 6.5
CVE-2024-45332 A potential security vulnerability in some IntelĀ® Processor stream cache mechanisms may allow escalation of privilege. 5.6

Enhancements

  1. Update Microcode to 0x437.

Fixes

  1. Reverted fan set points to prevent the CPU from throttling to 400Mhz

Component Versions

This BIOS update is a bundle of updates to multiple embedded components in the system.

Not all of them use the same version number.

BIOS 3.18 3.17
SI c.0.75.10 c.0.75.10 Same
TXT 1.18.13.0 1.18.13.0 Same
Intel CSME 16.1.35.2557 16.1.35.2557 Same
Microcode 437 436 Updated
GOP 21.0.1061 21.0.1061 Same
EC f6620a8 a7cf293 Updated
PD 0.1.2E 0.1.2E Same

Known Issues

  1. There are two progress bars when updating the bios using the EFI update method.
  2. No display output during the retimer update in standalone mode.
9 Likes

update using EFI went smoothly

4 Likes

I’d give it a try through LVFS (as the CSME version did not change in comparison to 3.17), but lvfs-testing does not provide this beta version currently (tested right now). Will retest in a few hours.

EDIT: successfully upgraded using LVFS some hours later. Upgrade went smooth.

1 Like

I’ve been driving it for a couple hours and in some more I’ll start having some Google Meet calls that were consistently giving me 400Mhz even with 3.17 (albeit a lot less than previous firmware versions and recovered much faster), the paranoia of the fans is definitely gone which I thank all the gods, it was really annoying

I’m adding again the link to the SoftwareFirmwareIssueTracker on Github for reporting problems with the Beta.

Is there a reason why the BIOS announcements for the 11th and 12th Gen Intels are always missing the dedicated section " Reporting Issues" the newer mainboards usually get (e.g., Framework Laptop 13 IntelĀ® Coreā„¢ Ultra Series 1 BIOS 3.05 Release Stable)?

Updated via EFI (no update in lvfs-testing yet). So far, the fans seem much less annoying.

1 Like

've just performed the upgrade with LVFS (worked flawlessly, awesome!), and I see an improvement, in the sense that I do see some CPUs hit turbo sometimes.

This is a 12th gen Framework 13" with a 12th Gen Intel(R) Core(TM) i5-1240P CPU.

Here’s what i7z looks like as I’m typing this:

Cpu speed from cpuinfo 2111.00Mhz
cpuinfo might be wrong if cpufreq is enabled. To guess correctly try estimating via tsc
Linux's inbuilt cpu_khz code emulated now
True Frequency (without accounting Turbo) 2111 MHz
  CPU Multiplier 21x || Bus clock frequency (BCLK) 100.52 MHz

Socket [0] - [physical cores=12, logical cores=16, max online cores ever=12]
  TURBO ENABLED on 12 Cores, Hyper Threading ON
  Max Frequency without considering Turbo 2211.52 MHz (100.52 x [22])
  Max TURBO Multiplier (if Enabled) with 1/2/3/4/5/6 Cores is  44x/44x/37x/35x/35x/35x
  Real Current Frequency 3076.65 MHz [100.52 x 30.61] (Max of below)
        Core [core-id]  :Actual Freq (Mult.)      C0%   Halt(C1)%  C3 %   C6 %  Temp      VCore
        Core 1 [0]:       2014.95 (20.04x)      1.21    97.8       0       1    46      1.1127
        Core 2 [2]:       3076.65 (30.61x)      2.36    95.6       0       1    46      1.1127
        Core 3 [4]:       2350.32 (23.38x)       2.1    96.2       0     1.5    46      1.1078
        Core 4 [6]:       2973.10 (29.58x)      2.77    95.1       0       1    48      1.1277
        Core 5 [8]:       2334.90 (23.23x)      1.68    2.28       0    95.9    45      1.1127
        Core 6 [9]:       2715.21 (27.01x)      1.65    1.66       0    96.2    45      1.1127
        Core 7 [10]:      2170.68 (21.59x)         1    1.91       0    97.1    45      1.1277
        Core 8 [11]:      1643.91 (16.35x)       1.4    3.64       0    95.3    45      1.1277
        Core 9 [12]:      2174.92 (21.64x)         1     1.3       0    98.1    48      1.1477
        Core 10 [13]:     2066.47 (20.56x)         1    5.84       0    93.5    48      1.1377
        Core 11 [14]:     1810.60 (18.01x)         1    0.621      0      99    48      1.1377
        Core 12 [15]:     1432.82 (14.25x)      1.26    3.24       0    95.9    48      1.1377

Now I wish I had copy-pasted the i7z output in Framework Laptop 13 - 12th Gen Intel Core BIOS 3.17 Release Stable - #124 by anarcat to compare, but I seem to recall it was more stuck around 1000MHz before, I would not see those 2000/3000MHz marks at all.

And while performing a becnhamark, it actually spins up to 4GHz correctly:

Cpu speed from cpuinfo 2111.00Mhz
cpuinfo might be wrong if cpufreq is enabled. To guess correctly try estimating via tsc
Linux's inbuilt cpu_khz code emulated now
True Frequency (without accounting Turbo) 2105 MHz
  CPU Multiplier 21x || Bus clock frequency (BCLK) 100.24 MHz

Socket [0] - [physical cores=12, logical cores=16, max online cores ever=12]
  TURBO ENABLED on 12 Cores, Hyper Threading ON
  Max Frequency without considering Turbo 2205.24 MHz (100.24 x [22])
  Max TURBO Multiplier (if Enabled) with 1/2/3/4/5/6 Cores is  44x/44x/37x/35x/35x/35x
  Real Current Frequency 4316.37 MHz [100.24 x 43.06] (Max of below)
        Core [core-id]  :Actual Freq (Mult.)      C0%   Halt(C1)%  C3 %   C6 %  Temp      VCore
        Core 1 [0]:       2924.97 (29.18x)      4.27      91       0    3.04    63      1.0684
        Core 2 [2]:       4316.37 (43.06x)       100       0       0       0    94      1.0884
        Core 3 [4]:       3427.23 (34.19x)      3.22    93.8       0       1    60      1.1338
        Core 4 [6]:       3468.47 (34.60x)      6.07    88.5       0    1.52    63      1.0638
        Core 5 [8]:       2942.05 (29.35x)      4.56    4.12       0    89.5    60      1.1238
        Core 6 [9]:       3059.79 (30.53x)      7.99    3.86       0    84.6    60      1.1438
        Core 7 [10]:      2831.92 (28.25x)      2.12    4.76       0    92.4    59      1.1438
        Core 8 [11]:      3049.16 (30.42x)      5.73    2.29       0    89.4    59      1.1438
        Core 9 [12]:      2677.65 (26.71x)      2.93    3.67       0    92.6    61      1.1538
        Core 10 [13]:     2762.01 (27.55x)      2.99    6.05       0      90    61      1.1538
        Core 11 [14]:     2930.54 (29.24x)      2.63    3.34       0      93    61      1.1688
        Core 12 [15]:     2126.81 (21.22x)      3.23    9.71       0      87    61      1.1538

… and I do see a performance improvement on the benchmarks!

anarcat@angela:~/s/asncounter> hyperfine -i -w 3 --input test/data/sample-10m.ips \
                                    "./asncounter.py --cache-dir=test/cache"
Benchmark 1: ./asncounter.py --cache-dir=test/cache
  Time (mean ± σ):      6.506 s ±  0.104 s    [User: 6.387 s, System: 0.118 s]
  Range (min … max):    6.361 s …  6.690 s    10 runs
 

Before the BIOS upgrade, it was 16 seconds instead of 6 seconds.

I don’t get the quirky fan spinups anymore (which were oddly satisfying, after the first knee-jerk reaction), but I guess that’s a profile I can adjust myself…

Fan is at 5k RPM during the benchmark according to sensors and spins down to 3k after a a couple minutes, the whole thing gets pretty hot still (50C), so I’m not sure the fan profiles are ideal.

Every 2.0s: sensors                                      angela: Thu Jul 10 10:00:16 2025

iwlwifi_1-virtual-0
Adapter: Virtual device
temp1:        +42.0°C

cros_ec-isa-000c
Adapter: ISA adapter
fan1:         3361 RPM
F75303_Local:  +47.9°C
F75303_CPU:    +49.9°C
F75303_DDR:    +47.9°C
Battery:       +31.9°C
PECI:          +51.9°C
F75397_VCCGT:  +45.9°C

acpitz-acpi-0
Adapter: ACPI interface
temp1:        +51.8°C
temp2:        +47.8°C
temp3:        +49.8°C
temp4:        +45.8°C
temp5:        +31.8°C

coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +52.0°C  (high = +100.0°C, crit = +100.0°C)
Core 0:        +52.0°C  (high = +100.0°C, crit = +100.0°C)
Core 4:        +51.0°C  (high = +100.0°C, crit = +100.0°C)
Core 8:        +50.0°C  (high = +100.0°C, crit = +100.0°C)
Core 12:       +48.0°C  (high = +100.0°C, crit = +100.0°C)
Core 16:       +50.0°C  (high = +100.0°C, crit = +100.0°C)
Core 17:       +50.0°C  (high = +100.0°C, crit = +100.0°C)
Core 18:       +50.0°C  (high = +100.0°C, crit = +100.0°C)
Core 19:       +50.0°C  (high = +100.0°C, crit = +100.0°C)
Core 20:       +51.0°C  (high = +100.0°C, crit = +100.0°C)
Core 21:       +51.0°C  (high = +100.0°C, crit = +100.0°C)
Core 22:       +51.0°C  (high = +100.0°C, crit = +100.0°C)
Core 23:       +51.0°C  (high = +100.0°C, crit = +100.0°C)

BAT1-acpi-0
Adapter: ACPI interface
in0:          17.21 V
curr1:         0.00 A

nvme-pci-0100
Adapter: PCI adapter
Composite:    +36.9°C  (low  = -40.1°C, high = +83.8°C)
                       (crit = +87.8°C)
Sensor 1:     +51.9°C  (low  = -273.1°C, high = +65261.8°C)
Sensor 2:     +36.9°C  (low  = -273.1°C, high = +65261.8°C)

here’s what the ec fan profile looks like:

anarcat@angela:~[1]> sudo dist/EmbeddedController/build/bds/util/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
EC result 3 (INVALID_PARAM)
(all temps in degrees Kelvin)

this seems similar to previously reported (e.g. Framework Laptop 13 - 12th Gen Intel Core BIOS 3.17 Release Stable - #54 by Ryan_Martens)

After writing this for a while, the fan has spun down to 2k RPM and is not audible over the ambiant noise here, it was barely audible before, even during the benchmark.

Finally:

I saw that! It’s a little distracting, but otherwise feels completely inoffensive.

That, I did not notice however, not sure what it means.

So, long story short, I’d call this a Great Success, thanks for iterating quickly on this, and congrats on the team!

5 Likes

I’ve actually wondered why I’ve never seen those two progress bars. During the updates to 3.09, 3.17, and now 3.18 there was always only the green one visible.

1 Like

I upgraded from 3.17 using EFI method, and noticed a small issue:

When the machine default-booted into my USB drive (I have it as the first device to boot to), the script will always fail with the message ā€œNot foundā€. With some testing I found that the message was emitted by the bundled framework_tool.efi.

The workaround I used was to enter the boot menu, then select the USB from there, which would allow framework_tool.efi to work again and the upgrade to proceed.

Other than that, it’s only a few minutes after installation but I hope that there are no regressions :crossed_fingers:

1 Like

Updated to 3.18 using EFI to check retimers as well. It went smoothly.

1 Like

Flawless update. Finally Framework appears to be prioritizing firmware updates. Thanks for the focus and the thankless hard work. Keep it up.

6 Likes

I just updated from 3.17 in Win11 24H2 using Framework_Laptop_13_12th_Gen_Intel_Core_BIOS_3.18.exe with no issues.

I noticed the 3.17 Release Page stated Please note that retimer updates only need to be done one time. So this is only necessary to do one time. This is optional., but I didn’t see this advice about only doing it once in this announcement (only that it was optional).

Unless a BIOS update resets the retimers, or a new version is released, I would suggest adding the note about not having to redo this step back into the final release posting since the retimer updates were in the 3.17 release.

After the update it was fine. However, I drained the battery down to nothing and had to plug it in for power and then turned it on. When I got back into windows I am stuck at 400Mhz for 20 minutes. Then I rebooted and it still was stuck at 400Mhz. Fans never ramped up. I decided to try flashing 3.18 again and that fixed it.

The issue may be tool-related. Thanks for the feedback, I’ll investigate.

The issue may happen when system updates BIOS in the standalone mode.

1 Like

Thank you very much. Here are my test results.

For reference - I came from 3.17. First updated BIOS, afterwards retimers. Windows 11 latest patch level.

In general I would say things improved, we are getting somehow closer? My impression was it took quite longer until the 0,40GHz bug kicked in again and if it did it didn’t got stuck there for minutes, more like 10-30 seconds roughly I would say.

Here are some screenshots from the last three occurences:



By the way - any testing tool etc. available by now which I could use help troubleshoot the issue? We talked about that in the 3.17 thread.

For reference the system information excerpt showing 3.18 installed:
REF

Thanks & Best
Stefan

It would be great if the updates that are offered via LVFS would also show this is a beta update. On Fedora it shows up as a regular update and since I really need my machine to work I don’t want to install beta versions. I checked this post to find out it’s a beta. See screenshots below. I would be great if it shows in the title it concerns a beta version of the firmware.


Is lvfs-testing enabled by default in Fedora? In Arch, I had to edit /etc/fwupd/remotes.d/lvfs-testing.conf to get access to Beta firmware.

1 Like

Is this from lvfs Stable or Testing repo?

1 Like

Apparently it’s enabled by default… So this is a classic PEBCAC… Thanks for pointing this out. I’ve disabled the testing repo. Maybe this is something @Matt_Hartley can add to the Fedora on Framework guide so people like me are aware of the fact testing is enabled by default and that you can disable the testing repo if you rely on the machine? Fedora 42 Installation on the Framework Laptop 13 - Framework Guides

Sorry this is incorrect LVFS testing is not enabled by default. The user needs to explicitly enable testing. The default enabled for fwupd is stable.

1 Like