Repository navigation
Add guarded J514M/T6034 native graphics bring-up - #372
chriskearney wants to merge 10 commits into
Conversation
837591a to
10a8340
Compare
b32a2ba to
19b6f89
Compare
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>
19b6f89 to
e585531
Compare
|
Hi @chriskearney, @scottjones, 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:
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. |
|
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. |
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 4ca24b658f8ebe7c27375fdf38e41e5daf8632515077b537ca19e6d0dc7704b7Separate 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:f461411f0e6c; that historical failed run remains failed. Manual CI skips commit/DCO checks and is not certification.apple-drm, reported3024x1964@120, completed swaps, and measured the same canonical firmware tuple twice. Its empty table refused GPU admission withEINVAL; no render node or GPU firmware READY was observed. Original kernel and loader were restored and verified.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.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.