Skip to content

Add guarded J514M/T6034 native graphics bring-up - #372

Closed
chriskearney wants to merge 10 commits into
chris/j514c-bringup-20261105-7a53from
chris/j514m-t6034-pmp-20261105
Closed

chriskearney wants to merge 10 commits into
chris/j514c-bringup-20261105-7a53from
chris/j514m-t6034-pmp-20261105

Conversation

@chriskearney

@chriskearney chriskearney commented Nov 5, 2026 •

Copy link
Copy Markdown

J514M/T6034 currently remains on the boot framebuffer with its GPU disabled. Add its own display/PMP handoff and G15C profile so normal boot can start native display and admit this machine's measured GPU image without enable flags. Explicit owner disable settings remain available.

This draft is stacked on #363. The profile requires J514M and T6034, measured B1 identity, four ten-slot clusters with 30 enabled cores, and six-channel MCC mapping. It does not admit J516M. T6034 now requires this complete firmware tuple; the generic digest-prefix override cannot bypass it:

TEXT 0x64000 DATA 0x140000 GKTS 0x5cf28 sha256 4ca24b658f8ebe7c27375fdf38e41e5daf8632515077b537ca19e6d0dc7704b7

Separate T6034 startup and OF records let its handed-off halted PMP start when requested, then require the display ACK. The shared DRM component enumeration also recognizes T6034. Selected ADT metadata verifies the request/ACK/status offsets and all 35 ordered device records; SRAM, firmware UUID, PMGR floor and ACK checks remain mandatory.

Validation at 19b6f899f031a55b4d0097201835aa73c5b00fe4:

  • Six maintained host suites and manifest checks pass, including actual production admission, component enumeration/probe and OF-table bodies. Mutants cover missing startup/matches, wrong ACK, missing/shared display slots, wrong board/firmware fields and a forbidden T6034 prefix override.
  • Exact-source CI has passed the tools host suites and KUnit; remaining jobs are in progress. The previous host-fixture compile failure was fixed separately in f461411f0e6c; that historical failed run remains failed. Manual CI skips commit/DCO checks and is not certification.
  • The latest diagnostic boot registered native apple-drm, reported 3024x1964@120, completed swaps, and measured the same canonical firmware tuple twice. Its empty table refused GPU admission with EINVAL; no render node or GPU firmware READY was observed. Original kernel and loader were restored and verified.
  • That diagnostic remains failed. Its checker incorrectly matched GPU firmware build: inside the unsupported-build refusal message. A separate source/log review establishes the measured identity and refusal; it does not rescore the test. Its microphone failure also occurs on the restored original kernel and remains recorded.
  • Diagnostic package configurations match the Aurora14 baseline byte-for-byte. The final pinned-image package is building. GPU startup, native GL/Vulkan pixels, installed-cohort identity and automatic default boot remain pending; no hardware rendering pass is claimed yet.

The 400 MHz boot-clock metadata is not independent proof of the programmed display clock. Firmware reports it below videoClock 402278400; that reporting limitation remains unresolved. Bandwidth/LACS/parity messages also appear on the previously accepted J514C display path. The next hardware scope is a guarded, brief native pixel check; sustained load, clock/bandwidth correctness and power/thermal qualification are not claimed.

J516C power/reference words inherited by the profile remain explicitly unqualified for J514M. They are not a native macOS capture of this machine. Human DCO certification is pending; the agent has added no signoffs. No merge or package-channel release is requested.

@scottjones
scottjones force-pushed the chris/j514c-bringup-20261105-7a53 branch from 837591a to 10a8340 Compare November 7, 2026 03:12
@scottjones
scottjones force-pushed the chris/j514m-t6034-pmp-20261105 branch 2 times, most recently from b32a2ba to 19b6f89 Compare November 7, 2026 03:15
The 14-core M3 Max reports T6034, with four ten-slot G15C clusters and enabled masks yielding 8, 8, 7 and 7 cores. Add an exact J514M/T6034 OF profile, the measured identity pair and B1 silicon revision, and a six-element memory-cache IOMapping with repacked following VAs. Preserve the shared four-cluster command shape and explicitly warn about the inherited, unqualified J516C power reference words.

Propagate the SoC identity into the hardware record and require the separately published T6034 native display before admission. No enable parameter is needed. The firmware build list is intentionally empty until the normal kernel path measures the canonical loaded TEXT digest; empty profiles cannot use the generic prefix escape hatch and cannot start firmware.

Host validation compiles the actual profiles and firmware admission, checks record identity and six-channel mapping, and exercises display ordering and wrong board/SoC refusals with compiled mutants. Existing full T6031 firmware identities remain unchanged. Hardware startup and full ARM64 package validation remain for the coordinated lab run.

Assisted-by: Codex:GPT-6
Signed-off-by: Scott Jones <scottajones@gmail.com>
Add the distinct T6034 DCP, display-subsystem and PMP compatibles used by the J514M handoff. The DCP register layout has eight named regions, including the fifth display window, before its IOP VBAR region.

Assisted-by: Codex:GPT-6
Signed-off-by: Scott Jones <scottajones@gmail.com>
Give the measured J514M and T6034 pair a distinct native-display handoff, exact DCP image UUID and PMP namespace. Keep the checked inherited DART mappings, PMP image and power-state topology before enabling consumers. The native display starts by default only on that board and SoC pair; an explicit owner disable still keeps the framebuffer and GPU firmware off.

Publish and retain its component separately from T6031 so GPU startup cannot follow the wrong display. The IOMFB record requires both the J514M board and T6034 root compatible, and uses boot-framebuffer geometry while logging the first native timings. Unmeasured panel controls stay off.

Host checks run the production default/request helpers and board/image selection, including wrong boards and SoCs, unknown firmware, owner disable, and three failing mutants. Existing DCP panel and J514C default checks pass. Native hardware boot qualification is performed separately by the controller.

Assisted-by: Codex:GPT-6
Signed-off-by: Scott Jones <scottajones@gmail.com>
The fresh J514M ADT identifies the T6031-layout internal DCP, its display DARTs, and the checked PMP firmware, with a 400 MHz disp0 clock. Describe those resources only on J514M, behind distinct T6034 handoff and component compatibles. Keep all native display consumers disabled until the loader and kernel gates admit them.

The device tree preprocesses and compiles. Readback confirms the T6034 DCP, display subsystem and PMP compatibles, the measured 400 MHz clock, and the disabled DCP status.

Assisted-by: Codex:GPT-6
Signed-off-by: Scott Jones <scottajones@gmail.com>
Run the new measured-profile and native-display policy suites in the maintained host-test runner. Pin the Rust profile suite to 1.93.1 and retain the C display suite in the normal tools group. Update the shared display-order description to include T6034.

The manifest discovery and validation checks pass. The T6034 profile and display suites pass with the actual production bodies, including empty-firmware refusal and the display failure mutants.

Assisted-by: Codex:GPT-6
Signed-off-by: Scott Jones <scottajones@gmail.com>
The first J514M native-display diagnostic reached Linux with the validated
DCP/PMP handoff, but DCP returned -ENODEV before starting its RTKit session.
The T6034 report node matched only its T6020 fallback. That observer-only
record does not create a halted-PMP startup owner, so wait_ready() correctly
refused the display request rather than running DCP without an ACK.

Add the exact T6034 report match and a separate startup record. Selected
read-only ADT metadata confirms status index 1, request index 0x200 and ACK
index 0x208, with all 35 soc-device IDs in record order. DISP is ID 17 with
ACK and ANS is ID 34 without ACK. Keep the real firmware, SRAM, PMGR-floor,
PTD-layout and request-ACK checks intact. The PMGR nodes retain the existing
T6031-specific tag on T6034; use that tag for their lookup.

Report explicit disable parameters for both normal-default T6031 and T6034
fallback paths. Compile the production layout records and OF match table
in the registered T6034 host test, with missing-match, missing-startup-owner
and wrong-ACK-aperture mutants. The old table reproduces the missing owner;
the corrected table and all mutants pass. ARM64 LLVM 22 compiles the PMP
object and the KUnit-enabled display gate. The GPU firmware table remains
empty for the next digest-only diagnostic; no firmware startup is admitted.

Fixes: a8dd7fc ("arm64: dts: apple: describe the J514M internal display")
Assisted-by: Codex:GPT-6
Signed-off-by: Scott Jones <scottajones@gmail.com>
The selected powered-identity metadata reports core-mask-0 0x5fc7f5fd and
core-mask-1 0x7b. Splitting that value into four ten-slot clusters gives
[0x1fd, 0x1fd, 0x1fc, 0x1ed], with [8, 8, 7, 7] enabled cores. Correct the
profile comment and use those actual masks in the host fixture instead of
the same-count reference masks. The production profile still admits the
measured hardware IDs and geometry; it does not require an exact fuse mask.

The production-profile host harness passes with the corrected fixture.

Assisted-by: Codex:GPT-6
Signed-off-by: Scott Jones <scottajones@gmail.com>
The second J514M diagnostic reached the PMP display-request ACK, and the
T6034 DCP provider probed successfully. Native DRM still did not publish,
so GPU admission correctly kept firmware stopped. The display master and
DCP provider had their T6034 OF matches, but apple_dcp_id_tbl omitted the
T6034 internal DCP. add_dcp_components() therefore found no component and
returned -ENODEV before master binding. The same table also controls DCP
initialization after binding.

Add the internal T6034 compatible to that shared enumeration table. Keep
availability, board/firmware, PMP ACK, boot-display readiness and GPU
publication ordering checks unchanged. No external display compatible is
added. The frozen J514M DTB has one internal DCP with its direct panel and
no external endpoints; its provider, mailbox, DART, PMGR and PMP wiring was
reviewed alongside all T6031-only selectors in the affected consumers.

Compile the production component table, master/provider OF tables,
add_dcp_components(), apple_dcp_usable() and apple_platform_probe() in the
registered host suite. The old table reproduces the missing component;
the fixed control passes and missing-enumeration, missing-master/provider
binding and lost-availability-filter mutants fail. ARM64 LLVM 22 compiles
apple_drv.o, and all five maintained admission/display host suites pass.
The GPU firmware table remains empty for the next digest-only diagnostic.

Fixes: a8dd7fc ("arm64: dts: apple: describe the J514M internal display")
Assisted-by: Codex:GPT-6
Signed-off-by: Scott Jones <scottajones@gmail.com>
The shared production display-slot selector gained T6034 support, but the
T6030 pthread/sanitizer harness declared only the T6030 and T6031 slots.
Importing the current production body therefore fails to compile every
variant, including the control, on apple_t6034_display. This caused the
host-tools failure in full CI run 42066154106 at 9056262 and reproduces
on the subsequent diagnostic source; the new T6034 suites passed.

Declare the third slot in the host fixture and include it in reset and
non-provider checks. Publish T6034 alongside T6031, check that neither can
satisfy T6030 admission, and verify that withdrawing T6034 preserves the
T6031 owner and both reference counts. Add missing-slot and shared-slot
mutants while retaining all existing compile and runtime requirements.

The sanitizer/pthread control passes 17 boundaries, all ten mutants compile
and fail at runtime, and the maintained runner passes all six related host
suites without skips. Manifest checks pass and checkpatch reports no errors
or warnings. This changes only the host tests; the frozen 1.60343 diagnostic
kernel, configuration, device trees and firmware policy are unchanged.

Fixes: 8a1c538 ("drm/apple: admit J514M native display on normal boots")
Assisted-by: Codex:GPT-6
Signed-off-by: Scott Jones <scottajones@gmail.com>
The 1.60343 diagnostic on J514M reached native apple-drm publication and
reported one canonical loaded TEXT identity twice, then refused GPU
admission with EINVAL before firmware startup. Pin only that exact J514M
row: TEXT 0x64000, DATA 0x140000, GKTS 0x5cf28 and canonical SHA-256
4ca24b658f8ebe7c27375fdf38e41e5daf8632515077b537ca19e6d0dc7704b7.
The raw collector result remains FAILED because its unanchored accepted-
build regex also matched the unsupported-build refusal; the independently
reviewed log and source control flow establish the expected refusal.

Make the internal identity helper's prefix policy explicit. T6034 never
consults g15_accept_text_prefix, including with a nonempty build table;
older profiles keep their existing explicitly requested override behavior.
The exact board/SoC, measured hardware IDs, B1 revision, four-cluster/six-MCC
layout, normal defaults, owner opt-outs and display-before-GPU checks stay.
Inherited J516C power/reference words remain explicitly unqualified.

Compile the actual profile and production lookup against its public row,
rejecting every other board and each changed identity field. Exercise the
production identity helper with a nonempty strict table and verify that it
never reads a matching override prefix. Production admit() mutations catch
both enabling a T6034 prefix and changing the older profiles' policy.
All six related maintained host suites and manifest checks pass; checkpatch
reports no errors or warnings. No firmware images were read or exported.

This is a candidate for a bounded idle/single low-load native pixel probe,
not hardware or power/thermal qualification. R4's new frequency-reporting
warning remains unresolved; the DCP clock rate and timing are unchanged.
No additional hardware action or package build accompanies this commit.

Assisted-by: Codex:GPT-6
Signed-off-by: Scott Jones <scottajones@gmail.com>
@scottjones
scottjones force-pushed the chris/j514m-t6034-pmp-20261105 branch from 19b6f89 to e585531 Compare November 7, 2026 03:38
@Faeric

Faeric commented Nov 7, 2026

Copy link
Copy Markdown

Hi @chriskearney, @scottjones,
I own the J514M (14-inch M3 Max, T6034, 14 CPU / 30 GPU) enrolled in the Mac Lab, so I believe the diagnostic boots for this PR ran on it. Thanks for the work.

The PR notes that the J516C power/reference words are unqualified for J514M and don't come from a native macOS capture of this machine, and that the programmed display clock is still unresolved. I can help with both:

  • macOS is still installed on this Mac, alongside Omarchy (macOS version: 26.6.2 (do I need the last version?).
  • I have a separate Linux x86 host to drive m1n1 over USB-C.
  • I work with a coding agent (Codex or Claude) that can help prepare the host setup, run the tracer scripts and collect and summarize the logs, so the turnaround should be quick. I stay at the keyboard for anything that touches the boot chain.

If a native macOS capture under the m1n1 hypervisor would help qualify the J514M profile (GPU power/reference words, DCP/PMP, display clock), I'm happy to run it. Could you send the tracer and the steps: m1n1 build, required macOS version and what to dump? I'll keep any board data or firmware off-tree and post only hashes, as with the J514C captures on aurora-silicon/linux#363.

I won't touch the default boot path without your go-ahead, and the Mac Lab window stays open in the meantime.

@scottjones

Copy link
Copy Markdown
Collaborator

Hardware results from our Mac lab on a J514M (14" M3 Max, 30-core GPU), kernel built from e585531:

We also booted a combined trial kernel (#363 + #372 + #388 + #400, with m1n1 #23 + #24 + #25, stage2 v1.6.1-473-gd2b8d44b) on four Macs: M3 Air and J504 Vulkan 780/0 bad each, this J514M with Hyprland at 3024x1964@120 and Vulkan 694/0 bad (mesa #32 staged), MacBook Neo wifi soak 9/9. 0 DART faults on all four, every Mac restored to its own stock boot.bin, and no regressions vs stock apart from audio.microphone-signal on the J514M, which fails on stock too.

@maralcbr

maralcbr commented Nov 7, 2026

Copy link
Copy Markdown
Member

Carried as #408 (rebased onto #363, two commits reordered so each one builds), now merged.

@maralcbr maralcbr closed this Nov 7, 2026
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.

4 participants