[chriskearney]

On J516C/T6031, native graphics still needed a manual display option and the GPU had no OF autoload alias. This change requests the native display automatically on exact apple,j516c, adds T6031 GPU autoload, and defers GPU preparation until the native display has completed DRM/client setup and published readiness.

An explicit apple_t6031_display.enable=0 keeps the framebuffer path and the GPU deferred for that boot. Other T6031 boards retain their existing explicit-=1 display path; J514C GPU admission and T6034 support are unchanged. The boot-loader handoff, PMP image/values/topology and firmware checks remain mandatory. Missing, disabled or unpublished native display returns EPROBE_DEFER to the GPU; it is never treated as successful display preparation. No global boot refusal is added.

The shared display code keeps separate T6030/T6031 publication slots, takes references under the publication lock, and withdraws publication before unbind. The existing T6030 PMP startup path is preserved; this does not add a T6031 PMP vote or claim active-GPU forced-unbind safety.

Dependencies and delivery:

• omacom/m1n1#19 supplies the matching J516C DCP + GPU defaults; omacom/omarchy-pkgs#1707 carries its source pin. Explicit per-switch zeroes, master-default opt-out and configuration-loss handling remain effective. GPU-only opt-out does not also opt out of the display.
• linux-aurora#249 replaces the missing J516C board-file dependency with device-tree/ADT data and 14 reference words from one J516C. It must be included in the kernel delivery; its one-machine reference-value limitation remains explicit.
• The installer image must be rebuilt with the matching Stage2 and packages. Updating a source pin does not change an existing image's boot.bin. The first boot loading the new Stage2 applies its defaults; a blanket two-reboot workaround is not required.
• There is no fresh-install/native Max hardware qualification for these changes. Pro firmware issue #247 is separate; no firmware pin is widened in this PR.

Validation at 41aa66da56ba28868732848bc88544bf0c445df4:

• Independent source review and strict patch application matched all five successor files exactly.
• Local switch-path controls pass; five compiled runtime mutants are killed. Independent rejected-option, repeated-resolution and unsupported-board controls pass.
• Existing G15 display-order and threaded T6030 display-admission controls pass, including the eight admission mutants. These are host/source controls, not native GPU tests.
• Kernel CI run 40587694445 passed on this head: CI self-test, plan, commits, device trees, compilation, both host suites, full kernel package, KUnit, emulated boot/module loading and result. The attest job is normally skipped for a PR.
• Retained KUnit results show all 26 T6031 gate cases PASS, including default-board on, explicit-off, missing-marker and option-resolution cases. KUnit and boot validation are CPU/emulation checks, not Max hardware tests.

Native aarch64 builds of 41aa66da combined with #249 at 23a7bd13 and m1n1#19 at 5d17a034 passed boot, GUI smoke and short native GL/VK regression checks on M3 Pro J516S, M1 J293 and M1 Air J313. All three were restored and both final audits were clean. Exact source cohort, results and limitations. No J516C Max or fresh installer was tested. #249's subsequent 79f78916 log-only delta is a separate source/CI review, not the binary booted in those runs.

Follow-up at ca6c77a09ff0cd5a0b29bab93c736ada827dc865 addresses Scott's review:

• Kconfig and gate comments explicitly say that the display-off option also keeps the GPU off.
• An enabled but unpublished display now produces a single G15 waiting message; all return values and admission behavior are unchanged.
• The display-order suite checks one message over repeated preparation and catches the new silent-wait mutant. All seven C scenarios, eight C mutants and two admission mutants pass; threaded T6030 admission controls also pass. The new test fails against the original silent implementation. The code patch passes strict checkpatch; the repository's commit checker passes.
• Successor CI 40619768036 passed at unchanged head ca6c77a0: self-test, plan, commits, device trees, compile, both host suites, full kernel package, KUnit, emulated boot/module loading and result. Attestation is normally skipped for a PR. The owned-Mac boot results above belong to 41aa66da; the successor binary has not been booted by us. The combined J516C cold-boot report is now linked below for maintainer review.

Owner validation: Naeem reports the combined J516C cold boot passed using the exact private 246249.2 kernel/headers and aurora22-1 loader packages, with their hashes checked. He reports an empty m1n1.conf, no kernel enable override or modules-load workaround, standalone disk cold boot, Stage2 5d17a034-dirty, both chosen defaults set, native display, GPU autoload/READY and the normal SDDM/Hyprland desktop on packaged Mesa 7c86130d. This is one owner-operated J516C using his existing unchanged local Stage1; it is not a second reference machine, a fresh installer/image test or an independent root-operated Max run. Maintainer review, coordinated kernel/loader pins and package/image delivery remain separate.

[scottjones]

We checked this at 41aa66d, alone and merged with #249, clean both ways.

What "ready" means here: apple_drm_init() publishes the T6031 display only after drm_dev_register() and drm_client_setup_with_fourcc() (drivers/gpu/drm/apple/apple_drv.c). Until then, asahi_g15_display_prepare() (drivers/gpu/drm/asahi/g15/glue.c:150) returns -EPROBE_DEFER, and admit() (g15/boot.rs:489) stops before it reads the ADT or touches firmware.

If the display never comes up, the GPU stays in deferred probe for the rest of the boot. It doesn't hang, and it doesn't touch the GPU. The only message is the dev_info_once at glue.c:162, which fires only when the display node is disabled. If the node is enabled but the DCP fails to bind, the G15 driver logs nothing.

Before this PR the T6031 GPU did not wait for the display (boot.rs:482-485 on integration/aurora). Now any display failure also keeps the GPU off. For example, the DCP refuses any image other than F493F03E (iomfb_v14_7.c:56). Please check that the 14.8.3 stub the installer uses carries that DCP UUID, and log a line when the GPU is still waiting on a bound but unpublished display.

Notes:

1. apple_t6031_display.enable=0 now also keeps the GPU off, because the GPU waits for the native display. Please say so in the Kconfig help and in the t6030-display-gate.c comment, so nobody uses it as a display-only switch.
2. This doesn't address #189. That hang risk is in m1n1's powered identity read, before Linux starts, so a kernel deferral can't reach it.
3. Installs that already have chosen.asahi,t6031-dcp=1 (the aurora-sep Max variant) move to the native display on this kernel with no m1n1 change. We want that for the release, but it needs to be in the release notes. Installs from the aurora-sep script also have t6031-gpu=0, so they get the native display but still no GPU.
4. None of the new code (the J516C default, the deferral, the autoload) has run on a Max. Naeem's J516C boot set apple_t6031_display.enable=1 and a modules-load file by hand. The cold boot above covers that.

What we ran: g15-display-order-tests.py passes (7 C mutants and 2 admit() mutants caught), and t6030-display-admission-tests.py --mutations passes, on this PR alone and merged with #249. A mutant that returns 0 from asahi_g15_display_prepare() on -EPROBE_DEFER fails the display-order controls. We didn't build the KUnit cases.

[chriskearney]

Boot regression results for the combined changes: all three candidate runs passed and returned to their captured packages, boot files and configuration. Both final restoration audits were clean on each Mac; all leases were released.

Tested source: this PR at 41aa66da56ba28868732848bc88544bf0c445df4 plus #249 at 23a7bd131f1b9978d23038bdd61f46479bc3b51d, over 937b727e; combined tree b0e5038f21e92c0552b1a9c9cb776cd0b87f22f9. Native aarch64 kernel build: 7.2.11-7-246249.1-ARCH. Boot loader: m1n1#19 at 5d17a0348745e755299f2c6455f6f1c31236d66b, built natively from package PR #1707 at 89d0c1f4. Each candidate boot independently showed that kernel and live Stage2 version 5d17a034-dirty.

Machine	Boot	Boot health / GUI smoke / native GL+VK	OMT comparison	GL / VK checked iterations
M3 Pro, J516S	36s	PASS	NO_REGRESSION; 37 pass / 10 fail / 26 skip	5,433 / 4,447; zero wrong pixels
M1 MacBook Pro, J293	30s	PASS	NO_REGRESSION; 39 pass / 10 fail / 24 skip	8,341 / 7,810; zero wrong pixels
M1 Air, J313	27s	PASS	NO_REGRESSION; 40 pass / 7 fail / 26 skip	9,012 / 7,643; zero wrong pixels

OMT's retained failures/skips are historical and unscored for this comparison, not an all-tests-pass claim. The native graphics checks used the already-installed userspace unchanged. They are short job-mode compatibility checks, not performance, CTS, thermal soak or ordinary-login desktop qualification.

The M3 Pro retained its explicit display/GPU owner settings, so this tests its existing enabled path, not a new default/no-config Pro path. M1/Air do not execute the G15 backend. The M3 log retained the previously observed PMP workqueue and DCP lane-count warnings; M1 retained its previously observed SPI-NOR dummy-regulator warning. Exact earlier matches were checked. Air had no new error lines. No new combination regression was identified; these warnings were not suppressed.

On each Mac the guard restored the original Stage2 during the candidate boot's orderly shutdown: one candidate-Stage2 boot, followed by verified original Stage2 f5a82fdb-dirty. Original kernel/package state, protected boot files and configuration were restored. M3 audio remains muted.

No J516C Max was tested here. In particular this does not validate the new Max defaults, #249's Max hardware record on our machines, a fresh installer, or release-wide hardware qualification. #249's later 79f78916 adds only a J516C record-digest log and a documentation correction; its source delta was separately reviewed, but that binary was not booted in these runs. Its CI is tracked separately.

For fresh J516C delivery the pieces are m1n1#19, this display/autoload/readiness change, #249's replacement of the missing board-file dependency, and package #1707, followed by package and installer-image integration. #249 retains a documented one-machine reference-value limit. No firmware pins were widened and nothing was merged or published by this test.

[chriskearney]

Thanks Scott. Addressed the wording and missing diagnostic in ca6c77a0: Kconfig and both gate comments now say the display-off option also keeps the GPU off. An enabled display that has not published readiness gets a dev_info_once explaining that the GPU is waiting. It still returns the same deferral; no firmware or publication checks changed. The repeated-pending control and a new silent-wait mutant cover the message; the other display-order and threaded admission controls remain passing. CI for this successor now passes at ca6c77a0, including the full kernel package, both host suites, KUnit and emulated boot.

For the installer stub, the existing public evidence supports the expected UUID: Naeem's J516C report identifies OS firmware 14.8.3 / stub 23J220 (reported as 14.7 by m1n1) carrying DCP F493F03E-CC40-3D89-9A08-5F259BA2B246. That is the image the current J516C DCP record accepts. The installer's T6031 firmware rules require 14.8.3, and its firmware test metadata identifies the J516C IPSW entry with iBoot 10151.140.19 and SFR 23.10.220. This is source/public metadata plus the author's observation, not a new UUID measurement by us. The second GPU firmware chain's DCP UUID is not established by that evidence. No pin is widened.

#189 now has the Recovery answer. Existing aurora-sep dcp=1,gpu=0 installs getting native display while retaining GPU-off is documented in the related m1n1/package PRs. The combined J516C cold boot and shipped-installer check remain outstanding; our M3 Pro/M1/Air regression results at the preceding kernel head do not replace those.

[maralcbr]

Checked the 41aa66da...ca6c77a0 delta. The new dev_info_once keeps the -EPROBE_DEFER return and the node put, and admission is unchanged. The Kconfig help and gate comments now say the display-off switch also keeps the GPU off. No blockers from me.

I'm holding the merge until the J516C cold boot Scott asked for (#246 + #249 kernel, m1n1#19 stage 2, empty m1n1.conf). For the release notes: on the next kernel bump, existing aurora-sep Max installs (dcp=1,gpu=0) get the native display with no m1n1 change, and the GPU stays off.

[chriskearney]

Concrete inputs for the requested J516C cold boot are now prepared and independently checked. This is test preparation, not a Max boot result or release publication.

Source cohort: this PR at ca6c77a09ff0cd5a0b29bab93c736ada827dc865 plus #249 at 79f789160c73e1413cf817a1fb4c0beb8ac914f7, over 937b727e; exact combined tree a9a2a9af7ee45fd2bbc2b802f04040ddbd7ee98f. Stage2 is m1n1#19 at 5d17a0348745e755299f2c6455f6f1c31236d66b. #249 has since been merged by Marcelo; the prepared source remains that reviewed cohort.

One native aarch64 build completed with the same RC configuration as our preceding test build. The recipe changes are only the test pkgrel and the two source patches/checksums. Private test artifacts:

Package	SHA256
linux-aurora 7.2.11.aurora7-246249.2	b2d08c31893a1ffa3fbd7eacf57a15ebcef0d801c28dd89da2a61bd735c888de
matching headers	2cb41c49190e5d934c9827f79845bf6684c443823f420058c71d02cbf88afbc2
m1n1-aurora 1.6.1.aurora22-1	602b92e689b42283afa2f305914ed8cf85b7a2c0675ed5bc05977a16162ed533

These packages are held privately, not in a published repository. An owner-built equivalent of the same source heads is also useful; identify its source and binaries rather than expecting an independently built package to have the same hash. Our package inspection confirms the T6031 GPU/display autoload aliases, the new diagnostics, and the unchanged configuration. The four focused combined-source suites pass, including their mutations; private hardware-fixture skips remain explicit.

For the owner test:

1. Preserve a verified known-working boot.bin on a Recovery-readable filesystem, check ESP space for the backup/update/temporary files, and keep the working kernel fallback. Recovery guidance. Do not assume boot.bin.old is a working original.
2. Back up and use an empty /etc/m1n1.conf; no owner graphics values, master-default opt-out, kernel apple_t6031_display.enable override of either value, or manual module-loading workaround. Report any Stage1 graphics override rather than modifying Stage1 for this test. Check the aurora-sep updater freeze: a package installation alone may leave the older boot.bin in place.
3. Shut down fully, then power on and boot normally from disk into the greeter/desktop. Record the Limine entry, kernel version and same-boot Stage2 version. For these artifacts they are 7.2.11-7-246249.2-ARCH and 5d17a034-dirty.
4. Confirm both chosen T6031 GPU/display values and, where available, the loader's “by default” messages; automatic module loading; native panel/GPU startup; the standard phram ADT export; DCP/GPU firmware identities; record digest and any faults/refusals. The reviewed Stage2 already provides the ADT export; do not add an off-tree export workaround to turn this into a pass. Render-node numbering may vary.
5. Use the current packaged Mesa/Vulkan (7c86130d source or an identified reviewed successor), without the /opt override, and check the normal greeter/desktop plus short native GL/Vulkan sanity. Report any skipped step or manual workaround separately. No additional opt-out reboot is required for this check.

Please put the first cold-boot result and boot log here. This covers the combined default path on one J516C; it does not establish a new installer installation or wider Max/reference-word qualification. Our M3 Pro/M1 runs and these host/build checks do not replace it.

[malik-na]

J516C (M3 Max 16") cold boot with this PR at ca6c77a0, #249 at 79f78916 and m1n1#19 at 5d17a034, using the private packages from your 02:58Z comment. The joined tar and all three packages matched their SHA256.

Setup: /etc/m1n1.conf empty, so the rebuilt boot.bin has no appended chosen. lines. No apple_t6031_display.enable on the command line, no modules-load file, and the packaged mesa-aurora/vulkan-aurora 7c86130d with nothing from /opt. update-m1n1 ran from the package hook, since this Mac has no updater freeze. Our working boot.bin is kept on the ESP for Recovery, and the linux-aurora-g15 kernel stays in Limine as the fallback. Stage 1 is v1.6.1-dirty, a local build that opens a short USB proxy window at every boot. We haven't set any graphics lines in it, and it went on to the disk by itself.

Boot: full shutdown, power on, default Limine entry linux-aurora.

• uname -r = 7.2.11-7-246249.2-ARCH. Stage 2 is 5d17a034-dirty.
• chosen asahi,t6031-gpu = 1 and asahi,t6031-dcp = 1.
• apple-t6031-display: native display on by default on apple,j516c.
• Firmware UUIDs: gfx=F9BEA4A3-D65B-386D-B884-ECF2DF7B159E, dcp=F493F03E-CC40-3D89-9A08-5F259BA2B246 (dcpext0-3 the same).
• DCP and apple-drm came up natively: eDP-1 at 3456x2234@120, with no "not supported" refusal.
• Autoload worked: asahi loaded without a modules-load file.
• G15:
  • Firmware identity accepted (macOS 14.7, J516C).
  • "board data: T6031 G15C images from the device tree and the ADT sensor rows …", with sha256 7e4096e7c29389ac7f1592a00179789c573ede30bb45171ba5597efa07cc72a1, the same as your machine.
  • Firmware at READY at 1.80 s, and [drm] Initialized asahi at 2.02 s.
  • No "waiting for the T6031 native display" line.
  • No G15 faults, recoveries or rejections.
• Nodes: card0 and renderD128 are asahi-g15; card1 is apple-drm.
• phram: Stage 2 publishes the phram reserved-memory node labelled adt (and m1n1_stage2.log), but this kernel config has # CONFIG_MTD_PHRAM is not set, so no /dev/mtd appears for them.

Desktop: SDDM greeter, then the normal Hyprland desktop on the internal panel.

• glxinfo -B: Apple M3 Max (G15C B2), accelerated, core 4.6, GLES 3.2.
• eglinfo -B: G15C on wayland, gbm, surfaceless and x11.
• vulkaninfo --summary: Apple M3 Max (G15C B2), Borealis, API 1.4.363.
• vkcube (Wayland) and es2gears_wayland ran cleanly, with no new kernel messages.

No manual workaround and no skipped step. This covers one default-path cold boot on one J516C.

Boot log excerpt (display, PMP, DCP, apple-drm, G15)

[    0.000000] Linux version 7.2.11-7-246249.2-ARCH (linux-aurora@archlinux) (clang version 18.1.8, LLD 18.1.8) #1 SMP PREEMPT_DYNAMIC Wed, 28 Oct 2026 02:42:29 +0000
[    0.000000] Kernel command line: root=UUID=4f4d5801-524f-4f54-8000-000000000001 rw rootflags=subvol=@,x-systemd.device-timeout=0 zswap.enabled=0 rootfstype=btrfs user4k=on quiet splash loglevel=0 systemd.show_status=false rd.udev.log_level=0 vt.global_cursor_default=0 plymouth.ignore-serial-consoles
[    0.009316] DMI: SMBIOS 3.7.0 present.
[    0.009321] DMI: Apple Inc. Mac15,9/J516c, BIOS 2026.07-gfe7979927b51-dirty 07/01/2026
[    0.009328] DMI: Memory slots populated: 1/1
[    0.020588] apple-t6031-display: handoff: apple,t6031-handoff dcp 0x1 display 0x1 piodma 0x1; dcp firmware-compat 14.7.0 version 14.7.0 uuid F493F03E-CC40-3D89-9A08-5F259BA2B246; 8 memory regions, 1 OS log
[    0.020603] apple-t6031-display: handoff: PMP values /chosen/asahi,t6031-pmp: board-id 0x46 dram-vendor-id 0x6 tunable-uuid 07FF4C5B-CB2E-3DE6-95FF-3B107D19B7AB, 72 tunables (image pinned: 07FF4C5B-CB2E-3DE6-95FF-3B107D19B7AB)
[    0.020618] apple-t6031-display: handoff: dcp-oslog [mem 0x10004728000-0x10004747fff] no-map
[    0.020624] apple-t6031-display: handoff: dcp-oslog [mem 0x10004708000-0x10004727fff] no-map
[    0.020628] apple-t6031-display: handoff: dcp-oslog [mem 0x100046e8000-0x10004707fff] no-map
[    0.020632] apple-t6031-display: handoff: dcp-oslog [mem 0x100046c8000-0x100046e7fff] no-map
[    0.020636] apple-t6031-display: handoff: dcp-oslog [mem 0x100046a8000-0x100046c7fff] no-map
[    0.020638] apple-t6031-display: handoff: 5 dcp-oslog reservations
[    0.020639] apple-t6031-display: handoff: firmware image gfx=F9BEA4A3-D65B-386D-B884-ECF2DF7B159E
[    0.020640] apple-t6031-display: handoff: firmware image dcp=F493F03E-CC40-3D89-9A08-5F259BA2B246
[    0.020641] apple-t6031-display: handoff: firmware image dcpext0=F493F03E-CC40-3D89-9A08-5F259BA2B246
[    0.020641] apple-t6031-display: handoff: firmware image dcpext1=F493F03E-CC40-3D89-9A08-5F259BA2B246
[    0.020642] apple-t6031-display: handoff: firmware image dcpext2=F493F03E-CC40-3D89-9A08-5F259BA2B246
[    0.020642] apple-t6031-display: handoff: firmware image dcpext3=F493F03E-CC40-3D89-9A08-5F259BA2B246
[    0.020643] apple-t6031-display: handoff: firmware image pmp=07FF4C5B-CB2E-3DE6-95FF-3B107D19B7AB
[    0.020644] apple-t6031-display: native display on by default on apple,j516c; apple_t6031_display.enable=0 keeps the boot framebuffer
[    0.021208] apple-t6031-display: enabled /soc/iommu@38530c000, /soc/iommu@385304000, /soc/mailbox@386c08000, /soc/dcp@386c00000 and /display-subsystem
[    0.021357] apple-t6031-display: PMP: this Mac's 74 values from /chosen/asahi,t6031-pmp on /soc/pmp@290700000
[    0.021361] apple-t6031-display: completed /soc/pmp_report@2903c0000 with its display (/soc/pmp_report@2903c0000/report@10) and storage (/soc/pmp_report@2903c0000/report@21) requests; minimum power state of disp_sys, disp_fe and disp_cpu raised to active; pmp and pms_sram kept on
[    0.069928] apple-pmp-report 2903c0000.pmp_report: T6031 PMP handed over: requests 0x200010000; it starts when a consumer asks for it
[    0.087572] [drm] Initialized simpledrm 1.0.0 for 10bd1485c00.framebuffer on minor 0
[    0.110712] simple-framebuffer 10bd1485c00.framebuffer: [drm] fb0: simpledrmdrmfb frame buffer device
[    0.606586] workqueue: work func apple_pmp_start_work enqueued on deprecated workqueue. Use system_{percpu|dfl}_wq instead.
[    0.607047] apple-pmp-report 2903c0000.pmp_report: PMP halted, firmware 07ff4c5b-cb2e-3de6-95ff-3b107d19b7ab; PTD status 0x0 request 0x200010000 ack 0x0
[    0.607051] apple-pmp-report 2903c0000.pmp_report: starting the PMP with request 0x200010000
[    0.614869] apple_pmp 290700000.pmp: RTKit: Initializing (protocol version 12)
[    0.615721] apple_pmp 290700000.pmp: PMP firmware and endpoint ready
[    1.631856] apple-pmp-report 2903c0000.pmp_report: PMP ready: PTD status 0x1 request 0x200010000 ack 0x200010400
[    1.631902] apple-dcp 386c00000.dcp: PMP running with the display request acknowledged
[    1.632276] apple-dcp 386c00000.dcp: DCP CPU control 0x10 status 0x3000ac
[    1.632536] apple-dcp 386c00000.dcp: RTKit: Initializing (protocol version 12)
[    1.634164] apple-dcp 386c00000.dcp: DCP RTKit session running
[    1.634170] apple-drm display-subsystem: bound 386c00000.dcp (ops dcp_comp_ops [appledrm])
[    1.634937] apple-dcp 386c00000.dcp: DCPLink ready, RPC alignment 64
[    1.642010] apple-dcp 386c00000.dcp: display clock 0: 712000000 Hz
[    1.643559] apple-dcp 386c00000.dcp: display clock 0: 712000000 Hz
[    1.773869] [drm] Initialized apple 1.0.0 for display-subsystem on minor 1
[    1.775833] apple-drm display-subsystem: [drm] fb0: appledrmfb frame buffer device
[    1.788551] asahi-g15 40a400000.gpu: G15: probing (T6031 G15C)
[    1.789751] asahi-g15 40a400000.gpu: GPU firmware build: macOS 14.7 stub firmware (iBoot-10151.140.19.700.2), J516C
[    1.789754] asahi-g15 40a400000.gpu: M3: firmware identity accepted
[    1.789846] asahi-g15 40a400000.gpu: board data: T6031 G15C images from the device tree and the ADT sensor rows, reference maximum power 116739 mW and MTR masks, 1380 MHz top operating point
[    1.789874] asahi-g15 40a400000.gpu: board data sha256 7e4096e7c29389ac7f1592a00179789c573ede30bb45171ba5597efa07cc72a1
[    1.789893] asahi-g15 40a400000.gpu: T6031 G15C admitted, ASC=0x0
[    1.789911] asahi-g15 40a400000.gpu: T6031 G15C: power acknowledged, version=0x7041100 counts=0x21040a core-mask=0xffffffffff
[    1.789913] asahi-g15 40a400000.gpu: T6031 G15C: cores enabled per cluster: [10, 10, 10, 10]
[    1.789998] asahi-g15 40a400000.gpu: G15: UAT leaf self-check passed (9 classes)
[    1.790955] asahi-g15 40a400000.gpu: RTKit: Initializing (protocol version 12)
[    1.791066] asahi-g15 40a400000.gpu: mapped firmware crash storage 0x10001d08000/0x4000
[    1.791145] asahi-g15 40a400000.gpu: MMU: initialized, root[0..2]=0x10bfff7c403 0x10bfff84403 0x10bfff74003
[    1.793420] asahi-g15 40a400000.gpu: idle standby 1500 us from the device tree
[    1.793430] asahi-g15 40a400000.gpu: M3: publishing owned initdata root 0xfffffc204062ff40 (77 pages, 5 L3)
[    1.795845] asahi-g15 40a400000.gpu: M3 firmware readiness: magic=0xabcdabcd flags=1
[    1.797103] asahi-g15 40a400000.gpu: M3: firmware accepted owned initdata and device controls
[    1.797106] asahi-g15 40a400000.gpu: G15: firmware at READY, starting the backend
[    1.850136] apple-dcp 386c00000.dcp: swap 1 complete: surface 1, imported 0, 3726 us
[    2.021137] asahi-g15 40a400000.gpu: G15: PB heap: 64 blocks posted at start, 2 chunks of 16 MiB backed
[    2.021330] asahi-g15 40a400000.gpu: G15: compute graph: work 0xfffffc2d05e37760/0x7021003760 pools 0x7000000000 freelist 0x7005858000 table 0x7005c5f000
[    2.022631] asahi-g15 40a400000.gpu: preemption divisor Globals+0x9b0=0: 0
[    2.022784] [drm] Initialized asahi 0.0.0 for 40a400000.gpu on minor 0

[chriskearney]

One clarification on the ADT side note: CONFIG_MTD_PHRAM=n means there is no MTD device for the export, but G15 does consume it. asahi_g15_adt_phram() locates the reserved-memory phram node labelled adt; adt::copy() / sensor_rows() copy it directly and read the sensor rows. The MTD driver is not a prerequisite, and no configuration change is needed for this successful path.

[chriskearney]

@maralcbr @scottjones The requested combined defaults-only J516C cold boot is reported here at unchanged kernel head ca6c77a0 plus #249 79f78916 and m1n1#19 5d17a034, using the exact hash-checked packages. The report covers an empty m1n1.conf, no enable/module-load/opt-Mesa workaround, standalone cold boot, autoload, native display/GPU and the packaged-Mesa greeter/desktop. This satisfies the specific hardware check requested in the reviews; the one-machine and existing local-Stage1 limits remain explicit. CI here is green and the #189 recovery answer/release notes are linked. Both this PR and m1n1#19 still show REVIEW_REQUIRED; please record the final independent approvals if the evidence meets your requests so they can go through normal merge. Coordinated kernel/loader package pins and installer delivery remain separate.

[maralcbr]

Approving at ca6c77a0. Naeem's cold boot covers exactly the combination we asked for: this head, #249 79f78916 and m1n1#19 5d17a034, hash-checked packages, an empty m1n1.conf and no enable, modules-load or /opt Mesa workaround. Autoload, the native eDP display, the GPU at READY and the SDDM greeter and Hyprland desktop on packaged Mesa all came up. The board-data digest matches Naeem's earlier machine. CI is green, and my earlier comment on the ca6c77a0 delta stands.

Not blockers:

• This is one owner-run J516C with a local Stage 1 (v1.6.1-dirty, USB proxy window). It doesn't qualify stock Stage 1 or a fresh installer.
• CONFIG_MTD_PHRAM=n is fine, since G15 reads the adt reserved-memory node directly. The deprecated-workqueue warning from apple_pmp_start_work is worth a small follow-up.
• Release notes: existing aurora-sep Max installs (dcp=1,gpu=0) get the native display with the GPU still off, and the #189 recovery steps should be linked.

The next kernel pin will also carry #253, which this boot didn't include. Please boot that exact candidate on the J516C and an M3 Pro before or right after it reaches edge.