drm/asahi: g15: pin the cd05 firmware TEXT on the J516S by joelvj · Pull Request #390 · omacom/linux-aurora

joelvj · 2026-11-06T07:08:27Z

On a 16-inch M3 Pro (apple,j516s, T6030), the shipped kernel refuses GPU firmware TEXT cd05af6a828b52e4c2fed20086d3d18a7db42e03a8fd6f8354f9f06e0a61363e, so there's no render node and Hyprland falls back to llvmpipe. This adds a J516S-only row to the T6030 firmware table with the complete measured digest, sizes and marker, so the existing exact lookup admits it without g15_accept_text_prefix.

Rows still pin only on the machine they name, so nothing changes on the J514S or on other machines. #366 pins the same digest on the J514S, and its regression explicitly rejects it on the J516S. This PR covers that J516S case. Both PRs add a row to the same table and refresh the same golden pins, so whichever merges second needs a rebase and one more golden refresh.

Related: #247 (TEXT varies per unit on the same boot chain), omacom/omarchy#17739 (the user-facing report of this exact J516S failure).

Hardware evidence


Machine	MacBook Pro 16" M3 Pro (Nov 2023), `apple,j516s apple,t6030`
`asahi,os-fw-version`	14.7
`asahi,system-fw-version`	15.5
`asahi,iboot1-version` / `iboot2-version`	iBoot-11881.121.1 / iBoot-10151.140.19.700.2
m1n1 stage1 / stage2	v1.6.1-dirty / bc79acc4-dirty
Packages	Omarchy 4.5.0-3, `linux-aurora 7.2.11.aurora14-1`, `m1n1-aurora 1.6.1.aurora22-1`, `mesa-aurora 26.3.0_devel.20261031`, Hyprland 0.56.2

Without the override (every boot):

asahi-g15 292400000.gpu: unsupported GPU firmware build: TEXT 0x5c000 DATA 0x114000 GKTS 0x58e88 sha256 cd05af6a828b52e4c2fed20086d3d18a7db42e03a8fd6f8354f9f06e0a61363e; ...
asahi-g15 292400000.gpu: loaded GFX TEXT identity mismatch: EINVAL
asahi-g15 292400000.gpu: probe with driver asahi-g15 failed with error -22

/dev/dri had only card1, Aquamarine logged CDRMRenderer(drm): Can't create renderer, no matching devices found, and Hyprland sat at about 750% CPU.

With options asahi g15_accept_text_prefix=0xcd05af6a828b52e4 (in the UKI via limine-mkinitcpio):

asahi-g15 292400000.gpu: GPU firmware build admitted by g15_accept_text_prefix: TEXT 0x5c000 DATA 0x114000 GKTS 0x58e88 sha256 cd05af6a828b52e4c2fed20086d3d18a7db42e03a8fd6f8354f9f06e0a61363e
asahi-g15 292400000.gpu: M3: firmware identity accepted
asahi-g15 292400000.gpu: board data: ADT performance states, 1380 MHz top (differs from the reference machine)
asahi-g15 292400000.gpu: T6030 G15S admitted, ASC=0x0
asahi-g15 292400000.gpu: T6030 G15S: cores enabled per cluster: [9, 9]
asahi-g15 292400000.gpu: G15: firmware at READY, starting the backend
[drm] Initialized asahi 0.0.0 for 292400000.gpu on minor 0

renderD128 appeared, Aquamarine logged CDRMRenderer(drm): Using device /dev/dri/card0, and Hyprland dropped to about 2–4% CPU on eDP-1 at 3456×2234@120. After 7 minutes of uptime there were no asahi/G15 errors, faults, timeouts or recoveries in the kernel log. These are short observations, not a benchmark.

Testing

tools/asahi/g15-maintained-handoff-tests.py --mutations (rustc 1.85.0): the actual variant passes, and all five existing mutations fail with their intended messages. The new assertions check the J516S cd05 row's machine, sizes, marker and full digest.
With the original hw.rs and the updated test, the test fails (BUILDS.len() left 3, right 4), so it guards the new row.
tools/asahi/g15-zero-words-tests.py --mutations passes with the refreshed pins. Before refreshing, I confirmed the old hw.rs pin (e9b80be9…) matched the unmodified file. The new pins derive from exactly this 18-line insertion.
The pinned bytes were checked against the digest in the running kernel's admission line.
git diff --check is clean.

Not tested

I haven't built or boot-tested the patched kernel without the override. The runtime evidence above comes from the packaged kernel with the override. I'm happy to boot-test a CI-built package or this branch if a maintainer wants that first.
Vulkan, sustained GPU load, suspend/resume and long-term stability haven't been tested.

Some 16-inch M3 Pro (J516S) units on the 14.7 boot chain load a B0 GPU firmware image whose TEXT digest differs from the pinned J516S row: TEXT 0x5c000, DATA 0x114000, GKTS marker 0x58e88 and TEXT sha256 cd05af6a828b52e4c2fed20086d3d18a7db42e03a8fd6f8354f9f06e0a61363e. The build is refused with "loaded GFX TEXT identity mismatch", so there is no render node and the compositor falls back to llvmpipe. The GPU only starts with the g15_accept_text_prefix bring-up override. Add this build as a J516S-only row. Rows still pin on the machine they name; nothing changes on the J514S or on other machines. Extend the maintained-handoff host test to check the new row and refresh the zero-words golden pins for hw.rs and the T6030 module, which change by exactly this one row. Measured on a J516S (apple,j516s apple,t6030; os-fw 14.7, system-fw 15.5, iBoot2 iBoot-10151.140.19.700.2) with linux-aurora 7.2.11.aurora14-1 and the override: the admission line reports the identical sizes, marker and digest, and the GPU reaches READY with renderD128 present. Link: omacom#247 Link: omacom/omarchy#17739 Signed-off-by: joel cristobal <joelcristobal97@gmail.com>

joelvj · 2026-11-06T08:13:04Z

Boot-tested this PR on the J516S, with no override.

Kernel: this PR's head f800dce (integration/aurora 6a08a08 plus this commit), built from the omarchy-pkgs linux-aurora PKGBUILD and config (LLVM 18, Rust 1.85.0), packaged as a separate linux-aurora-pr390, 7.2.11-0-1-ARCH. I booted it once as its own Limine entry. Its UKI was built without /etc/modprobe.d/asahi-g15.conf, and I checked that its initrd doesn't contain the file. Nothing asahi is on the command line.

Machine: MacBook Pro 16" M3 Pro, apple,j516s apple,t6030, os-fw 14.7, system-fw 15.5, iBoot2 iBoot-10151.140.19.700.2.

Before (packaged 7.2.11.aurora14-1, no override): unsupported GPU firmware build ... sha256 cd05af6a..., loaded GFX TEXT identity mismatch: EINVAL, probe failed with -22, no render node.

With this PR:

asahi-g15 292400000.gpu: G15: probing (T6030 G15S)
asahi-g15 292400000.gpu: GPU firmware build: J516S cd05 firmware (14.7 boot chain)
asahi-g15 292400000.gpu: M3: firmware identity accepted
asahi-g15 292400000.gpu: board data: ADT performance states, 1380 MHz top (differs from the reference machine)
asahi-g15 292400000.gpu: T6030 G15S admitted, ASC=0x0
asahi-g15 292400000.gpu: T6030 G15S: cores enabled per cluster: [9, 9]
asahi-g15 292400000.gpu: M3: firmware accepted owned initdata and device controls
asahi-g15 292400000.gpu: G15: firmware at READY, starting the backend
[drm] Initialized asahi 0.0.0 for 292400000.gpu on minor 0

The build was admitted through the new row; there are no admitted by g15_accept_text_prefix lines. renderD128 is present, and Aquamarine logs CDRMRenderer(drm): Using device /dev/dri/card0. Hyprland is at about 2% CPU on eDP-1 at 3456×2234@120, and the system is 98% idle. That boot has no asahi/G15 errors, faults, timeouts or recoveries.

Caveats:

m1n1 stage 2 still carries the device trees from the packaged 7.2.11-14-1-ARCH, which sorts higher, so the test kernel ran with those rather than its own. The J516S DTB differs between the two trees, and the GPU came up with the aurora14 one.
This was a single short boot (minutes). I haven't tested Vulkan, sustained load or suspend/resume.

scottjones

Thanks for this one, it looks good. The new J516S row matches the J514S cd05 row from #366 byte for byte apart from the machine, it's scoped to apple,j516s only, and the da26 rows and the J514C/J516C tables are untouched. The golden pins were refreshed correctly: g15-zero-words-tests.py and g15-maintained-handoff-tests.py pass with and without --mutations, and removing or altering the row makes them fail. Thanks too for the no-override boot test showing the GPU came up via the new row.

One landing note: #366 (same cd05 build on the 14-inch J514S) should land first, and then #390 needs a small rebase: keep both cd05 rows (J516S at index 4), BUILDS.len() goes from 4 to 5 and BUILDS[3] becomes BUILDS[4] in the handoff test, #366's j516s Refused assertion becomes Pinned(4), and both golden pins get refreshed again. Happy to help with that rebase if it's useful.

Optional: the 411833a7 build from #247 is still unpinned on both boards, so a follow-up for that would be welcome.

RenzoF · 2026-11-09T03:18:21Z

The same TEXT build also turns up on the 14-inch J514S, so the row in this PR could cover it too. It is limited to apple,j516s at the moment.

Machine

MacBook Pro (14-inch, M3 Pro, Nov 2023), Mac15,6, compatible apple,j514s apple,t6030.
Boot chain: 14.7 stub (asahi,os-fw-version 14.7, iBoot iBoot-10151.140.19.700.2), system firmware 26.6.2.
m1n1-aurora 1.6.1.aurora22-1, uboot-aurora 2026.07.aurora6-1, linux-aurora 7.2.11.aurora14-1. Omarchy Mac 4.5, installed with installer 2.3.16.

Without the override

asahi-g15 292400000.gpu: G15: probing (T6030 G15S)
asahi-g15 292400000.gpu: unsupported GPU firmware build: TEXT 0x5c000 DATA 0x114000 GKTS 0x58e88 sha256 cd05af6a828b52e4c2fed20086d3d18a7db42e03a8fd6f8354f9f06e0a61363e; to have it supported, report this line and the macOS version of the boot chain that loaded it
asahi-g15 292400000.gpu: supported: J514S B0 RTKit-2419.140.12 (maintained 14.x handoff)
asahi-g15 292400000.gpu: loaded GFX TEXT identity mismatch: EINVAL
asahi-g15 292400000.gpu: probe with driver asahi-g15 failed with error -22

The digest matches the J516S row in this PR byte for byte (cd05af6a…0a61363e, same TEXT/DATA sizes and GKTS marker). So this J514S unit loads the same image the J516S units do, not the one pinned for the J514S in #286.

With `options asahi g15_accept_text_prefix=0xcd05af6a828b52e4` (and `limine-mkinitcpio`)

asahi-g15 292400000.gpu: M3 firmware readiness: magic=0xabcdabcd flags=1
asahi-g15 292400000.gpu: M3: firmware accepted owned initdata and device controls
asahi-g15 292400000.gpu: G15: firmware at READY, starting the backend
[drm] Initialized asahi 0.0.0 for 292400000.gpu on minor 0

/dev/dri/renderD128 appears, and Aquamarine creates its renderer on it. Hyprland went from CPU compositing to about 1–3% CPU. I haven't tested sustained load or suspend yet.

Suggestion

Could the cd05 row admit the J514S as well, for example apple,j514s alongside apple,j516s? Or, since the row pins the complete digest, it could drop the machine restriction altogether. Either would let J514S units like this one boot with the GPU and without the override.

scottjones · 2026-11-09T03:56:12Z

Thanks for testing this, and for the full digest. Knowing the J514S loads exactly the same cd05 build as the J516S row here is really useful.

The J514S side is already covered: #366 by javanoo6 adds a cd05 row for the J514S with this same build, alongside this PR's J516S row. The two are meant to land together, so nothing needs to change in #390.

Nobody has booted #366's pinned row with the override removed yet. Would you be up for trying it on your machine?

Download the kernel-package-90ea4cff817d792a665af69c693842a3 artifact from drm/asahi: g15: pin J514S cd05 firmware TEXT #366's build run: https://github.com/omacom/linux-aurora/actions/runs/42520714524 (you need to be signed in to GitHub to download artifacts). Its packages/ folder has linux-aurora-7.2.11.aurora15-1.14-aarch64.pkg.tar.zst and the matching headers package.
Install both with sudo pacman -U.
Remove the options asahi g15_accept_text_prefix=... line from the modprobe file you added it to, run limine-mkinitcpio again the same way you did before, and reboot.
Post the asahi-g15 lines from journalctl -k -b | grep -i g15 and say whether /dev/dri/renderD128 is there.

If you have time, results from a sustained GPU load and a suspend/resume would be a bonus.

To go back afterwards, sudo pacman -S linux-aurora linux-aurora-headers reinstalls the released package. Then reboot.

joelvj · 2026-11-09T16:33:47Z

Thanks for this one, it looks good. The new J516S row matches the J514S cd05 row from #366 byte for byte apart from the machine, it's scoped to apple,j516s only, and the da26 rows and the J514C/J516C tables are untouched. The golden pins were refreshed correctly: g15-zero-words-tests.py and g15-maintained-handoff-tests.py pass with and without --mutations, and removing or altering the row makes them fail. Thanks too for the no-override boot test showing the GPU came up via the new row.

One landing note: #366 (same cd05 build on the 14-inch J514S) should land first, and then #390 needs a small rebase: keep both cd05 rows (J516S at index 4), BUILDS.len() goes from 4 to 5 and BUILDS[3] becomes BUILDS[4] in the handoff test, #366's j516s Refused assertion becomes Pinned(4), and both golden pins get refreshed again. Happy to help with that rebase if it's useful.

Optional: the 411833a7 build from #247 is still unpinned on both boards, so a follow-up for that would be welcome.

Hey @scottjones thanks for looking into this one. I dont mind doing the rebase once #366 lands.

RenzoF · 2026-11-09T16:59:49Z

Boot-tested #366's pinned J514S row successfully, with the prefix override removed.

Machine: MacBook Pro 14-inch M3 Pro, November 2023 (apple,j514s / T6030).
Installed both packages from the requested kernel-package-90ea4cff817d792a665af69c693842a3 artifact in run 42520714524: 7.2.11.aurora15-1.14.
Running kernel after reboot: 7.2.11-15-1.14-ARCH.
Removed the options asahi g15_accept_text_prefix=... line and rebuilt the initramfs and Limine UKI. Before reboot, verified that the test UKI contains the new kernel and no active prefix override in its modprobe configuration or command line.
/dev/dri/renderD128 is present after reboot.

Relevant lines from this boot (timestamps omitted):

asahi-g15 292400000.gpu: G15: probing (T6030 G15S)
asahi-g15 292400000.gpu: GPU firmware build: J514S cd05 firmware (14.7 boot chain)
asahi-g15 292400000.gpu: M3: firmware identity accepted
asahi-g15 292400000.gpu: board data: ADT performance states, 1380 MHz top (differs from the reference machine)
asahi-g15 292400000.gpu: T6030 G15S admitted, ASC=0x0
asahi-g15 292400000.gpu: T6030 G15S: cores enabled per cluster: [7, 7]
asahi-g15 292400000.gpu: M3 firmware readiness: magic=0xabcdabcd flags=1
asahi-g15 292400000.gpu: M3: firmware accepted owned initdata and device controls
asahi-g15 292400000.gpu: G15: firmware at READY, starting the backend
[drm] Initialized asahi 0.0.0 for 292400000.gpu on minor 0

There is no admitted by g15_accept_text_prefix line in this boot. This confirms basic boot admission through the J514S cd05 pin without the override. Sustained GPU load, suspend/resume, and long-term stability have not been tested.

Follow-up: load and suspend testing

GPU load: completed a 300-second local offscreen EGL/OpenGL ES shader workload on Apple M3 Pro (G15S B1), Mesa 26.3.0-devel (git-a196911147). The workload repeatedly draws a 1024×1024 triangle with a 128-iteration fragment shader and calls glFinish() each frame: 143,689 frames, zero GL errors, and no matching Asahi/GPU fault, timeout, or recovery messages found in this boot's kernel log. This is a focused rendering stress test, not a standard benchmark, Vulkan test, or long-term qualification.

Suspend: unsuccessful before entering sleep. systemctl suspend aborts with Device or resource busy. A further attempt after explicitly switching display power off and confirming Hyprland reported DPMS off produced the same failure:

apple-dcp 2d2c00000.dcp: refusing system sleep: a display link is up
apple-dcp 2d2c00000.dcp: PM: device_prepare(): genpd_prepare returns -16
apple-dcp 2d2c00000.dcp: PM: not prepared for power transition: code -16
PM: Some devices failed to suspend, or early wake event detected

So this is not a successful suspend/resume cycle. I have not compared that failure against the released kernel and cannot attribute it to #366. The machine remained on the same boot; /dev/dri/renderD128 was still present, and a three-second hardware rendering test passed afterwards.

Released-kernel comparison

Restored the released linux-aurora and headers 7.2.11.aurora14-1, restored the prefix override, rebuilt the boot images, and rebooted into 7.2.11-14-1-ARCH. Override admission, GPU READY, and /dev/dri/renderD128 are confirmed.

Repeating suspend after confirming DPMS off produces the same apple-dcp 2d2c00000.dcp: refusing system sleep: a display link is up / genpd_prepare returns -16 failure before sleep. Thus this suspend failure also reproduces on the released kernel with the override; it is not specific to the #366 test build. A three-second hardware rendering check passes afterwards. Remaining on the released kernel for daily use.

maralcbr · 2026-11-10T04:16:05Z

Superseded by #427, which carried this change rebased onto #366 (455b498, authored by Joel) and is now merged into integration/aurora. Thanks Joel.

joelvj requested review from chriskearney, maralcbr and scottjones as code owners November 6, 2026 07:08

joelvj mentioned this pull request Nov 6, 2026

MacBook Pro 16" M3 Pro (Mac15,7): asahi-g15 fails probe — unsupported GPU firmware; Hyprland CPU-compositing ~430% omacom/omarchy#17739

Open

joelvj force-pushed the g15-pin-j516s-cd05 branch from 9c47fac to f800dce Compare November 6, 2026 07:11

scottjones added the ci:build Build, test and boot the kernel for this PR now label Nov 8, 2026

scottjones approved these changes Nov 8, 2026

View reviewed changes

scottjones mentioned this pull request Nov 8, 2026

drm/asahi: g15: pin the 4118 firmware TEXT on the J514S and J516S #427

Merged

maralcbr closed this Nov 10, 2026

davidricardocristancho-max mentioned this pull request Nov 10, 2026

MacBook Pro 16" M3 Max (Mac15,9 / J516C): asahi-g15 rejects GPU firmware 669913fb… after reinstall; Hyprland CPU-composites at ~750% omacom/omarchy#18412

Open

Navigation Menu

Repository navigation

drm/asahi: g15: pin the cd05 firmware TEXT on the J516S - #390

drm/asahi: g15: pin the cd05 firmware TEXT on the J516S#390
joelvj wants to merge 1 commit into
omacom:integration/aurorafrom
joelvj:g15-pin-j516s-cd05

joelvj commented Nov 6, 2026 •

edited

Loading

Uh oh!

joelvj commented Nov 6, 2026

Uh oh!

scottjones left a comment

Uh oh!

RenzoF commented Nov 9, 2026

Uh oh!

scottjones commented Nov 9, 2026

Uh oh!

joelvj commented Nov 9, 2026

Uh oh!

RenzoF commented Nov 9, 2026 •

edited

Loading

Uh oh!

maralcbr commented Nov 10, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

joelvj commented Nov 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Hardware evidence

Testing

Not tested

Uh oh!

joelvj commented Nov 6, 2026

Uh oh!

scottjones left a comment

Choose a reason for hiding this comment

Uh oh!

RenzoF commented Nov 9, 2026

Machine

Without the override

With options asahi g15_accept_text_prefix=0xcd05af6a828b52e4 (and limine-mkinitcpio)

Suggestion

Uh oh!

scottjones commented Nov 9, 2026

Uh oh!

joelvj commented Nov 9, 2026

Uh oh!

RenzoF commented Nov 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Follow-up: load and suspend testing

Released-kernel comparison

Uh oh!

maralcbr commented Nov 10, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

joelvj commented Nov 6, 2026 •

edited

Loading

With `options asahi g15_accept_text_prefix=0xcd05af6a828b52e4` (and `limine-mkinitcpio`)

RenzoF commented Nov 9, 2026 •

edited

Loading