MacBook Pro · M5 family

[Acelogic]

MacBook Pro · M5 family

🧭 Hardware directory › M5 category

Important

Public source was audited; hardware qualification remains board-specific. No matching board build target or named-board hardware result was found in the reviewed public Aurora work. The J813 results in M5 MacBook Air do not qualify this product.

Refreshed October 16, 2026. Public PR states, follow-up reports, merge destinations and source were checked. This is an evidence update, not a new physical test. Baseline: linux/aurora-wip@f53454ba0da1; bootloader: m1n1/aurora-wip@f3ac615eb137.

Latest assessment · October 16, 2026

No named-board hardware result was found. New chip-level T6050 (M5 Pro/Max) development is open in DjDeveloperr's APIF series: a guest path under the Aura monitor covering storage, PCIe, power, display, wireless and Type-C. It is build- and host-tested only; no board in this discussion is qualified by it.

Configurations

Board	Silicon / SoC	Configuration	Year	Audit result
J704	M5 · T8142	MacBook Pro 14-inch	2025	⚪ No matching working-tree DTS or named-board runtime result found
J714S	M5 Pro · T6050	MacBook Pro 14-inch	2026	⚪ No matching working-tree DTS or named-board runtime result found
J716S	M5 Pro · T6050	MacBook Pro 16-inch	2026	⚪ No matching working-tree DTS or named-board runtime result found
J714C	M5 Max · T6050	MacBook Pro 14-inch	2026	⚪ No matching working-tree DTS or named-board runtime result found
J716C	M5 Max · T6050	MacBook Pro 16-inch	2026	⚪ No matching working-tree DTS or named-board runtime result found

Evidence key: 🟢 named hardware report · 🔵 code present in the pinned source · 🟠 partial or unqualified · ⚪ no board-specific evidence found. A merge is an integration event, not a hardware test or release qualification.

Hardware assessment

Area	Current evidence
Boot / CPU / memory / interrupts	⚪ No matching board target or named-board runtime report found.
NVMe / USB / PCIe / CPU scaling	⚪ No board-specific public qualification found.
GPU / display / media / audio / camera	⚪ No board-specific public qualification found.
Wireless / input / SEP / Touch ID	⚪ No board-specific public qualification found.
Thermals / suspend / installer	⚪ No complete-system public qualification found.
T6050 chip-level development	🟠 Open, unqualified · DjDeveloperr's stacked APIF series (linux #238, linux #241–linux #257) adds a T6050 path for a Linux guest under the Aura monitor and SPTM: MMIO transport, DART/SART providers, resident ANS NVMe, preinitialized PCIe/MSI, PMP, SPMI, PMU RTC, SMC, fixed DP PHY, a cpufreq profile, N1 Wi-Fi/Bluetooth, firmware-27 DCP, GPIO interrupts and Type-C. All 18 PRs are open; only #238 targets aurora-wip, the rest stack on apif-* branches. Validation is image builds, DT schema checks and host tests (16 TAP cases); every PR says hardware qualification is pending, no board is named, and GPU is out of scope.

Checked the current Apple board target list and public Aurora PRs, including newer M5/M6 work. This is a recorded evidence gap, not a claim that the hardware can never be supported.

🧪 Add a reproducible hardware report

Reply here with one feature or failure per report. Identify the exact row from the configurations table.

Board ID:
SoC ID and chip variant:
Model / screen size / configuration:
Feature or SoC block:
Kernel repository / branch / commit:
m1n1 / U-Boot / Mesa commits, where relevant:
Firmware version:
Steps to reproduce:
Expected result:
Observed result and repeat count:
Public log or artifact URL:
Artifact SHA-256 and command to repeat the check:
Known limits / recovery steps:

Repository admins can update this opening post through ⋯ → Edit. Record the tested board next to each result; leave other boards pending until their evidence is supplied.

---

Keep this product generation together. Discuss shared silicon changes here and link affected sibling products through the hardware directory. A result on one board does not change another board’s status.

Audit baseline: f53454ba0da1; public source and PR reports checked October 16, 2026. No new physical test was performed for this update. Working-tree integration does not imply an aurora-stable release.

PR state and integration audit · October 16, 2026

PR	GitHub state	Destination / target branch	Integration evidence
linux #238	🟠 Open	aurora-wip	Open development PR; hardware reports retain their tested revisions · 007b579dcd3e
linux #241	🟠 Open	apif-mmio	Open development PR; hardware reports retain their tested revisions · 9ee6782ef9b2
linux #257	🟠 Open	apif-typec-events	Open development PR; hardware reports retain their tested revisions · dd6994712b32

PR state, source integration and hardware qualification are separate. A closed PR is not necessarily merged. Public reports describe their original test kernels, including contributor branches. Repository administrators can edit this opening post.

[MarianoMiguel]

Hi! I have a 16-inch MacBook Pro with an M5 Max: board J716C (Mac17,6, T6050), 18-core CPU (6 Super + 12 Performance), 40-core GPU, 48 GB, 2 TB SSD. It runs macOS 27.0.1 (26A434), and the system firmware and OS loader are both 20457.1.29.

The J716C row has no reports yet, so I'd like to help qualify it.

• I can dedicate this machine to testing for a while and use another Linux box as a daily driver in the meantime. The Linux box can also be the USB host for proxy and chainload runs.
• I can free 512 GB on the internal SSD once there's an install path. Until then I'm leaving the disk layout alone.
• I have a full IODeviceTree dump from macOS 27.0.1 with identifiers removed (serials, ECID, MACs, nonces, NVRAM, boot manifest). I can share it with anyone working on T6050 device trees, or run specific read-only ioreg queries on request.
• I captured an M5 Max macOS baseline with omarchy-mlx's collect_deep.py, including the ANE device-tree nodes (ane,t8132exclave).
• I'm happy to test the APIF series (Add APIF MMIO transport and SPTM guest IOMMU providers #238, nvme: apple: Add resident ANS support over native APIF #241–arm64: Enable APIF platform consumers and document non-GPU M5 Pro coverage #257) on real J716C hardware once there's a v2 Aura build and a guest DT to try.

What would be most useful first?

[MarianoMiguel]

J716C (M5 Max 16") ADT vs. the APIF series

I checked the hardware assumptions in the APIF series (#238, #241–#257) against this machine's ADT. It's read-only from macOS 27.0.1 (26A434), firmware 20457.1.29. No boot was involved, so none of this is a hardware qualification. Board facts: chip-id 0x6050, board-id 0x0e, single die, 3 CPU clusters (2 × 6 M + 1 × 6 P), 8 AMCC × 4 DCS = 32 channels, 48 GiB.

Matches on J716C

PR	Assumption	J716C ADT
#242	apcie,t6050; ECAM = reg[0], PORT0 = reg[16] ≥ 32 KiB, PHY = reg[18] ≥ 16 KiB, INTR2AXI = reg[19] ≥ 16 KiB	✅ 0x1cb0000000+0x10000000, 0x410028000+0x8000, 0x417010000+0x4000, 0x410024000+0x4000 (40 regs, #ports 4)
#242	Port 0 Gen3 x1, behind one DART, tunables ≤ 16 tuples	✅ maximum-link-speed 3, lane-cfg 0, dart-apcie0 only; config/rc 4, gen3/4/5 shadow 3 each
#250	Port-0 endpoint 106b:1900/1901, fn1 1902, fn2 1903	✅ 106b:1901 / 1902 (Wi-Fi) / 1903 (BT)
#248	DP PHY core banks 2–34 at the fixed offsets, span ≥ 0x2c400, extra banks 39–43	✅ All 24 offsets match on every atc-phy0–3; span is exactly 0x2c400; 44 regs each
#248	Required tunables (axi2af, fabric, common-cfg, lioa, lane0/1 rx-clock, rx-eq, auspll)	✅ All present on atc-phy3, the only PHY with atc-lane-config/atc-plug-orientation, no usb-drd3 and no UHBR tables. It looks like the fixed HDMI lane (dp2hdmi-gpio0 exists)
#248/#254	Four two-port external sources	✅ dispext0–3 + dcpext0–3; display-crossbar0 (display-crossbar,t6050) lists atc0–7/dispext0–7 generically, J716C populates 0–3
#238	DART unit ID ≤ 255, ≤ 8 DARTs per master	✅ 43 DARTs, dart-id 0–42; each display master has 2 mappers
#249	5-bit OPP IDs, cluster count from DT	✅ Largest voltage-states* table has 26 entries
#243	DCHD is a u32	✅ 32 channels, dcs-channel-enable-mask 0xffffffff
#255	≤ 512 pins, ≤ 7 IRQ groups	✅ gpio0 221, aop-gpio0 85, nub-gpio0 61; 7 groups each

Gaps and questions

1. Aura NVMe split BAR (not APIF, but blocks SSD boot). J716C has the same split layout that aura mux: apple-display-crossbar: replace the T602x selector fields instead of OR-ing them #1 fixes for J616C: reg[3] NVMMU 0x41dcc0000+0x60010, reg[9] NVMe 0x45dcc0000+0x10000, with nvme-secure-bar and nvme-linear-sq. nvme_init() only widens 64 KiB → 0x30000 for T8140 and T6041, so T6050 should fail with "invalid split BAR geometry". I'd guess it needs the same entry for nvmmu_base == 0x41dcc0000 && nvme_base == 0x45dcc0000, but I can't confirm the linear SQ doorbell at +0x24908 without booting.
2. SD card reader. apcie0 port 1 is a GL9755 (17a0:9755, class 080501, maximum-link-speed 1) behind dart-apcie1. That's out of scope for the port-0-only path, just noting it for the 16".
3. Which Abbey is the RTC? J716C has three Abbey PMUs: abbeyL1 on nub-spmi0, abbeyF1 on nub-spmi2, abbeyF2 on nub-spmi3. All three carry info-rtc* properties. Which one should the producer convert to apple,pmu-rtc for rtc: apple: Add Abbey PMU counter and wake alarm support #246? I assume abbeyL1.
4. CPU part numbers. Add APIF MMIO transport and SPTM guest IOMMU providers #238 adds 0x064/0x065. Aura's midr.h also lists T6051 Sotra-C (0x068/0x069). macOS doesn't expose MIDR_EL1, so I can't tell which this M5 Max reports. I'll post it from the first Aura proxy boot, but if anyone knows the Max uses 0x068/0x069, the idle/delay quirk won't cover it.
5. DART alias budget. External display alone accounts for 12 DARTs here (dart-dcpextN, dart-dispextN, dart-dispextN-isoc for N = 0–3). Do the 16 retained v1 aliases (and the 0x61f20000 external-display alias) already account for dispext2/3, or is that layout sized for the M5 Pro?
6. Per-board values the producer will need: board-id 0x0e, so apple,centauri-platform-id = 0x000e6050 under the net: apple: Add N1 firmware and ACIPC transport over APIF PCI #250 encoding; soc-chip-variant 1; dram-vendor-id 1; dram-size 0xc00000000.

I have the full ADT dump with identifiers removed and can run any specific ioreg query. Happy to test an Aura proxy boot on J716C whenever there's a build to try.

[EliasJernberg]

Hi, I have a 14-inch MacBook Pro with a base M5: board J704 (Mac17,2, T8142), running macOS 27.0.1. I'd like to help qualify it.

The device table on aurorasilicon.org marks J704 as working (boot, storage, Wi-Fi, display, keyboard, trackpad, confirmed 2026-10-21), but this thread says no named-board result exists, and I only find J813 in aurora-silicon/linux. aurora-installer has no j704ap either. Is there J704 work that isn't public yet, or was the status carried over from J813?

From a read-only look at the ADT: the SoC-level addresses (AIC, UART, DockChannel, SMC, MTP, DCP, USB-DRD0, SPMI) match the J813 device tree exactly. The board differs in the 3024×1964 ProMotion panel, HDMI via dcpext/dp2hdmi, the GL9755 SD reader on PCIe, Broadcom BCM4388 C2 Wi-Fi instead of N1, a fan, six speakers and a third Thunderbolt port.

Unless someone already owns J704, my plan is to RAM-boot your J813 stack with a J704 device tree and report back here. Is macOS 26.6.1 still the stub you'd recommend, given that my system firmware is already 27.0.1?