Framework 16 AMD 7040, BIOS 4.05: PD1 warning reports 2.0.0C, but direct reads show 0.0.21; intermittent touchpad failure

Framework Laptop 16 Linux
1

Hello,

I’m seeking help diagnosing a reproducible discrepancy between the
EC’s reported PD firmware version and the versions read directly from
the PD controllers. I have also experienced an unresponsive touchpad,
although I have not established that the two problems share a cause.

My goal is to keep this laptop reliable and correctly configured. I
depend on it for job applications and interviews, so I would
appreciate a supported diagnostic and recovery sequence that minimizes
downtime.

System and current condition

Measurements below were collected today (10th September 2026).

Component Details
Laptop Framework Laptop 16, AMD Ryzen 7040 Series, mass-production mainboard
OS NixOS, GNOME/Wayland
Current kernel 7.2.4; touchpad failures also occurred on 7.2.3
BIOS 04.05, release date reported by firmware: 06/30/2026
EC RO and RW versions Both lotus-4.0.5-2246d58
EC build 2026-06-26 03:39:05
Executing EC image RO
ISO keyboard firmware 0.3.1
Touchpad firmware v0905
Diagnostic tool framework_tool 0.6.3

The machine currently boots into the desktop, and touchpad movement,
clicking and two-finger scrolling work. I have not established lasting
recovery.

Boot warning and reproducible discrepancy

After shutting down and starting the laptop, a full-screen preboot
warning displayed:

Please manually reinstall the BIOS to update PD1 firmware.
Currently: 2.0.0C. Expected: 0.0.21.

It included a QR code and allowed me to continue with a short press of
the power button. I continued.

Later in the running system, the EC’s two supported reporting
protocols returned:

$ sudo framework_tool --host-command 0x3e11 1
Response (17 bytes):
00000000: 0200 0000 0018 020c 2097 0100 3762 6e21  ........ ...7bn!
00000010: 00                                       .

$ sudo framework_tool --host-command 0x3e11 0
Response (16 bytes):
00000000: 0000 0000 1802 0c20 9701 0037 626e 2100  ....... ...7bn!.

Version 1 contains a controller count of two followed by the same 16
bytes returned by version 0. Using Framework’s
decoder,
the first controller’s application version decodes to 2.0.0C,
exactly matching the warning; the second decodes to 0.0.21.

However, sudo framework_tool --pd-info, run immediately after the
version-1 query, returned:

Right / Ports 01
  Silicon ID:     0x3580
  Mode:           MainFw
  Flash Row Size: 256 B
  Ports Enabled:  0, 1
  Bootloader Version:   Base: 3.6.0.009,  App: 0.0.01
  FW1 (Backup) Version: Base: 3.7.0.197,  App: 0.0.21
  FW2 (Main)   Version: Base: 3.7.0.197,  App: 0.0.21
Left / Ports 23
  Silicon ID:     0x3580
  Mode:           MainFw
  Flash Row Size: 256 B
  Ports Enabled:  0, 1
  Bootloader Version:   Base: 3.6.0.009,  App: 0.0.01
  FW1 (Backup) Version: Base: 3.7.0.197,  App: 0.0.21
  FW2 (Main)   Version: Base: 3.7.0.197,  App: 0.0.21
Back
  Failed to read Silicon ID/Family

Earlier repeated --versions and --pd-info queries also reported
0.0.21 for both side controllers. That is the PD version listed in
the BIOS 4.05 release
notes.

Touchpad symptoms and other diagnostics

The touchpad previously became completely unresponsive. This completed
successfully but did not restore it:

sudo modprobe -r i2c_hid_acpi && sudo modprobe i2c_hid_acpi

During the failure period, the kernel recorded:

i2c_hid_acpi i2c-PIXA3854:00: failed to set a report to device: -121
i2c_hid_acpi i2c-PIXA3854:00: failed to change power setting

For transparency, my NixOS configuration includes a custom touchpad
watchdog that can reload i2c_hid_acpi. Consequently, some driver
reinitializations in the logs were initiated by that watchdog.

After recovery, with the lid physically open, --inputdeck reported:

Chassis Closed:   true
Input Deck State: On
Touchpad present: true
SLEEP# GPIO high: true
Positions:
  Pos 0: GenericC
  Pos 1: KeyboardA
  Pos 2: Disconnected
  Pos 3: Disconnected
  Pos 4: GenericC

The current boot also contained UCSI errors, including UCSI_GET_PDOS failed (-95). I have not established a connection between these
errors, the touchpad and the PD-version discrepancy.

ectool successfully communicated with the EC and reported:

EC uptime: 2757.560 seconds
AP resets since EC boot: 0
EC reset flags at last EC boot: power-on | hibernate
Command 0x3e11 supports version mask 0x00000003

Port-80 history repeatedly alternated F90D and F90E, interspersed
with F022/F028. I have no authoritative interpretation of those
codes.

One boot also entered initrd emergency mode. Journal inspection showed
unsuccessful encrypted-volume unlock attempts followed by a
root-device timeout; unlocking subsequently succeeded. I am treating
that separately rather than assuming firmware caused it.

Source-level lead, not a confirmed root cause

The published input-module warning
implementation
uses this EC version-reporting path to generate the warning.

An earlier public EC revision’s
cypd_get_version()
logs a failed version-register read but still copies from its
uninitialized local buffer into the stored version record. Could this
explain the discrepancy?

I have not verified that this implementation exists in my
installed 2246d58 build, nor captured a boot-time
READ_ALL_VERSION_REG failed message. Both protocol versions
returning the same bad record suggests the issue is not limited to
version-1 response formatting, but does not identify the underlying
defect.

What I’m asking Framework

  1. Is this a known EC version-reporting or PD-initialization issue?
    What additional evidence would distinguish invalid stored version
    data from a controller or hardware fault?
  2. What exact recovery procedure do you recommend: a particular
    power-reset sequence, BIOS 4.05 reinstallation using a specified
    method, or another action? What should I capture first, and how
    should I verify lasting recovery?
  3. Could the touchpad failure be related, or should I investigate it
    separately, including testing without my watchdog? If the symptoms
    persist after the supported recovery procedure, what findings would
    warrant hardware inspection or replacement?

I’m requesting diagnostic and repair guidance first. I’m willing to
provide further logs and perform controlled tests, and would like
advice on whether this should also become a firmware-tracker issue or
a private hardware-support case.

Thanks,
X

2

Another user recently reported the same PD firmware issue on an AI 300 board.

There are knowledgeable individuals here, but Framework’s email support is the best place to get official assistance with this. Please do keep this updated as you investigate and resolve the issue though to document the results.

Edit: Agreed regarding the SoftwareFirmwareIssueTracker mentioned below.

1 Like
3

With all the information that has been gathered and data collected, this would be a worthy issue to post on the Framework GitHub account under BIOS issues that can be successfully tracked. Others can contribute to it as well so the root cause is flushed out.

Something is hard coded to look for that version number or greater and it is being misread somewhere in the chain of communication.

This may be related to another issue (though I think it is on the 13 model) where one of the controllers is reverting to a previous BIOS after being successfully updated to the newest version.

4

I would suggest running that command multiple times, to see if the answers change.
The EC talks to the PD chip over i2c.
The EC firmware has bugs that make its use of i2c a little unreliable at times.
So, running the command multiple times, might demonstrate that.

Note: I have a fix for the bug in the EC source code.

5
1 Like
6

I’m currently experiencing the same error on my FW 16 (7840HS + RX7700S).

The linked github issue suggests that it might be a problem on the I²C bus. If this is actually the case, does someone here know of a good point to electrically access the bus? I have a pretty good logic analyzer (Saleae Logic Pro 16) available and could try to capture the communication during the initialization.