Skip to content

soc: apple: pmp: start the T6050 PMP on bare metal - #1326

Merged
DjDeveloperr merged 5 commits into
integration/aurorafrom
djdev/t6050-pmp
Nov 9, 2026
Merged

DjDeveloperr merged 5 commits into
integration/aurorafrom
djdev/t6050-pmp

Conversation

@DjDeveloperr

@DjDeveloperr DjDeveloperr commented Nov 9, 2026 •

Copy link
Copy Markdown
Contributor

Summary

The T6050 PMP (M5 Pro/Max) can now be started by Linux on the bare-metal boot chain (aura Stage 2), the way T8142's is.

  • pmp: apple,t6050-pmp-v2: 42-bit DMA mask (the PMP DART's window is 1 TiB + 64 GiB, ADT dart-pmp0 vm-base/vm-size), no boot-argument uuid check, and endpoint 7 (CoreAnalytics) not started: unlike T8142's, this firmware never readies it, and waiting fails the probe with -ETIME.
  • dts: the T6050 PMP node as the driver needs it: pmp = firmware SRAM (ADT pmp0 reg[2]), asc = reg[0], the ASC mailbox at +0x8000 (AIC 396-399), the DART's DMA range. Everything stays disabled.
  • pmp-report (added after the first test): apple,t6050-pmp-v2-report with T6041's offsets (the ADT's ptd-range has T6041's entries at the same places), and the T6050 PTD described: read aperture 0x284240000, update page 0x10000 above it (pmp0's ptd-update register), always-on requests for the three CPU clusters, the internal display and storage (reg = soc-device ID - 1). Disabled with the PMP.

iBoot loads the PMP firmware on T6050 without starting it; the driver patches the boot arguments in SRAM and starts it as on the other SoCs.

Tested (J714sAP, M5 Pro, RAM-boot kit on the PR #1012 kit kernel)

With the node enabled plus the board's values (board-id 8, dram-vendor-id from /chosen, apple,pmc 1, apple,pmc-pmgr 63, and the 149 iop-pmp0-nub properties as apple,tunable-*):

  • apple_pmp 284500000.pmp: RTKit: Initializing (protocol version 12), then PMP firmware and endpoint ready 1.6 ms later; a PMC gated on it (apple,pmp) and its CLPC bind after it. No SError, no warning; GPU, cpufreq and the CLPC floors (pmdomain/soc: apple: T6050 DRAM and fabric floors (PMC voters, CLPC, GPU link) #1324) ran as before.
  • With endpoint 7 started (T8142's setting) the probe fails: CoreAnalytics readiness failed: -62.

With the report as well (run pmpr1): apple-pmp-report 284240000.pmp-report: PMP running (status 0x1), requests 0x1000047000, the PMP's own log says io.cpp:61: PMP started, it acknowledges every request bit, and its PMC vote (agent 0) drops from the static DCS 5 / fabric 1 iBoot leaves to 0, where it stays at idle, under a 12-thread memcpy and under GPU work. Without the report that static vote stays, and honouring it cost ~0.9 W at idle (3.15 → 3.93 W total system power); with it, idle with the PMP running and agent 0 honoured is 2.65-2.72 W. CPU and GPU results are unchanged (the CLPC raises the floors under load, #1324).

Not in this PR, and why:

  • No board enables it yet. The PMP now runs its loop but doesn't raise DCS itself for CPU or GPU bandwidth (its GPU request, soc-device 16, isn't made yet: claiming it while nothing powers the GPU crashed the T6041 PMP), so enabling it on J714s changes nothing measurable today. The J714s board values and tunables used for these runs are ready to go up with that.
  • A system sleep with the PMP running needs the sleep path (5378a11's T6050 port, kept separately for the M5 sleep series).

Relation to #475: that PR adds a registry-v2 path for the APIF guest boot; on bare metal the existing registry handling works as it does on T8142, so this is the smaller change.

🤖 Generated with Claude Code

The T6050 PMP DART's window starts at 1 TiB and spans 64 GiB (ADT
dart-pmp0 vm-base and vm-size), as T8142's does, so the firmware gets a
42-bit DMA mask. iBoot loads the firmware without starting it; the
driver starts it as on the other SoCs. Unlike T8142's, this firmware
never readies endpoint 7 (CoreAnalytics): waiting for it fails the probe
with -ETIME, so it isn't started.

Tested on J714s (M5 Pro) with the PMP described as in the following
commit and enabled, board-id, DRAM vendor, PMC boot arguments and the
ADT's iop-pmp0-nub properties as tunables: "PMP firmware and endpoint
ready" 1.6 ms after RTKit init, and a PMC gated on it binds. With
endpoint 7 started the probe failed with -62.

Signed-off-by: Diljit Singh <hey@djdev.me>
The PMP driver maps the firmware's SRAM as "pmp" (ADT pmp0 reg[2]) and
the ASC as "asc" (reg[0]), talks through the ASC mailbox at +0x8000 and
allocates through its DART, whose window starts at 1 TiB and spans
64 GiB (ADT dart-pmp0 vm-base, vm-size). Describe them that way; the
mailbox interrupts are the ADT's four in ascending order, as for the
other T6050 ASC mailboxes. Everything stays disabled: a board enables the
PMP once it supplies the boot arguments and firmware properties.

Signed-off-by: Diljit Singh <hey@djdev.me>
The T6050 PMP node now has the form its driver uses on the other SoCs:
the firmware SRAM and ASC views named "pmp" and "asc", and the ASC
mailbox, with the mailbox interrupts moving to that node. Describe it
that way, keeping the second power domain (PMS SRAM). The node is no
longer required to stay disabled.

Signed-off-by: Diljit Singh <hey@djdev.me>
The T6050 PMP nub's ptd-range lists the PTD entries T6041 has, at the
same places: PMP-STATUS 1, SOC-DEV-PS-REQ 480, SOC-DEV-PS-ACK 488 and
FAST-DIE-CE 600 with three lanes. Use T6041's offsets.

Tested on J714s (M5 Pro) with the report at 0x284240000 and always-on
requests for the three CPU clusters, the internal display and ANS: the
driver reads "PMP running (status 0x1)" and writes requests 0x1000047000,
the PMP acknowledges every bit, and its PMC vote drops from the static
DCS 5 / fabric 1 iBoot leaves to 0 and stays there at idle and under
CPU and GPU load.

Signed-off-by: Diljit Singh <hey@djdev.me>
The host tells the PMP which soc-devices are on through the PTD: the read
aperture at 0x284240000, and the update page 0x10000 above it, which is
pmp0's ptd-update register (ADT reg[3]); together they are the PMGR's
ADT reg[7]. Describe it with always-on requests for the three CPU
clusters, the internal display and storage, the entries it was tested
with. It stays disabled with the PMP.

Signed-off-by: Diljit Singh <hey@djdev.me>
@DjDeveloperr

Copy link
Copy Markdown
Contributor Author

Retested before merging on the M5 Pro (J714sAP, bare metal, SSD boot), kernel 7.3.0-m5-merge: the M5's integration kernel with this round's rebased heads in place of the old ones (every PR's own patch identical to what is merged; logs in work/m5-pr-merge-20261109). CI green.

Before merging, this round (these 14 PRs, #1323 and the rebased #1254/#1306/#938/#1316/#1199) was test-merged in order onto integration/aurora f9cf6f9 with no conflicts: apple-dt-check.sh 414 → 414 warning lines (0 new) over 137 DTBs, all 20 changed bindings pass, and a local host-test run fails only where integration itself fails with this host's newer toolchain. A full arm64 build of the same set on 8d98b7a was clean.

  • With the PMP node disabled (no board enables it), pmp@284e00000 stays disabled and nothing binds; no regression in boot, GPU, cpufreq or the CLPC. The two PMP-report commits are in the retest kernel too (disabled, as in-tree); they were tested enabled by the load lane (run pmpr1, in the description).
  • The dt-checks failure is fixed by b092bd4 (the T6050 branch of apple,pmp.yaml now describes the node's driver form).

🤖 Generated with Claude Code

@DjDeveloperr
DjDeveloperr merged commit 2b57935 into integration/aurora Nov 9, 2026
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant