[sithglan]

Base: integration/aurora (cae47c0), which has #1174 (the firmware 27 method table per build). Branch thomas/j813-272, five commits.

This brings up the J813 (M5 MacBook Air, T8142, G17G) under a macOS 27.2 (26B123) stub: the GPU on the 26B123 G17G firmware and the panel on the 27.2 DCP firmware. 27.0 (26A428) keeps working as before; the J813 picks the interface from the firmware it finds.

It needs aurora-silicon/aura#192, which fills the GPU fw-text region and publishes 27.2 as the OS firmware version. Without it, the DT keeps the 27.0 fw-text address. The GPU then sees an unknown image and refuses to start it, and the DCP gets compat <0 0 0>: the same crash as today.

What 27.2 changes

All of it was read from the J813's own 27.2 restore image (kernelcache.release.mac17g, armfw_g17g, armfw1_g17g, t8142dcp) and compared with 27.0.

GPU (RTKit 3514.41.1, the same firmware family as the J873's 26B123 G18G in #1652, and the same deltas):

• The InitData root version word is 0x0c8b_6339_83a0_04c0 (bit 45 added).
• The policy grows 0x60 bytes: 0x7168 -> 0x71c8 for G17G, 0x7800 -> 0x7860 in the common table. It moves in three bands: [0, 0x2f0c) +0, [0x2f0c, 0x2f18) +0x10 and [0x2fb4, 0x6da0) +0x18. A new word at +0x2f28 is 5000.
• The status config grows 8 bytes, 0x6d0 -> 0x6d8: [0x59c, 0x5b4) +4 and [0x5b4, 0x6d0) +8, with a new word at +0x5b8 = 5000.
• The power controller's +0x1122c is 5000.
• Everything after the policy in the shared cluster moves +0x80. The private cluster is unchanged.
• iBoot loads the GPU TEXT 64 KiB higher (0x100_00e5_4000) and the data 80 KiB higher (0x100_0245_8000).

DCP: 27.2 renumbers the AP -> DCP methods. #1174 has the 27.2 table from the T6050. The J813's own IOMobileGraphicsFamily-DCP and AppleMobileDispH17G-DCP, compared with 27.0's by method name, agree with it entry for entry. UnifiedPipeline2 gained getDisplayCaps at A380, so A380-A399 move up by one. Every IOMobileFramebufferAP and DCPPowerManager method moves up by 50: A427 get_color_remap_mode is A477, A408 swap_submit_dcp_main is A458, A484 setPowerState is A534. Everything else matches 27.0: the in/out sizes (swap_submit_dcp stays 0x1d30), the DCP -> AP callbacks, and the methods below A380. The one entry #1174 leaves out is dfb_ready_query (UnifiedPipeline2::headless), which is A385 (27.0: A384). #1174's own 27.3 trace sends it there as well.

The commits

1. arm64: dts: apple: t8142-j813: Describe the GPU firmware TEXT: a fw-text reserved-memory node, which aura fills from the ADT. Its static value is the 27.0 placement, like fw-data.
2. drm/asahi: g17: M5: InitData for the macOS 27.2 (26B123) common firmware: a 26B123 profile of the common 26A428 graph. The 26A428 encoding is moved by the bands above, and a byte that no band carries is refused rather than dropped. The 26A428 encoding is unchanged.
3. drm/asahi: t8142: Identify the J813 GPU firmware and admit macOS 27.2: the J813 identifies the loaded build by the TEXT digest, as the T6041/T6050 do (Firmware::Identified), and gets the 26A428 or 26B123 config. An unknown build is refused. There is a new KUnit case, t8142_identifies_each_build.
4. drm/apple: dcp: T8142: Drive the macOS 27.2 firmware: T8142 admits apple,firmware-compat 27.2.0 as firmware 27, so probe picks drm/apple: traced firmware 27.3 IOMFB method IDs #1174's 27.2 table.
5. drm/apple: dcp: Give firmware 27.2 its dfb_ready_query: A385 in the 27.2 table, so 27.2 boots with the same sequence as 27.0. Without it, boot_5() skips the query. This also applies to the T6050 on 27.2; it is a separate commit so it can be dropped on its own.

Testing

All of this is on the J813 under the 27.2 stub, with aura aura-j813-272a (the J813's enrolled branch plus aurora-silicon/aura#143's fw-data and aurora-silicon/aura#192's two commits), chainloaded in place from the DebugUSB proxy. This head (4592ae5, built as 7.3.0-aurora-j813-272+) and the same series on integration 3d6f0f5 (where the J813 still carried its own 27.2 table with A385) were both booted through aura-try with the kernel's own DTB, so aura filled fw-text and fw-data:

• Ten CPUs. The GPU reports "GPU firmware: 27.2 (26B123), G17G", and EGL and Vulkan see "Apple M5 (G17G C0)". The DCP gets compat <27 2 0> and boots with no crash; its boot callback chain completes, so it answered dfb_ready_query at A385. eDP-1 runs at 2560x1600, appledrmfb binds, and sway runs on the panel: the plane alternates between sway's framebuffers as the bar redraws, and no swap fails. The sound card is present.
• CTS with Mesa j813 (/opt/mesa-j813, JOBS=4), on the 3d6f0f5 build. drivers/gpu/drm/asahi is identical on this head:
  • GLES2: 16955 pass, 0 fail.
  • GLES3: 44380 pass, 0 fail.
  • GLES31: 37339 pass, 0 fail, 1 flake (image_load_store.3d.qualifiers.coherent_r32f).
  • GLES2 again on this head: 16955 pass, 0 fail.
  • No GPU submission failed. That matches the J813 on 27.0 (drm/asahi, drm/apple: J813 (M5 MacBook Air) GPU and display on the macOS 27.0 firmware #1413's 7.3.0-aurora-j813-oni4s+: 16955/0, 44380/0, 37339/1).
• Each of the five commits builds (Image.gz, modules, dtbs; LLVM 22).
• KUnit asahi_fwid: 9 passed, 1 skipped (the j713 case, which skipped before this series too). The new t8142_identifies_each_build passes.
• The first three commits on integration 9746918 were also booted with aura 27av, which publishes no 27.2 version and fills nothing, using a DTB that carries the 27.2 addresses. The GPU ran the same CTS there: 16955/0, 44379/1 (texture.units.8_units.mixed.8, which passes alone 3 of 3) and 37339/0. With all four commits under 27av, the DCP gets compat <0 0 0>, falls back to H17P and crashes on A427, as it does today.

Known on 27.2, and as far as I can tell on firmware 27 generally:

• The DCP's powerlog-service is announced with only ep-has-desc-mgr and interface-id. The AFK name fallback covers only the H17G profile, and T8142 on firmware 27 runs the default profile, so the service is not bound ("AFK[ep:20]: failed to extract init props: -2") and no loader brightness arrives. The backlight starts from the fallback level.
• A new KMS client's surfaceless first present can be dropped at the backlight step ("present dropped: backlight prepare -61"). Sway runs normally afterwards.
• Both are left for a follow-up.

cc @Acelogic @DjDeveloperr @RyanTheTide @LiamRay10

[sithglan]

Rebased onto cae47c0 right after opening, because #1174 had just merged. The J813's own 27.2 method table is gone in favour of #1174's per-build tables. They agree entry for entry with what the J813's 27.2 kernelcache gives, so T8142 now only admits 27.2.0. The one entry #1174 leaves out, dfb_ready_query at A385, is a separate commit on top. The new head was booted on the J813 under 27.2 (DCP, panel, sway, GPU) and ran GLES2 at 16955/0.

[RyanTheTide]

Reviewed the build identification, the band relayout and the T8142 firmware-compat change. The J700 and other profiles keep their old values in every edited match, and the CTS runs on the 27.2 stub cover it.

@sithglan one change before this goes in: the dcp_methods_27_2 comment says the A385 tag comes from the J813's 27.2 kernelcache. Please describe it from your own 27.3 call trace only and drop the kernelcache reference.

[sithglan]

@RyanTheTide done, force-pushed as 17229b9 (was 4592ae5; the diff between them is comments and commit messages only).

• dcp_methods_27_2: the A385 comment now says what we observed: the 27.3 trace sends dfb_ready_query at A385, and the J813's DCP answers it there on 27.2. The kernelcache reference is gone.
• I applied your drm/asahi: g18: J873 G18G on the macOS 27.2 (26B123) firmware #1652 note here as well. The 26B123 InitData comment block in g17/fw/m5/initdata.rs described the change by kext functions and image offsets; it now describes it by the fields and sizes only. The three commit messages that cited the kernelcache or kext (InitData, DCP 27.2 admission, dfb_ready_query) are reworded the same way.

The fw-text build tables in hw/t8142.rs keep their image ranges, as the T6041/T6050 tables do: the identification hashes those ranges. The asahi and apple drivers build.