Framework Laptop 16 BIOS v4.02 and Driver v3.01 Releases (AMD Ryzen™ 7040 Series) STABLE

I reported this issue as well, way back on the 4.01 bios release:

We are now over a month into this broken 4.02 bios release, still without a fix. What is taking them so long?

Reminds me of when Razer released that Forge set top box and had like only one guy working on the software for it, never improving it (it never even got Netflix working)….. Then liquidated the entire product line a few months later.

Previously, it would cap at 35 our 38W when I used a CalDigit TS4 as the power source (it provides 96W). Now, it still caps at that for the CalDigit, but as soon as I plug the official one, it will go down to 30W :upside_down_face:

1 Like

I have it reported

I think they have see it…

Well I hop it is related :wink:
but il look it take some time.

1 Like

I started to notice some problems with 4.02 bios and 240w chargers.
Under specific load scenarios and having PPD set to performance (sometimes happens with balanced but much more rarely) the connection will reset and power renegotiated.
Shouldn’t be a problem with the dock, because it is rated up to 6+ amps on 48v, but you never know.

ec logs
PORT80: F90E
[270893.139100 HC 0x0002]
[270893.141500 HC 0x000b]
[270893.414000 HC 0x0002]
[270893.416200 HC 0x000b]
[270893.672800 HC 0x0002]
[270893.675000 HC 0x000b]
[270893.918900 HC 0x0002]
[270893.921300 HC 0x000b]
[270894.154600 HC 0x0002]
[270894.156700 HC 0x000b]
[270894.378700 HC 0x0002]
[270894.381100 HC 0x000b]
[270894.605600 HC 0x0002]
[270894.607800 HC 0x000b]
[270894.916600 HC 0x0002]
[270894.918700 HC 0x000b]
[270895.151100 HC 0x0002]
[270895.153400 HC 0x000b]
[270895.434700 HC 0x0002]
[270895.437000 HC 0x000b]
[270895.703200 HC 0x0002]
[270895.705500 HC 0x000b]
[270895.924200 HC 0x0002]
[270895.926700 HC 0x000b]
[270896.165200 HC 0x0002]
[270896.167400 HC 0x000b]
[270896.391000 HC 0x0002]
[270896.393800 HC 0x000b]
PORT80: 0040
[270898.478300 event set 0x0100000000000000]
[270898.531100 PMF: SPL 95000mW, sPPT 95000mW, fPPT 95000mW, p3T 150000mW, ao_sppt 45000mW]
PORT80: AA8F
PORT80: 0020
[270899.562600 event set 0x0100000000000000]
[270899.614400 PMF: SPL 120000mW, sPPT 120000mW, fPPT 120000mW, p3T 150000mW, ao_sppt 45000mW]
PORT80: AA8F
PORT80: 0010
[270901.694600 event set 0x0100000000000000]
[270901.749200 PMF: SPL 145000mW, sPPT 145000mW, fPPT 145000mW, p3T 227000mW, ao_sppt 45000mW]
PORT80: AA8F
[270902.436500 HC 0x0002]
[270902.438800 HC 0x000b]
[270902.712100 HC 0x0002]
[270902.714300 HC 0x000b]
[270902.992300 HC 0x0002]
[270902.994600 HC 0x000b]
[270903.236300 HC 0x0002]
[270903.239300 HC 0x000b]
[270903.511500 HC 0x0002]
[270903.513700 HC 0x000b]
[270903.761600 HC 0x0002]
[270903.764600 HC 0x000b]
[270904.008000 HC 0x0002]
[270904.010200 HC 0x000b]
[270904.244000 HC 0x0002]
[270904.246300 HC 0x000b]
[270904.483000 HC 0x0002]
[270904.485100 HC 0x000b]
[270904.738800 HC 0x0002]
[270904.741000 HC 0x000b]
[270904.957700 HC 0x0002]
[270904.959800 HC 0x000b]
[270905.188500 HC 0x0002]
[270905.191200 HC 0x000b]
[270905.418300 HC 0x0002]
[270905.420500 HC 0x000b]
[270905.672600 HC 0x0002]
[270905.675200 HC 0x000b]
[270905.889500 PORT_DISCONNECT]
[270905.890700 events = 2, pre_events = 0]
[270905.891800 set AP throttling type 1 to on (0x00000010)]
[270905.899500 board_set_active_charge_port port -1, prev:0]
[270905.901800 event set 0x0400000000000000]
[270905.914600 cypd_write_reg8_wait_ack C:0 0x1032 response 0x0]
[270905.916900 cypd_cfet_vbus_control:0 fail:5]
[270905.918200 Force exit bypass mode for port switch]
[270905.928000 ISL9241 bypass_chrg -> bat]
[270905.931700 event set 0x0400000000000000]
[270905.948000 ISL9241 bypass_chrg -> bat]
[270905.956800 event set 0x0400000000000000]
[270905.969700 cypd_write_reg8_wait_ack C:0 0x1032 response 0x0]
[270905.972300 cypd_cfet_vbus_control:0 fail:5]
[270905.984900 cypd_write_reg8_wait_ack C:1 0x1032 response 0x0]
[270905.987200 cypd_cfet_vbus_control:2 fail:5]
[270905.994000 cypd_write_reg8_wait_ack C:1 0x2032 response 0x0]
[270905.996100 cypd_cfet_vbus_control:3 fail:5]
[270905.997600 update charger!!]
[270906.014600 AC off]
[270906.076700 TYPE_C_ERROR_RECOVERY]

Had an issue during the BIOS update (from 3.05) where it seemed to power off in the middle of it (screen turned off, all LEDs on keyboard, numpad, power button, and mainboard turned off) and the power button did not turn it back on (both a simple press and a hold). I disconnected and reconnected the power cable and battery, which fixed the issue and allowed the BIOS update to complete.

I came across an interesting comment, in this video

@Thundertactics
I had a look at how they pulled it off a while ago (it really is great how much information they share about their circuitry) and it looks like they have an additional buck converter IC (a TI LM5143) which is used to step USB-C’s 48V down to the 20V that’s more common in proprietary chargers (and USB-C PD at 100W). And then that 20V is used by their battery charger (Renesas ISL9241, which is fairly common)). That additional conversion is definitely going to reduce efficiency (unfortunately the datasheets for the LM5143 don’t really specify efficiencies at those voltages, but their graphs at other voltages don’t really go above 95%), which is the reason why those other companies don’t bother. (And this isn’t just them wanting to save you some money on your electricity bill, that reduced efficiency is just turning into heat, which is going to make cooling even more troublesome. And they might need a more powerful charger to reach the same effective power budget.) There’s some laziness and penny-pincing at play, to be sure (not like they couldn’t at least give you the option to use their USB-C ports at that power, and throttle the rest of the system to compensate for the heat), but these are valid design concerns. Ideally, there’d be some battery charger IC and cell configuration which could take 48V directly, but that doesn’t seem to be readily available.

The power management is particularly challenging because of this. The laptop literally uses two DC-DC converter for PD(non-EPR) and EPR chargers. In the latter case the 48V is stepped down to 20V then goes to the non-EPR buck-boost converter. Hopefully there’s a BIOS update later to passthrough the buck-boost and only use the 48V buck when EPR charger is connected, or make a custom 20V12A adapter

1 Like

I tracked my problem down to the usb-c PD cable (the one shipped with the 180w charger.) I am using a 240w -rated cable from Anker and have had no issues (yet)

2 Likes

Seems like the embedded controller firmware in this version makes the laptop limit the CPU power to 30W when using a Caldigit TS4 dock with its own 98W charger. Unfortunately I have to stay on v3.07 until we can modify the firmware available in v4.02 to get rid of this limit as it is still not available on the EmbeddedController GitHub repo.

1 Like

Is the latest EC firmware here for lotus and azalea (FW13 AMD and FW16 AMD 7040):
New Branch: fwk-tulip-29169

It mentions “lotus” and “azalea” so, maybe it replaces the branch lotus-azalea-19573 ?

I have not found out how to compile it yet, so if you manage to compole itblet me know.

I did try to compile but it seems like the lotus-zephyr branch for zephyr itself is not up to date as it just throws an error at me about a missing board when trying to compile the firmware using zmake build lotus -t zephyr

Configuring lotus:rw.
Loading Zephyr default modules (Zephyr base (cached)).
No board named ‘npcx9/npcx9m3f’ found.
Please choose one of the following boards:
CMake Error at /home/wsl/ECFirmware/src/third_party/zephyr/main/cmake/modules/boards.cmake:163 (message):
Invalid BOARD; see above.

I did try switching over to fwk-lilac-27116 zephyr, and while that did get rid of the board missing error, it just gave me a different error and still wouldn’t compile.

Configuring lotus:rw.
Loading Zephyr default modules (Zephyr base (cached)).
CMake Error at /home/wsl/ECFirmware/src/third_party/zephyr/main/cmake/modules/dts.cmake:311 (message):
  gen_defines.py failed with result code: 1 - stderr contents:
    devicetree error: 'stable-poll-period-ms' appears in /soc/kbd@400a3000 in
    /home/wsl/ECFirmware/src/platform/ec/build/zephyr/lotus/build-rw/zephyr/zephyr.dts.pre,
    but is not declared in 'properties:' in
    /home/wsl/ECFirmware/src/third_party/zephyr/main/dts/bindings/input/nuvoton,npcx-kbd.yaml

This branch also doesn’t contain chromiumos/third_party/zephyr/nanopb inside west.yml which makes me think its completely wrong and lotus-zephyr should still be used.

Any help with getting this compiled would be appreciated. I just used DHowett’s guide, but that does not seem to work anymore as it did previously. I did also try this to update dependencies, but that unfortunately changes nothing for lotus.

EDIT: I did also notice that the GitHub workflow on the fwk-tulip-29169 branch uses fwk-main branch for zephyr, so I did also try the main zephyr branch to no avail as well. I assume we should be using fwk-main but that is not published on the zephyr repository as of yet.

An update to this. I have managed to get the firmware to finally compile. It required changing a few things in both the EC and Zephyr code. The xml for repo and the two patches are available at this gist (apply ec.patch in src/platform/ec and zephyr.patch in src/third_party/zephyr/main). I cannot make guarantees that this’ll actually fully work as it isn’t using the “correct” zephyr branch from Framework since it doesn’t seem to be published yet, but this was a quick and dirty solution to get it to compile, I don’t have any issues running the firmware that I noticed as of yet.

Flashing also requires a newer version of ectool.efi (thanks @DHowett) as Framework changed the version formatting. The previous version would throw a “board mismatch” error due to this.

If anyone is interested into changing the power limits, the tables for the various configs (AMD dGPU, Nvidia dGPU and CPU-only) are located in src/platform/ec/zephyr/program/framework/lotus/src/pmf.c.

2 Likes

In case the post is not super visible, note that the 4.03 beta was just released:

4 Likes

(And beta 3.02 drivers.)

3 Likes

Installing the keyboard driver and BOIS worked fine, rebooting after each step. However, when updating the chipset driver with the v3.01 driver package on my Framework 16 (7040) on Windows 11 (Pro Workstation/24H2, clean installed from scratch about 8 months ago and all updates applied, and relatively few applications/drivers installed or anything else particularly non-standard), I get the error “This installer is intended to be deployed only on an AMD system. Exiting installation as the requirement is not satisfied.” which is obviously not the case, as the 1st-gen F16 has a R7 7840HS.

Error dialog screenshot

This is running as admin, after doing a full reboot with no other applications launched. I’ve tried various troubleshooting steps suggested online for this error, including resetting WMI and disabling Hyper-V and Device Guard, rebooting each time, but every attempt produced the same result. I’ve also had the same error occur on the same step during the install of at least one previous driver bundle.

For reference, per Windows “Installed apps” the current version of “AMD Chipset Software”, which I’m assuming is the chipset driver, is 5.06.29.310, well behind the nominal 7.06.02.123.

Version screenshot

What’s going on here? Thanks!

I has similar issue in the past. it was caused by missing VB support Reddit - The heart of the internet

1 Like

Thanks so much–yup, that fixed it! The VBScript Feature on Demand wasn’t enabled on my clean install, since it is an deprecated legacy feature as of 2023. Hopefully AMD fixes their installers to use pwsh or something else non-archiac by the time the FOD is disabled by default for all users, which per MSFT could be as soon as a year from now in sometime in 2027.

Hey, a few weeks ago I noticed that the alt codes stopped working on my keyboard + numpad, and since I did this update end of November/beginning of December, I’m wondering if the new keyboard firmware is the culprit. Has anyone else had this issue? I can use alt codes on another keyboard (proof: alt+0176 gives °) so I’m thinking it’s an input deck problem.

Hi,
On BIOS 4.0.2 the computer limits itself to 38W TDP when a 100W power adapter is plugged in.

This is inconsistent with the previous behavior, which is max 54W TDP when a 100W adapter is plugged in.

Toggling power modes in Linux can let it sometimes spike to 45W, but that quickly go back down to 38W.
Temps are good, 87 degree on the hottest spot.

Hi @Xavier_Jiang, I’m curious what software you are running to stress test your FW16 ?

s-tui on Linux Ubuntu 240403 (along with stress).

As well as CInebench R23 on Windows 10. There’s a bunch of others as well, but. These do the trick.

In both cases, no temperature reading from any system go above 90C, and the system sat at 38W TDP.

I lost my Lenovo 100W charger, so these will not be testable until a few days later.
I can also try with a 130W Dell charger (which is 20V 6.25A). But I suspect Framework might be programming it to do it only on 180W+ chargers.