Skip to content

T8142 (M5): match CPUs by MPIDR, reserve the second CTRR range, log stuck SMP calls - #19

Open
hishamMounir wants to merge 3 commits into
GravityLinux:mainfrom
hishamMounir:j704/t8142-core
Open

hishamMounir wants to merge 3 commits into
GravityLinux:mainfrom
hishamMounir:j704/t8142-core

Conversation

@hishamMounir

Copy link
Copy Markdown

These are three small changes that the T8142 (Apple M5, Mac17,2 / J704) needs to boot Linux with all CPUs.

kboot: match DT CPU nodes to running CPUs by MPIDR

kboot paired DT CPU nodes with live CPUs by position, and bailed on the first MPIDR mismatch. This change looks up the live CPU by the node's MPIDR instead.

  • Trees that list CPUs in order behave exactly as before.
  • A bring-up DT can now list the CPUs in a different order. We needed that on J704 to bring up one specific E-core first while chasing an SMP problem.

kboot: reserve the second CTRR range on t8142

T8142 has a second CTRR instance. It covers the DeviceTree/TrustCache area just below the bootloader, and iBoot leaves it enabled on the secondary cores. If Linux hands one of those pages to a secondary CPU and writes to it, the CPU faults, just as it does for the first instance.

  • main already reserves the first instance on T8142, through the apple_sysregs_unlocked check.
  • This adds the second instance: its two registers (3, 0, 11, 0, 2/3, next to the existing pair) and the reservation itself.
  • It runs only on T8142 and is skipped when the instance reads back zero. Other SoCs are untouched.

How it was found: a native boot oopsed at exactly the first page of a protected range. A read-only sweep of the CTRR system registers on the boot core then gave the second instance's bounds, which cover the DeviceTree and TrustCache.

smp: log once when a call target hasn't taken a call after 1 s

A secondary that never takes a cross-CPU call leaves smp_call4() spinning silently, which looks exactly like a dead board. This change prints the CPU, the call and the target's state once after a second, flushes the console, and then keeps waiting as before. Apart from the message, behaviour is unchanged.

Testing

The test machine was a J704 with iBoot mBoot-20457.41.3.

  • This tree, on current main, was chainloaded into RAM.
  • It booted a Linux 7.1 Asahi kernel (16K pages) with root on the internal SSD.

On the M5, this series needs two other PRs:

Result with this series + #14 + #18:

  • 10 CPUs online.
  • No "has not taken call" message.
  • No oops, SError or DART fault.
  • Keyboard and trackpad work, and USB networking works.
  • The machine stayed up for a 5-minute check.

Limits of this test:

  • On this chainloaded path the second CTRR instance reads back zero, so the new reservation was skipped. It is exercised only on a native boot, where it was found and used with the AsahiLinux-based bootloader. That machine has booted Linux from its SSD this way since mid-October.
  • The MPIDR change runs on every boot. All 9 secondaries are matched and started, and CPU 6 is the boot CPU here.
  • The smp message never fired, as expected.
  • Builds and links with clang and the Rust target, with no warnings in the touched files. clang-format was not run.

Provenance

These changes come from boot failures, m1n1's own error output and live system-register reads on the machine. No Apple binary was disassembled for them, and none of them touches the components listed in my disclosure in #tainted-re.

🤖 Generated with Claude Code

Instead of assuming the DT lists CPUs in the same order as the ADT, look
up the live CPU with the node's MPIDR. Same result for in-order trees;
lets a bring-up DT reorder CPUs (used to boot one specific E-core early
on t8142).

Assisted-By: LLM
Signed-off-by: Hisham Alkhudrawi <hisham.ma.mohammed@gmail.com>
t8142 has a second CTRR instance, covering the DeviceTree/TrustCache area
below the bootloader. iBoot leaves it enabled on the secondary cores, so
Linux crashes when it hands those pages to a secondary CPU and writes to
them, the same way it does for the first instance.

The first instance is already reserved for t8142 through the
apple_sysregs_unlocked feature check. Name the second instance's two
registers (encodings 3, 0, 11, 0, 2/3, next to the existing pair) and
reserve that range too, gated on t8142 and skipped when the instance reads
back zero, so the M4 targets are untouched.

Assisted-By: LLM
Signed-off-by: Hisham Alkhudrawi <hisham.ma.mohammed@gmail.com>
A secondary that never takes a cross-CPU call leaves smp_call4() spinning with
no output at all, which looks exactly like a dead board. Print the CPU, the
call and the target state once after a second, flush the console, and then keep
waiting as before, so the behaviour is unchanged apart from the message.

This was written to chase a first-secondary wedge on J704 (M5) that shows up
roughly one boot in three.

Assisted-By: LLM
Signed-off-by: Hisham Alkhudrawi <hisham.ma.mohammed@gmail.com>
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