M5 Max 16-inch (J716c): runtime ADT for a board tree

@edimoldovan

I have a 16-inch M5 Max (Mac17,6, J716cAP), the sibling of the 14-inch J714c that @edimoldovan has booting on his t6050-j714c branch. It's my main machine, so I can't run m1n1 on it, but I rebuilt its runtime ADT from macOS's IODeviceTree plane into m1n1's raw format, and m1n1's adt.py parses it.

j716c-adt.bin and j716c-adt.txt, from macOS 27.0.1 (26A434) with iBoot 20457.1.29
t6051-pmgr.dtsi, 295 power domains generated from it with betizzel/omarchy-m5's adt2pmgr.py
ioreg2adt.py, so anyone with another M5 board can do the same from macOS

Serials, MAC addresses, nonces, the ECID and the boot-security parts of /chosen are left out, and removed.txt lists every property that was. The macOS copy can't show which power domains are on at handover.

I can run anything else read-only from macOS on it.

j716c-adt.zip

@maralcbr

@maralcbr @DjDeveloperr, tagging you since you're on the M5 work here.

I have all my changes in these

But stuck for the moment with this: secondary cores are not fixable loader-side. The SPTM cryptographically binds EL1 code execution to the Apple-signed kernel image; there’s no runtime path to grant it to Linux from any context a loader can reach. This is the same wall that blocks CS domain power and core-start, now understood at its root. The only theoretical escapes need Apple to sign a third-party kernel, an Image4/coreTrust break, or an Apple SPTM change. Hit the same issue with the GPU.

@birkskyum

Here's a runtime ADT from a base M5: a 15-inch MacBook Air, Mac17,4, J815AP, T8142 (chip-id 0x8142, board-id 0x26), with 10 CPUs and 32 GB. It was captured from macOS 26.5.1 (25F80), firmware mBoot-18000.120.36, using the same method as the J716c capture above.

j815-adt.bin and j815-adt.txt: m1n1's adt.py parses all 169 nodes, including pmgr, sgx/gfx-asc, DCP, ANS, SMC, AOP, MTP and all ten CPUs.
removed.txt lists the 170 properties and nodes that were removed. The rules are @birkskyum's, from ioreg2adt.py. I also checked that none of the 44 identifying values in the full capture appear in the blob.
m5air-adt.py is the conversion I ran. It's a rewrite of ioreg2adt.py with the same rules.

This doesn't change the SPTM finding above. It just gives whoever takes on the base-M5 boards a tree to start from. The Air stays on macOS, and I can run other read-only commands on it if they'd help.

j815-adt.zip

@edimoldovan

An update on the base M5 15-inch Air (J815, T8142) from my last comment. It isn't behind the SPTM wall. Linux now boots on it with all ten cores. That matches aurora-silicon's J813 (13-inch M5 Air) work. The wall @edimoldovan describes is on the M5 Pro/Max (T6050/T6051). My last comment should have said so.

Boot chain. The Air runs macOS 26.5.1 (25F80). An Omarchy developer installer put aurora-silicon/aura ea46479 in place as its Stage 1, with a 5-second USB proxy window. Everything below ran from RAM over that USB-C proxy. Nothing was written to the Air's disk.

SMP in aura. I ran validate_t8142_smp.py, changed in two ways: it accepts Mac17,4, and it accepts aura's USB proxy as well as KIS. Aura started CPUs 0–5 and 7–9 from boot CPU 6. Every core passed 20 of 20 computations, and the result was "pass": true with none missing.

Linux. I used aurora-silicon/linux integration/aurora at 67c64c8, built -aurora-j815-wip on arm64. The J815 tree is t8142-j813.dts with apple,j815, the 15-inch model string, and the display, peripherals and USB includes removed. That leaves CPUs, AIC, timers, DockChannel and simplefb. I loaded it with aura's linux.py:

earlycon=dockchannel,0x38812c000 console=ttyDC0 console=tty0 keep_bootcon fbcon=font:TER16x32 maxcpus=10 rdinit=/init panic=0

The BusyBox initramfs printed this on the panel:

Linux 7.3.0-aurora-j815-wip+ #1 SMP PREEMPT … aarch64. The compatibles were apple,j815, apple,t8142, apple,arm-platform.
online: 0-9. Timer, IPI and function-call interrupts counted on every CPU.
Uptime went from 0.03 to 2.03 across a 2-second sleep.
MemTotal was 32452304 kB.
simplefb ran at 2880x1800, x2r10g10b10, and fbcon took over.
Ten jobs ran, each pinned with taskset to one CPU. Each hashed 16 MiB of zeros, and all ten gave 080acf35…b719643e, the same as the J813 reference in apple-j813.rst.

The Air's 26.5.1 firmware has no trouble with this path, and neither does the boot chain installed from macOS.

Hashes:

013e943d3aa199146ab86ed7ec119e7da77a915c65e954116ba922a55ba54b81  Image.gz
791908792a619e824fc73174f8078d969e608dfb6cd82bb0d7bf066e055722b9  t8142-j815.dtb
af9328279d288c3766b921b5f0ef98c9553017de06fd7ecc4e0387ddc740cbe4  initramfs.cpio.gz
67438ef1b77db962bddbd905245722039bb708b37e2c138db86392b55c20628b  kernel.config

Two build notes:

At 67c64c8, the J813 fragment in arch/arm64/configs/j813.config doesn't build. allnoconfig leaves CONFIG_ARM64_APPLE_X86_FP off, but arch/arm64/kernel/signal.c calls apple_afp_enabled(), which asm/processor.h only declares under that option. I set CONFIG_ARM64_APPLE_X86_FP=y and CONFIG_ARM64_APPLE_X86_FLAGS=y to build.
BusyBox 1.37.0's defconfig needs SHA1_HWACCEL and SHA256_HWACCEL turned off on arm64.

Not tried yet on J815: the DCP display, MTP keyboard and trackpad, and USB. The 15-inch panel and trackpad will need checking against the J815 ADT. I can run more tests on the Air, since it's a spare machine.

@birkskyum

GPU status on the 14-inch M5 Max (J714c, T6050), for reference.

Short version: the GPU firmware and driver come up, but no GPU job runs yet. Jobs stall because the GPU's CS power domain stays off. CS needs the PMP, and the PMP is not running when Linux boots.

Working

The asahi G17 driver, with the G17C/HAL300 firmware interface, initializes both GPU coprocessors and registers the DRM device.
The firmware register map matches what macOS's AGXG17X hands the firmware on this machine.
Aurora Mesa's M5 path, with an exact G17C admission (chip 0x6050, 4 clusters) under ASAHI_M5_BRINGUP=1, opens "Apple M5 Max (G17C B1)", compiles compute and graphics pipelines, and submits work.

Where it stops

The firmware accepts the kick, then waits in agfKSMKickQueuesSchedulingPause; the pause is never acknowledged. Compute jobs and render passes both stall there. Mesa starts a render pass with a compute helper.

Register	Value	Meaning
sgx+0x211c8	0x5	pause requested (bit 0)
sgx+0x211d0	0x4	acknowledge (bit 0) never set

GPU-related PMGR domains while the job is stuck:

Domain	Address	Value	State
gpx	0x23_00e8_0000	0x1f0003ff	on
afr	0x23_00e8_0100	0x1404034f	target on, auto (actual 4)
cs	0x23_00e8_0108	0x0f000300	off; ignores writes
gfx	0x23_00e8_0110	0x1f0403ff	on
aic_gfx	0x23_8060_0108	0x00000200	off
pms_gfx_c1ppt	0x23_8060_0110	0x000000ff	on
soc_dpe_gfx	0x23_8060_0118	0x000000ff	on
b2b_ctrl_gfx	0x23_8060_0128	0x00000200	off
fppt_gfx	0x23_8060_0198	0x0f000200	off

Forcing cs, aic_gfx, b2b_ctrl_gfx and fppt_gfx on with apple,always-on brings up all but cs. For cs the PMGR driver logs PS cs: Failed to reach power state 0xf (requested 0xf00000f, now: 0xf000300).
The ADT entry for CS (name 'CS', id1 16, id2 361, group 3, offset 0x108) has notify_pmp = true, with parents 360 (AFR) and 359.

PMP

What	Address	Value
ps_pmp power domain	0x2_8060_0128	0x0f0000ff (on)
PMP firmware memory (pmp0 reg[2], 1 MiB)	0x2_8450_0000	loaded (95715 nonzero words), unchanged over 3 s
PMP ASC registers (pmp0 reg[0])	0x2_84e0_0000	reading +0x44 raises a SYNC exception in m1n1
PTD window base (pmp0 reg[ptd-update-reg-index 3] − 0x10000)	0x2_8424_0000
PMP-STATUS	+0x10, +0x14	0, 0 (also 2 s later)
SOC-DEV-PS-REQ	+0x1e00	0
SOC-DEV-PS-ACK	+0x1e80	0
PMP-TO-GFX	+0x2b50	0
GFX-TO-SMC	+0x27a0	0

Single 32-bit reads of the PTD window are fine. A 16 KiB bulk read of it took down the m1n1 proxy.

The GPU firmware's register-map slots 10, 9 and 11 (PushTelemetryDashboard read space, update page and config space: 0x2_8424_0000, 0x2_8425_0000, 0x2_8425_8000) are this same PTD window.

J714c ptd-range (/arm-io/pmp0/iop-pmp0-nub, 32-byte entries {id, offset, unk[8], name[16]}; read = offset × 16, write = offset × 8 + 0x10000, as in aura's pmp_assist.py):

id	offset	name	read	write
1	0x0000	NULL	0x0000	0x10000
2	0x0001	PMP-STATUS	0x0010	0x10008
3	0x0008	DVFS-STATE	0x0080	0x10040
4	0x000c	PMPTOOL	0x00c0	0x10060
5	0x0010	PMS-PMGR-PKT	0x0100	0x10080
6	0x0018	PMS-DPE-PKT	0x0180	0x100c0
7	0x0038	PMS-DEVC-PKT	0x0380	0x101c0
8	0x0080	PMS-PWRS-PKT	0x0800	0x10400
9	0x0090	SOC-DEV-PKT	0x0900	0x10480
10	0x01e0	SOC-DEV-PS-REQ	0x1e00	0x10f00
11	0x01e8	SOC-DEV-PS-ACK	0x1e80	0x10f40
12	0x01f0	SOC-DEV-DVFS	0x1f00	0x10f80
13	0x0220	SOC-DEV-BWR	0x2200	0x11100
14	0x023a	DVFS-DIE-TO-DIE	0x23a0	0x111d0
15	0x023c	MC-DRV-TO-CTRL	0x23c0	0x111e0
16	0x0258	FAST-DIE-CE	0x2580	0x112c0
17	0x025a	SMC-TO-PPM	0x25a0	0x112d0
18	0x0261	MC-CTRL-TO-DRV	0x2610	0x11308
19	0x026a	LTS-VOLT-CAP	0x26a0	0x11350
24	0x0270	PPM-TO-SMC	0x2700	0x11380
25	0x0275	CLPC-TO-SMC	0x2750	0x113a8
26	0x027a	GFX-TO-SMC	0x27a0	0x113d0
27	0x029a	FAST-DIE-TO-SMC	0x29a0	0x114d0
28	0x02a3	MC-CTRL-TO-SMC	0x2a30	0x11518
29	0x02a4	ANE-TO-SMC	0x2a40	0x11520
32	0x02b4	LTS-TO-GFX	0x2b40	0x115a0
33	0x02b5	PMP-TO-GFX	0x2b50	0x115a8
34	0x02b6	PMU-TO-GFX	0x2b60	0x115b0
40	0x0320	PMS-VIRT-CNTR	0x3200	0x11900

Questions

Has anyone seen PMP-STATUS non-zero on T6050/T6051 outside macOS, or started the PMP there?
@birkskyum, if it's easy from macOS: does J716c's iop-pmp0-nub ptd-range match the J714c table above?

Thanks @scottjones for the J815 result and @birkskyum for the J716c ADT. Aura's PMP tools gave us the PTD layout.

Yes, it matches. J716c's /arm-io/pmp0/iop-pmp0-nub ptd-range has the same 29 entries as your J714c table, with the same ids, offsets and names, so the read and write offsets are the same too. pmp0 has the same reg offsets as well (0x84e00000, 0x84850000, 0x84500000 and 0x84250000 under arm-io, ptd-update-reg-index = 3).

One thing that may help with the layout: the first of the two unknown words is each range's length in offset units. SOC-DEV-PKT's is 0x150, which ends where SOC-DEV-PS-REQ starts, and DVFS-STATE through PMS-PWRS-PKT line up the same way. The second word is non-zero only on PMP-STATUS (16), FAST-DIE-CE (12), SMC-TO-PPM (13), LTS-VOLT-CAP (10), PPM-TO-SMC (14), CLPC-TO-SMC (15) and PMP-TO-GFX (11).

This is from the ADT attached above, so nothing new ran on the Mac.

@birkskyum

Secondary-core status on J714c (T6050). This replaces the SPTM explanation from my earlier comment.

Short version: a secondary core powers up but is never released from reset. On T6050 the release goes through the PMP coprocessor, and the PMP is never started when a loader boots the machine. J716c (T6051) has the same PMP layout (thanks @birkskyum), so this likely applies to both.

Symptom: a secondary powers up (its PS reg reads the running pattern 0xef20d102), and its RVBAR is correct and identical to the boot CPU's, yet it never fetches its first instruction or reaches SPTM reset_entry. That points to reset release, not execute permission.

Ruled out (T6050 vs T8142: SPTM, iBoot j714c/j813, DeviceTree j714cap/j813ap):

The SPTM per-core path (reset_entry, GXF bootstrap, register_cpu, CTXR/SPRR writer, sptm_retype) is byte-identical apart from relocations and the CPU-table bound, with no chip, fuse or DT branch.
For a raw loader the SPTM isn't active: GXF_CONFIG_EL1 = 0, and the /chosen SPTM ranges are absent.
No device-tree property gates fetch on either chip.

The T6050 difference:

pmgr has function-pmp_control on T8142 but not on T6050. On T8142 the core release is driven from pmgr registers a loader can write at EL2. On T6050 it moved into the PMP coprocessor (/arm-io/pmp0; the IPSW template also lists pmp1), which has to be booted.
On our boot the PMP is never started. PMP-STATUS, SOC-DEV-PS-REQ/ACK and PMP-TO-GFX read zero and don't change; the firmware is present but not running.
The per-core ACC/impl register window (cpu-impl-reg, acc-impl-reg, cpm-impl-reg, cpu-uttdbg-reg, coresight-reg) SErrors from EL2 at every offset except +0x0 (RVBAR) and +0x100, on the running cpu0 too: a chip-wide access lock, not a per-core state.

We read this as T6050/T6051 silicon or reset-firmware access state that a loader can't reach from EL2. The GPU's cs power domain (notify_pmp) most likely stays off for the same reason.

Where another data point would help:

cpu-impl-reg + 0x100 is the one other per-core offset readable from EL2. If anyone with a live T6050 (@betizzel?) can compare it on the boot CPU and a stuck secondary: a difference is the one EL2 lever left; identical values mean the release is entirely PMP-side.
If anyone has booted the T6050 PMP, that unlocks both SMP and the GPU. The M1–M3 host start (aura's pmp_init.py: bootargs, start the ASC, endpoint 0x20) needs the PMP ASC registers, which fault on EL2 access for us.

Happy to help test this!

Can you share the exact probe/script and m1n1/aura revision you used, including the access width for cpu-impl-reg + 0x100 and the sequence that leaves the secondary powered but stuck? I can compare the boot CPU against a secondary and report the raw values with my board/firmware details.

@betizzel

@betizzel answers in order. All values below are from a fresh run today; they match our earlier dumps.

1. Probe script. Run against the resident m1n1 proxy; nothing else is loaded:

# M1N1DEVICE=/dev/ttyACM0 PYTHONPATH=m1n1/proxyclient python3 probe.py
from m1n1.setup import *
PM = u.adt["/arm-io/pmgr"].get_reg(0)[0] + 0x88000
def dump(tag):
    print(tag, "pmgr", [hex(p.read32(PM + o)) for o in range(0, 0x14, 4)])
    for n in ["cpu0", "cpu1", "cpu6", "cpu12"]:
        b = u.adt["/cpus/" + n].cpu_impl_reg[0]
        print(tag, n, hex(b), "rvbar", hex(p.read64(b)), "+0x100", hex(p.read64(b + 0x100)))
dump("cold")
p.smp_start_secondaries()
dump("after")

2. m1n1 / aura revision. Upstream AsahiLinux/m1n1 v2.0.0-53-g7cde7d1a, unmodified, installed raw via kmutil --raw --entry-point 2048, running at EL2, USB proxy. No aura. Our fork (https://github.com/edimoldovan/m1n1/tree/t6050-aurora) is what we chainload for Linux boots; it was not used for this probe.

Machine: Mac17,7 / J714c, board-id 0xa, chip-id 0x6050. Same result on the stable channel (macOS 27.0, iBoot-20457.1.29) and the current beta (macOS 27.2 beta, system firmware mBoot-20457.41.3); the values above are from today's run on the beta.

3. Access width. read64 at +0x100, one access covering +0x100 and +0x104. The only other safe access in the window is read64 at +0x0 (RVBAR). Anything else SErrors and hangs the proxy: a memcpy32 from the impl base died at +0x98. We never tried read32 at +0x100, and never wrote it. The pmgr start-block read32s are safe.

4. Sequence that leaves the secondary powered but stuck.

Cold: the pmgr start block (pmgr reg[0] + 0x88000) reads +0x0 = +0x4 = 0x3fffe (every core but cpu0 held).
p.smp_start_secondaries() writes, per core, +0x4 = 1 << (4*cluster + core) and then +0x8 + 4*cluster = 1 << core, and polls the spin table for 100 ms. Every core prints Failed!; m1n1 survives.
The core is now powered (+0x100 changes from 0x0000d800 to the 0xef20… pattern), but it never fetches its first instruction: a stub at RVBAR never runs and smp_is_alive stays false.

The 4*cluster index never clears bits 14–17 on this 6-core-per-cluster chip, hence 0x3c000 afterwards. A manual release of cpu1 with the dense index (+0x4 = 0x2, +0x8 = 0x2) gives the same stuck result.

Our output:

cold pmgr ['0x3fffe', '0x3fffe', '0x0', '0x0', '0x0']
cold cpu0 0x210050000 rvbar 0x100100051c4001 +0x100 0x80802aef201102
cold cpu1 0x210150000 rvbar 0x100100051c4001 +0x100 0x118040000000d800
cold cpu6 0x211050000 rvbar 0x1100100051c4001 +0x100 0x8040000000d800
cold cpu12 0x212050000 rvbar 0x2100100051c4001 +0x100 0x8040000000d800
Starting CPU 1 (0:0:1)... Failed!   [same for CPUs 2..17]
after pmgr ['0x3c000', '0x3c000', '0x0', '0x0', '0x0']
after cpu0 0x210050000 rvbar 0x100100051c4001 +0x100 0x80802aef201102
after cpu1 0x210150000 rvbar 0x100100051c4001 +0x100 0x118080caef20d102
after cpu6 0x211050000 rvbar 0x1100100051c4001 +0x100 0x80804aef205102
after cpu12 0x212050000 rvbar 0x2100100051c4001 +0x100 0x80804aef205102

core	`+0x104 : +0x100` cold	after start
cpu0 (boot, running)	`0x0080802a : 0xef201102`	same
cpu1 (cluster 0)	`0x11804000 : 0x0000d800`	`0x118080ca : 0xef20d102`
cpu6 (cluster 1)	`0x00804000 : 0x0000d800`	`0x0080804a : 0xef205102`
cpu12 (cluster 2, P)	`0x00804000 : 0x0000d800`	`0x0080804a : 0xef205102`

After the start, the secondaries match cpu0 except bits 15:12 of +0x100 (0x1 on cpu0, 0xd on cpu1, 0x5 on cpu6/cpu12) and bits 7:5 of +0x104. We don't know what those fields mean. RVBAR is identical on cpu0 and cpu1 (m1n1's vector base, lock bit set).

Correction to my earlier comment: the 0xef20d102 "running pattern" there is this same +0x100 register.

Full notes: https://github.com/edimoldovan/kernel/blob/master/CPU-START.md and https://github.com/edimoldovan/kernel/blob/master/T6050-CONDITION.md

@edimoldovan

Thanks @edimoldovan , that makes the procedure clear. I checked my existing J714s/Mac17,9 T6050 captures: the boot-core value and the cold-to-start transitions for cpu1, cpu6 and cpu12 exactly match yours, with the secondaries also reporting Failed. These are older captures, not a fresh run of your script; the documented setup was macOS 26.5 firmware and patched m1n1 4184923.

Below I have the newer captures

Fresh run of your supplied cold/start/after probe against my resident m1n1 USB proxy, without chainloading anything.

Setup

t6050-cpu-impl-0100-2026-11-04-j714s.log

• Mac17,9 / J714s, M5 Pro, chip-id 0x6050, board-id 0x8.
• 15 cores: five per cluster; CPU IDs 5, 11 and 17 are absent.
• Resident m1n1: v1.6.1-28-g4184923f-dirty, running at EL2.
• OS and system firmware both report mBoot-18000.120.36.

This is an independent result on an older loader/firmware combination, not a reproduction using your exact revision.

All eight cpu-impl-reg + 0x100 readings match yours bit-for-bit, using read64:

Core Cold After startup attempt
cpu0 0x0080802aef201102 0x0080802aef201102
cpu1 0x118040000000d800 0x118080caef20d102
cpu6 0x008040000000d800 0x0080804aef205102
cpu12 0x008040000000d800 0x0080804aef205102

All 14 secondary startup attempts printed Failed!. The proxy survived, and a subsequent NOP succeeded.

RVBAR was unchanged on all four sampled cores. CPU0 and CPU1 were identical, and all four decoded addresses matched the resident m1n1 base, 0x100042e4000.

The difference is the PMGR held masks; both +0x0 and +0x4 read:

Phase My J714s Your J714c
Cold 0x3fffe 0x3fffe
After 0x3e000 0x3c000

My resulting mask is exactly what the 4*cluster + core indexing predicts for the exposed five-core clusters: the attempted releases cover bits 1–12, leaving bits 13–17 set. This difference does not indicate a successfully started secondary.

No writes to cpu-impl-reg + 0x100, exploratory register scans, or PMP accesses were performed. This confirms the same observed per-core status transitions here; it doesn’t establish the fields’ meanings or the underlying blocker.

I also attached the log too.

A short final summary from my side:

I was able to boot and start Omarchy into Hyperland from a kernel sitting on the NVME partition by m1n1 handing runtime control over
missing secondary CPU cores and GPU make it very slow
USB working in USB2 mode
Keyboard and trackpad also working, there are some keyboard repetition issues, so lileky not perfect
NVME also mounted and working
Networking through USB

Happy to do further testing but for the moment the lack of GPU and secondary CPU cores is blocking me and I haven't yet figured out a way forward.

@edimoldovan

On secondary cores, for @edimoldovan and @betizzel: on my 16-inch M5 Pro (J716s, T6050) all 18
cores now come up, untethered. What fixed it was firmware, not a loader change.

Apple's macOS 27.3 beta 1 release notes (26C5035r), under mBoot > Resolved Issues: "Only a
single core is available when you boot Linux or other third-party operating systems from a
custom raw boot object on Mac computers with M5 Pro, M5 Max, and M5 Ultra chips. (182898702)
(FB23916610)".
Installing 27.3 beta 1 on the main volume is not enough. It only updates LLB
(/chosen/system-firmware-version). The stage 2 that starts the cores comes from the stub's
Preboot restore bundle (/chosen/firmware-version), and a macOS update leaves that alone. I had
to recreate the stub from 27.3 beta 1. An in-place refresh fails at bless with bootpolicy
error 11 "AP boot mode".
After that, firmware-version read mBoot-20457.60.65.0.1, and m1n1's existing T6050 start
sequence started 17/17 secondaries over the proxy. That was main @ 7cde7d1a plus our patches,
none of which touch CPU start. Linux reports
Brought up 1 node, 18 CPUs. Nothing about the PMP changed on our side. I haven't checked
whether the new mBoot starts the PMP. If someone shares the offsets they want, I can do
read-only reads of PMP-STATUS etc. on this stub. That might say something about the GPU cs
domain too.
For an untethered boot with stage-2 on the ESP, three m1n1 patches were needed:
- 0013: relocate above the secondary-only CTRR window;
- 0014: MAX_CPUS 24, to stay under the iBoot raw-image size limit;
- 0015: secondaries' RVBAR is locked to the stage-1 base, so a relocated stage-2 needs a
  trampoline there.

I've only tested a J716s. The J714c result above, on 27.2 beta firmware (mBoot-20457.41.3), matches
what we saw before the fix.

Other J716s results, all tested on hardware:

Trackpad: the host drives the AFE reset (SMC low GPIO gp1c line 28 on J716s).
NVMe: ANS sometimes needs ~3 s for the RTKit handshake, so the 1 s wait fails.
iBoot boot-failure counter: cleared from Linux by building macsmc-reboot in as
poweroff-only. Verified over four boots.
SMC core: RTKit, both GPIO banks, lid/power button, RTC and hwmon all work. The battery
driver (macsmc-power) hangs the machine hard at probe (~7.8 s), so it stays disabled.

Write-up, patches, repro steps and redacted logs: https://github.com/rolotrealanis98/m5pro-linux/blob/main/docs/status-2026-11-05.md (SMP boot log: https://github.com/rolotrealanis98/m5pro-linux/blob/main/docs/logs/01-smp-18-cpus.txt)

Disclosure: the code and reports were produced with Claude (AI) under my direction. I ran the
hardware tests myself.

@rolotrealanis98

This is awesome @rolotrealanis98 ! So the assumption that this was an Apple bug, was correct. need to figure out if I can run the dev beta on the mac with no risk to my work.

@rolotrealanis98

This is awesome @rolotrealanis98 ! So the assumption that this was an Apple bug, was correct. need to figure out if I can run the dev beta on the mac with no risk to my work.

Yep, surprised they even mention the bug fix in their release notes. Im glad apple is putting resources there. The dev betas for golden gate have been pretty solid for me. Most of this beta was focused on siri AI. I havent had issues so far.

Installing 27.3 on the separate volume now, if understand it correctly, that will update the firmware, then I need to re-add m1n1, and hopefully I can reproduce your test.

[Joshua's agent] Thanks, this is the clearest M5 data point we have. The stub-recreation detail matters on our side too: a macOS update only refreshes LLB and leaves the Preboot restore bundle alone, so any firmware check that reads /chosen/firmware-version from an updated main volume reports stale stage-2 firmware. That matches what we saw on the J714c.

On the ANE: yes, we would take you up on the read-only reads. What the M5 ANE work needs, from the same stub:

An ADT dump of the ane and dart-ane nodes (m1n1's proxyclient adt.py): registers, interrupts, power-gates, service-gates, clock-ids, msgbox-mailbox-num, iommu-parent, and from dart-ane the SIDs, vm-base/vm-size and page size.
The pmgr PSD group base and the ANE slot rows inside it. On the M6 these decode as slot rows with block, request, status, valid and diag addresses (for example ANE0_CPU_BLOCKIN and ANE0_SYS_0); we need the M5 rows with their slot numbers.
Read-only reads of those ANE slot request and status registers at the m1n1 stage. The question is whether the stub already starts the ANE power and clock domains, or whether they stay dark until the driver asks.

The J714c is the chip our M5 Max port targets, but a J716s dump is still useful: same T6050 silicon family, and the M6 decode gives us a row-by-row comparison shape.

@joshuaswarren

@joshuaswarren first data from the J716s (16-inch M5 Pro, T6050), taken with macOS 27.3 running as a guest under the m1n1 hypervisor on that machine (single-core guest, the PMP mailbox traced from guest start; decode in m5pro-linux contrib/pending/hv/captures/DECODE-PMP-20261109.md):

The PMP is already running when XNU starts (no SET_IOP_PWR; RTKit HELLO v12, EPMAP 0,1,2,3,4,7 then 0x20, no oslog endpoint). On the application endpoint 0x20 the PMP is the only requester: 3,063 requests each way in 3.5 minutes, the AP just serves GET_IOVA_TABLE (answer 0), MALLOC/FREE (always the same 0x1000 IOVA), ADVERTISE (the AP hands back iop-pmp0-nub ADT properties by size: pm-ptd-ranges, ptd-range, soc-device, ...) and SET_VAL, plus IOReport ping-pongs on a 0x60000 buffer. The AP never originates a voter, floor or device-power command in that window.
The report region is the PTD aperture at 0x284240000, traced directly in a second run (DECODE-PTD-20261109.md): status 0x10, tgt_read 0x1e00, tgt_write 0x10f00, actual 0x1e80, fast_die 0x2580 all behave as apple_pmp_offsets_t6041 describes (stores to 0x10f00 read back 35/35, tgt_read mirrors them). No periodic sweep: 91% of the accesses are one busy-wait on an MC command handshake (0x11220 = 0x1002, 0x11228 = 0x600000, ack 0x2690 = 2) during bring-up; afterwards 36 request-word updates, 119 writes to DVFS entry 0x1f0 (levels 0..14) and a ~98 ms float feed on the CLPC/SMC channel. macOS writes request words before PMP-STATUS is 1 (the driver's comment is wrong for T6050), request bit N = PMGR id1 - 1 up to at least id 37, and no DRAM/fabric floor is ever requested through the PTD (bits 0-11 stay clear). What pmp-report.c lacks for T6050: update 0x10000, dvfs_first 0x1f0, dvfs_count 0x30, the MC command pair, the SMC/PPM/CLPC channels, LTS-VOLT-CAP.
Six PMGR power-state writes precede the first PMP mailbox message (ATC0_COMMON with notify_pmp, FAB8_SOC, UART_P, UART0, ATC0_USB_AON, ATC0_USB).

Tell me which register ranges would help you most next; the hypervisor setup makes a targeted trace a ~10-minute job now.

Finally got WiFi working perfectly

@TripleU613

Finally got WiFi working perfectly

@TripleU613 I had some temperature issues with that, it kept warming up. It turned out the the performance cores were too active and were heating up the wifi chip. The issue only showed up after GPU started working.

@edimoldovan

@edimoldovan

Not by me.

Anyhow, I've decided that since I've already burned through two Claude Max accounts working on this, and I see everyone working on different pieces independently, I might as well take a different approach.

This thread has some collaboration going on, but at the end of the day, there's no clear, central omacom/m4/m5/m6 repo where everything is coming together.

So I'll let y'all continue working on your individual pieces, and I'll be Thanos, collecting all the Infinity Stones into my forked installer:

https://github.com/TripleU613/omarchy-mac-installer

I'll integrate everyone's work, give proper credit to every contributor, and hopefully get everything into a state where we can eventually submit one big PR to the main Mac installer.

Sound good? Or does that sound like, "You guys do all the hard work, and I'll just collect it"? 😂

Kidding, obviously. Getting everyone's work to play nicely together in one kernel and installer is a whole challenge of its own.

At least for the M5 Pro MacBook, I'm already at the final installer stage.

Anyway, genuinely appreciate all the hard work everyone's putting into this. It's pretty awesome seeing so many people tackle different parts of the puzzle.

I think we're finally starting to see the light at the end of the tunnel. No?

@TripleU613

@TripleU613 think we're on the same page, ive also just been going through and adding bits and pieces from everyone's work to mine as well.

People are getting to it faster than me lol

Very thankful for all the work being done

@betizzel

Ok @betizzel so I'll pr to your repo. Add me as collab

@betizzel

Update on the Thanos plan: I've consolidated all my M5 / J714s work into one place, teaming up with @betizzel:

https://github.com/betizzel/omarchy-m5

patches/linux-aurora-installer + patches/m1n1-installer: the J714s kernel/m1n1 my installer image ships (N1 Wi-Fi/BT via the Centauri kernel train, T6050 USB/DP PHY, cpufreq/idle, G17S GPU profile). Byte-exact with the frozen installer sources.
patches/upstream-prs/: my previously open PRs (linux-aurora#414, m1n1#39/External-display sleep: extend qualified behavior without bypassing M3 link guard #40, drm/asahi: J714s G17S voltage profile and fuse-mask guard rolotrealanis98/linux#1, m5pro-linux#1/USB4/Thunderbolt and Type-C display support #2) as git-am series. I closed those PRs so work isn't scattered; everything is preserved there.
installer/: the J714s installer integration as patches on omacom/omarchy-mac-installer, plus the CI-built package bundle as a release.
docs/omarchy-m5-pro/: my J714s status/evidence history.

Next up: merging betizzel's J714s series (DCP, battery, s2idle) with the N1/PHY pieces into one J714s kernel, then rebuilding the image. Credits for @rolotrealanis98 and @edimoldovan are in docs/installer-stones.md. If you'd rather have any of the closed PRs reopened upstream, say so.

J714s (14-inch M5 Pro): Omarchy desktop through the installer chain

Mac17,9 now boots to the Omarchy 4.5.0 desktop through the J714s installer image, using the normal chain:
stage 1 m1n1, ESP stage 2, U-Boot, Limine, UKI.
Kernel 7.3.0-15.j714s2-1-j714s-candidate-ARCH, Hyprland 0.57.1, G17S B1.

The blocker was the shipped uboot-aurora j714s2. It was cross-built on x86_64, and its Image header image_size
(524288) is smaller than the binary (752512), so m1n1's load_kernel() assert reboots, which shows up as a 4 s logo
loop. The same recipe rebuilt natively on aarch64 has a valid header and boots to the desktop.

Details, the two other build fixes (dm_integrity and the optional mt7932 module), and test results: betizzel/omarchy-m5#3

Investigated and written with Claude Code. The owner ran every hardware boot.

@TripleU613

@TripleU613 @betizzel Agreed. I have also been submitting multiple PRs in multiple repos.
One thing that I would add is that @joshuaswarren is trying to help as well with the consolidation.

But it is indeed a little difficult particularly because it touches several repos and I am also trying to submit back to the Aurora repos.

J716c update: all 18 CPUs came online on macOS 27.2.1 firmware (mBoot-20457.41.3) using padded Mach-O Aura Stage 1. A small local patch enabled the USB2 proxy over a standard USB-C cable to an x86 Linux host. N1 Wi-Fi, DHCP, and SSH came back automatically after a tethered reboot. Aurora hardware report.

J716c / Mac17,6 update, still on macOS 27.2.1 firmware:

RAM-only Arch/systemd now reaches accelerated Hyprland on the native 3456×2234 panel. Native GLES/Vulkan work; a 32-frame Vulkan readback checked 24.8 million pixels with zero mismatches. Wayland presentation and all six advertised refresh modes passed software checks.
This builds on Aurora/Erik’s GPU and DCP work. Local changes cover the J716c/G17C 27.2.1 handoff/power integration and guarded shallow WFI. A 10-minute mixed CPU/GPU correctness run passed across all 18 CPUs at bounded frequencies.
Runtime USB serial remains unresolved. A zero-data-endpoint gadget completes configuration successfully on both host and target, while ACM configuration stalls. We’re isolating endpoint setup next; the bootloader USB proxy works.

Reviewed sources and build pins are available in the Linux status document and Aura branch.

These are bounded RAM-boot results, not a completed Omarchy installation. Audio, suspend and usable camera capture remain unqualified.

https://github.com/betizzel/omarchy-m5

btw This is the thanos repo y'all. keep on doing your thing big thanos gonna snatch it up and credit you 🤭

Latest updates, hopefully not repeating myself too much

J714c (MacBook Pro 14", M5 Max) status, since Nov 7

New since the last status, checked in a normal Omarchy login:

GPU: Hyprland renders through the GPU (/dev/dri/renderD128, Mesa's asahi driver), not llvmpipe.
- The driver is aurora-silicon's G17 work with Erik Bourget's M5 port, carried to omacom in omacom/linux-aurora#439.
- Dylan Ironside's (@IronsideXXVI) gpuvm fix for hardware-decoded video is in omacom/linux-aurora#438.
Front camera: 1920×1080 and 2560×1440 capture, and it still works after lid sleep. T6050 support for the ISP and the IMX958 sensor: omacom/linux-aurora#422, on top of aurora-silicon's ISP driver carry, omacom/linux-aurora#421. The installer extracts the IMX958 setfiles: omacom/omarchy-mac-installer#208.
Hardware video decoding: 4K YouTube in Firefox at about 53 frames/s with the CPU about 95 % idle. H.264 through VA-API matches software decoding exactly (bit for bit).
- Kernel: aurora-silicon's AVD driver carried to omacom: omacom/linux-aurora#433.
- Packages: firmware omacom/omarchy-pkgs#2374, VA-API driver name omacom/omarchy-pkgs#2375.
speakersafetyd: its CPU use dropped from 33 % to 5 % of a core. The J714c speaker sense data is now copied in bulk instead of byte by byte from uncached memory (77463cf115c6). The J714 speaker safety profile: omacom/omarchy-mac-pkgs#94.
Temperature: while idle, the performance clusters ran at top speed 30-40 % of the time, which heated the machine and the Wi-Fi chip. PipeWire's realtime threads caused it, because schedutil runs a cluster at full speed while a realtime thread runs. With utilization clamping on (884e2817b7de) and the realtime minimum set to 0 (omacom/omarchy-mac-pkgs#115), that is 0 %, and the fans are back at minimum.
Wi-Fi: the N1's own iwd defaults, 6 GHz included: omacom/omarchy-mac-pkgs#101.
Boot: the kernel unpacks zstd initramfs images (b96202d000ca). Without it, an Omarchy update that switched the initramfs to zstd left a black screen after U-Boot.

Landed upstream:

Wi-Fi/Bluetooth PCIe (aurora-silicon/linux): my six N1 port commits landed in aurora-silicon/linux#1182 by @rolotrealanis98, merged Nov 10. They cover training a port the boot loader left down, the host tunables, no ASPM and a shutdown that holds the port, and DART availability for an adopted port.
Video decoder (aurora-silicon/linux): the J714c decoder node, merged Nov 11 through aurora-silicon/linux#1577 (from aurora-silicon/linux#1322).
Speakers, microphones and jack: merged Nov 9 in aurora-silicon/asahi-audio#20 and aurora-silicon/alsa-ucm-conf-asahi#10.

Open in omacom: base support omacom/linux-aurora#404, boot from disk omacom/m1n1#30, plus the PRs linked above.

Still open:

Deep sleep (suspend-to-RAM): the SoC resets instead of powering down. macOS's own sleep entry is now traced under aura's SPTM hypervisor by Diljit Singh (@DjDeveloperr). aura needed one USB fix on the J714c: 24cae226. Linux now does most of the same steps, starting from Naeem Malik's (@malik-na) M1 work. The current reset is a Linux panic during the entry.

J716c/T6050 update: fixed empty effective_affinity reporting for active hardware interrupts. The kernel now reports CPU0 with the old bootloader routing, and CPUs0–17 with the upstream Aura M5 routing fix, matching independent per-CPU register reads.

Matched RAM-boot tests reproduced the original reporting defect and verified the patch while transferring data successfully. Patch and test evidence.

This corrects kernel reporting; the hardware routing change comes from Aura. The separate USB notification and bulk-transfer stalls remain under investigation.

Navigation Menu

Repository navigation

M5 Max 16-inch (J716c): runtime ADT for a board tree #293

Below I have the newer captures

45 remaining items

J714s (14-inch M5 Pro): Omarchy desktop through the installer chain

J714c (MacBook Pro 14", M5 Max) status, since Nov 7

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

M5 Max 16-inch (J716c): runtime ADT for a board tree #293

Description

Activity

birkskyum commented on Oct 30, 2026

edimoldovan commented on Oct 30, 2026

scottjones commented on Nov 3, 2026

scottjones commented on Nov 3, 2026

edimoldovan commented on Nov 3, 2026

birkskyum commented on Nov 3, 2026

edimoldovan commented on Nov 3, 2026

betizzel commented on Nov 3, 2026

edimoldovan commented on Nov 3, 2026

betizzel commented on Nov 4, 2026

Below I have the newer captures

edimoldovan commented on Nov 5, 2026

rolotrealanis98 commented on Nov 5, 2026

edimoldovan commented on Nov 5, 2026

rolotrealanis98 commented on Nov 5, 2026

edimoldovan commented on Nov 5, 2026

45 remaining items

joshuaswarren commented on Nov 9, 2026

rolotrealanis98 commented on Nov 9, 2026

TripleU613 commented on Nov 9, 2026

edimoldovan commented on Nov 9, 2026

TripleU613 commented on Nov 9, 2026

betizzel commented on Nov 9, 2026

TripleU613 commented on Nov 9, 2026

TripleU613 commented on Nov 9, 2026

FatBoy721 commented on Nov 10, 2026

J714s (14-inch M5 Pro): Omarchy desktop through the installer chain

edimoldovan commented on Nov 10, 2026

cameroncooper commented on Nov 11, 2026

cameroncooper commented on Nov 11, 2026

TripleU613 commented on Nov 11, 2026

edimoldovan commented on Nov 12, 2026

J714c (MacBook Pro 14", M5 Max) status, since Nov 7

cameroncooper commented on Nov 12, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions