[malik-na]

Base: omacom/linux-aurora integration/aurora (396f2d6 at time of writing)
Head: malik-na/linux-aurora g15-289-third-j516c-pin-v2 @ ce30ba3
Fixes/relates: #289

What

Adds a third FirmwareBuild to the J516C list in drivers/gpu/drm/asahi/g15/hw/t6031.rs:

• TEXT sha256 125f0497c7904fde87b05a9264a88cf03bdb3572a1715cec91bd0f9b78245544
• TEXT 0x64000, DATA 0x140000, marker 0x5cf28 (same sizes and marker as the two existing entries)
• machine: None, so it stays gated by the existing J516C layout checks, like the other two entries.

The entry name and comment say where the digest was measured. They do not claim it is a distinct firmware build (see maralcbr's wording points on #289 below).

Why

Two J516C MacBook Pro 16" M3 Max owners reported on #289 that the driver refuses the GPU firmware their Mac loads, so the Mac falls back to llvmpipe. Both loaded TEXT 125f0497….

Evidence (as posted on #289)

	Mac 1 (MikeK, via the Omarchy Mac Discord, relayed in the first comment)	Mac 2 (digital-brew)
Model	MacBook Pro 16" M3 Max, 40-core GPU	16-inch M3 Max, 40-core GPU (J516C)
Kernel	7.2.11-11-1-ARCH (aurora11), refused without override	7.2.11-11-90-ARCH (aurora11 + #292 display series; G15 driver unchanged)
iBoot1	mBoot-20457.1.29	mBoot-20457.41.3
iBoot2	iBoot-10151.140.19.700.2	iBoot-10151.140.19.700.2
OS firmware	trailing 14.727.0 in his paste, read as 14.7 + 27.0 (not confirmed)	14.7 (system-fw unknown)
Override	asahi.g15_accept_text_prefix=0x125f0497c7904fde	same
Result	driver loads, render node present, glxgears runs; no compute job, no longer use reported	glxinfo -B: Apple M3 Max (G15C B2), Accelerated: yes, OpenGL 4.6 core / ES 3.2; vulkaninfo: Apple M3 Max (G15C B2); GLES 3.1 compute: 20 dispatches, 0 mismatches, no GL errors, no GPU messages in dmesg; same TEXT digest in 13 journal boots (3 refused, 10 admitted), no faults in any admitted boot; daily use with internal + one external display

Mac 2's probe log line: GPU firmware build admitted by g15_accept_text_prefix: TEXT 0x64000 DATA 0x140000 GKTS 0x5cf28 sha256 125f0497…5544. Its compute run is GL compute; there is no OpenCL ICD on that install.

Boot test of this branch on a J516C

Mac Lab job j1031-185713-2fe6 (M3 Max, J516C) booted the earlier form of this change (6b9cb33, same code, before the rebase and message fix): 3 of 3 tests pass, GPU probed (asahi-g15 …: G15: probing (T6031 G15C), firmware identity accepted, cores enabled [10, 10, 10, 10]).

Limit: that Mac loads the macOS 14.7 stub firmware (the log shows it matched the existing "macOS 14.7 stub firmware (iBoot-10151.140.19.700.2), J516C" entry). The new digest was not exercised there; it only shows the branch boots and the GPU still probes for the existing pins. The rebased commit (ce30ba3) itself has not been booted.

Related

maralcbr's comment on #289 about not treating matching versions or sizes as build identity, and the idea of normalising bounded, validated per-unit fields instead of pinning digests (needs maintainer agreement first): #289 (comment). That comment ties it to the T6030 investigation in #247. This PR is the stopgap that comment calls fine once a compute job and a renderer check pass, which Mac 2 provided.

Checks run on ce30ba3

• checkpatch.pl --strict: 0 errors, 0 warnings, 0 checks
• tools/aurora-ci/check-commits.py (base 396f2d6): Signed-off-by yes, checkpatch clean
• Host tests that read the G15 firmware table: g15-maintained-handoff-tests.py and g15-zero-words-tests.py pass (full host suite not run)

Not tested

• The new digest on a lab Mac or any Mac of ours: no Mac in the lab loads 125f0497….
• The rebased commit booted anywhere (the booted build was the pre-rebase commit; same code).
• Without the override: both reporters' results used asahi.g15_accept_text_prefix, not the pin itself.
• Byte diff of TEXT dumps against the reference J516C, chip revision, cold-vs-warm repeatability (digital-brew did not record which boots were cold).
• OpenCL, and the full omarchy-m-test on the new digest.
• Kernel build of the rebased commit; the full host-test suite.

Assisted-by

Commit carries Assisted-by: Claude:claude-opus-5-5 and Naeem's own Signed-off-by; no agent Signed-off-by, per Documentation/process/coding-assistants.rst.

[unverified: MikeK's report is relayed in the first #289 comment, not first-hand; "14.7 + 27.0" for his Mac is that comment's own guess.]

[scottjones]

We reviewed ce30ba3 on top of 396f2d6, which is the current integration/aurora tip. Thanks for the careful write-up and for keeping the naming to where the digest was measured.

Where the digest comes from. It is the driver's own measurement. digital-brew's probe line from the g15_accept_text_prefix path prints the full sha256, and that is the TEXT hash with the GKTS entropy bytes zeroed, the same value a pin compares. The prefix is 0x125f0497c7904fde, and the digest doesn't duplicate either of the other two rows. Both probe lines on #289 give the full digest, MikeK's relayed from Discord in the issue body and digital-brew's first-hand, and the row matches both.

Layout. We see no risk of picking the wrong layout from this row. FirmwareBuild carries only sizes, marker and digest. Layout, root magic, IOMappings, board images and compute registers are all one per-SoC Config, and boot.rs:501 throws away the build identity::firmware returns. So a pinned build and one admitted by g15_accept_text_prefix run exactly the same code after the lookup. The only difference is an info line instead of a warning. That means the evidence on #289 (glxinfo on the M3 Max renderer, GLES compute with 0 mismatches, 10 admitted boots with no faults) already exercised the path this pin turns on. There is no other per-build table that needs an entry. The m3 KNOWN_IMAGES list covers T6030 and T8122 images, not this one.

The open question is the one maralcbr raised: matching sizes and marker don't prove the firmware ABI is the same. GL compute and daily desktop use cover a lot, but not every firmware path. Sleep, fault recovery and OpenCL weren't run on this digest. We're fine with this as the stopgap #289 agreed to, with the byte diff left for later.

Tests. No host test reads the T6031 firmware list. g15-maintained-handoff-tests.py and g15-zero-words-tests.py read the T6030 table in hw.rs, and the selftest under asahi-g15 tests lookup.rs and matching.rs with synthetic builds. We checked this two ways. We changed the marker and the last digest byte of the new row, and selftest run.py, maintained-handoff, zero-words and display-order all still passed. We also dropped the digest compare in matching.rs, and run.py then failed five lookup and matching tests. So the lookup is well covered but the table isn't. The two existing J516C rows have the same gap, so it's not a blocker. A small check that every T6031 row has a 32-byte digest, the J516C sizes and marker and no duplicates would be a cheap follow-up.

Small wording point, optional. The row comment says both Macs have OS firmware 14.7. For MikeK's Mac that comes from reading "14.727.0" as 14.7 plus 27.0, which hasn't been confirmed. Something like "OS firmware 14.7 on the second" would be more exact.

Hardware. The new digest itself has only been tested through the override on the two reporters' Macs. The lab boot (j1031-185713-2fe6) was the pre-rebase commit on a Mac that loads the 14.7 pin, so it shows that nothing regressed for the existing rows, not that the new pin works. Since the pinned and override paths are identical after the lookup, we don't think that is a problem.

What we ran, from a fresh worktree with Rust 1.85: selftest run.py and g15 input-error, queue-credit, maintained-handoff, zero-words and display-order pass. probe-init, retention, pb-growth and stats-drain wouldn't build on this host (two need Rust 1.93.1, two use features that are unstable in 1.85). None of them read t6031.rs. checkpatch --strict is clean, check-commits.py reports Signed-off-by yes and checkpatch clean, and the commit has Naeem's Signed-off-by and an Assisted-by trailer with no agent sign-off. drivers/gpu/drm/asahi compiles with clang LLVM=1 and Rust 1.85 on aarch64, with the new row in the object. We didn't do the final module link, because that needs a full vmlinux build. CI at ce30ba3 is green, including the boot job, though that job doesn't load this firmware. We didn't boot anything or run anything on hardware.

[scottjones]

Hi Naeem, sorry this one sat. I approved it on 11-03 with CI green, but it never got queued, and it now conflicts with integration/aurora. That's almost certainly #363 (J514C defaults), which merged on 11-07 and reworked the same firmware table in t6031.rs. Every row there now carries a machine:, so this row's machine: None needs a board too.

Could you rebase onto current integration/aurora?

While you're in there, there's new evidence for this digest on the 14" board. Davy (davycardinaal) has a J514C (M3 Max, T6031; os-fw 14.7, macOS 26.6.2) that loads the same TEXT, 125f0497. With asahi.g15_accept_text_prefix=0x125f0497c7904fde the GPU comes up: G15C B2, OpenGL 4.6 accelerated on Mesa 26.3, three healthy boots, about 0.2 s from display-ready to GPU-ready. Without it the GPU is refused (-22). He hasn't tried Vulkan or load yet. Details: omacom/omarchy-mac-pkgs#129 (comment) and omacom/omarchy-mac-pkgs#129 (comment). Our lab J514C loads a different build that's already admitted, so Davy's is the only J514C result we have for this one.

Would you be up for admitting 125f0497 on the J514C as well, bound to apple,j516c and apple,j514c rather than open to any T6031 board? Since a row takes one machine, that probably means two rows, but if you see a cleaner way I'm happy to go with it.

Once it's rebased and CI is green I'll re-review and queue it. Thanks again for the careful work on this.