-
Notifications
You must be signed in to change notification settings - Fork 0
PMU Firmware Observed Behavior
Per-firmware results from testing the photonicat-pm driver against real hardware. These are evidence for diagnosing an old firmware, not feature gates: the driver detects capabilities at runtime and never consults a version allowlist.
The driver documentation describes firmware that honors the gated features. If a feature there does not work on your board, check the running version first:
cat /sys/kernel/photonicat-pm/pmu_fw_versionOf the versions below, RA2E1260702000 honors both features in the matrix. Flashing instructions are on Home.
The matrix covers the two features that were exercised on more than one firmware. Promotes means the capability reached enabled-probe.
| Firmware version | RTC and scheduled boot | Status LED and beeper control |
|---|---|---|
RA2E1250815002 |
Promotes; scheduled boot works. | Ignored; the PMU acknowledges state 0x01 whatever is requested. |
RA2E1250918000 |
Promotes; scheduled boot works. | Honored. |
RA2E1260306000 |
Stays pending-probe; scheduled boot blocked. |
Honored. |
RA2E1260515000 |
Stays pending-probe; scheduled boot blocked. |
Honored. |
RA2E1260702000 |
Promotes; scheduled boot works. | Honored. |
RA2E1260730001 and RA2E1260813002 are absent because the PMU does not stay on either firmware — see step 5 of Home for the rollback behavior.
Everything below was exercised on RA2E1260702000 and on no other version. The reasons differ, so a blank elsewhere does not mean the same thing in each case.
A capability the vendor added in newer PMU firmware, so the older versions in the matrix were not candidates for it. On RA2E1260702000 it promotes and is honored: values below 50 or above 100 are refused by the PMU, and charging stops once the threshold is reached.
Nothing suggests this varies by firmware version, and it may behave identically on every version in the matrix. It is untested on the others because re-flashing to check costs a firmware cycle per version, not because it is suspected to differ. On RA2E1260702000 it promotes and is honored: only enabled and disabled are accepted, and the initial unconfigured state cannot be restored.
The Power button results below are also from RA2E1260702000 alone, and for the same reason.
Measured on RA2E1260702000 (HW NT2421A4) with the driver in
pmu-button-mode = "input", so the host never powers off on its own, the
protocol ACK for the request suppressed, and heartbeats flowing throughout.
| Press | Firmware behavior |
|---|---|
| Quick tap | Nothing sent. |
| Hold under about two seconds | Nothing sent. |
| Hold of about three seconds | One PMU_REQUEST_SHUTDOWN (0x0D) frame. |
| Hold of about ten seconds | One PMU_REQUEST_SHUTDOWN frame, then nothing for the remaining eight seconds of the hold or afterwards. No repeat frame and no hardware cutoff. |
The frame arrives roughly two to three seconds into the hold. That is bracketed rather than measured directly: the announcement landed 1.2 s before the end of a hold timed at about three seconds and 9.0 s before the end of one timed at about ten, with the hold lengths themselves estimated by hand.
The firmware debounces the button itself, so a stray press in a bag never reaches the host.
After sending PMU_REQUEST_SHUTDOWN the PMU stops sending status reports
(0x07) and cuts power once the force power off timeout has elapsed,
whatever the host does. That timeout is byte 1 of the host's own
WATCHDOG_TIMEOUT_SET (0x13) — the force-poweroff-timeout device tree
property — not a firmware constant:
| Byte 0 (heartbeat watchdog) | Byte 1 (force power off) | Power cut after the press |
|---|---|---|
| 60 | 60 | 62 s |
| 20 | 120 | 125 s |
| 60 | 0 | never — survived 400 s, and status reports never stopped |
Byte 0 does not bound byte 1: at 20 s it never fired, because heartbeats
kept arriving. During the countdown the PMU still answers
WATCHDOG_TIMEOUT_SET with WATCHDOG_TIMEOUT_SET_ACK status 0x00, but
re-sending the configuration does not restart or cancel the countdown —
re-sends at 31 s and 61 s were acknowledged and the cut still landed on
schedule. In the 60/60 run the PMU also dropped the 4G modem's USB rail
41 s in, 21 s before the SoC lost power.
So the host can decline a press; earlier reports that it could not were
measuring the timeout the host itself had configured. Armbian's Photonicat 2
device tree sets force-poweroff-timeout = <60>; the driver's default when
the property is absent is 0. Outside pmu-button-mode = "poweroff" the
driver sends 0 for this timeout while the system is running and restores the
configured value in the shutdown handler, so a declined press is not a power
cut.
On RA2E1260306000 and RA2E1260515000 the hardware RTC reports invalid values, so pmu_rtc_capability never leaves pending-probe. /dev/rtc0 stays registered for ABI stability, but reads report invalid data and alarm programming fails. The driver promotes the capability only after three consecutive valid, advancing RTC samples, so no firmware version string enables RTC or scheduled boot by itself.
On RA2E1250815002 the PMU ignores STATUS_LED_BEEPER_V2_SET (0x9B). Whatever state the driver requests, the PMU answers STATUS_LED_BEEPER_V2_SET_ACK (0x9C) with a constant payload of 0x01: status LED bit set, beeper bit clear. Requesting the LED off and requesting the beeper on are both refused, so neither status_led nor beeper is controllable.
Because the acknowledged beeper bit is stuck at 0, beeper reads 0 while the board still beeps audibly. A 0 there means the PMU reported 0, not that the beeper is silent.
0x9B is the only status LED and beeper command in the protocol; there is no earlier variant to fall back to. The driver builds the state byte and parses the acknowledgement exactly as the vendor manager does. Whether the acknowledged byte is a state or a result code is unsettled: the vendor stores it as state bits but logs it as PMU IO operation status. Under either reading the requested state is not applied.
No tested firmware, RA2E1260702000 included, exposes a trusted API to reset fan control back to PMU auto speed. This is the one limitation that is not version-specific, so the driver README documents it as driver behavior along with the power-cycle workarounds.
RA2E1260702000 refuses VOLTAGE_THRESHOLD_SET (0x17) — the LED, startup, charger limit, auto-shutdown and battery-full voltages the vendor manager configures — for every payload tested: the vendor's own 18-byte layout with plausible voltages, the same layout with zeros, a 16-byte variant, and a short 2-byte payload. There is also no command to read these thresholds back, so a firmware that did accept a write could not be verified. The driver keeps the command number in photonicat-pm.h for raw /dev/pcat-pm-ctl users but never sends it.
pmu_hw_version is reported by the running firmware, not read from a board-independent identifier. The same board reported NT2421A4 under RA2E1260515000 and NT2421A3 under RA2E1250815002. Treat it as a firmware-reported string, not as a board revision.