GuC bring-up on MTL/ARL: firmware from Resources, CT channel, first request #5

openkernel

watchthelight 2026-10-21

Milestone X4. GuC is required in practice from Alder Lake-P on, and on Meteor/Arrow Lake i915 skips TLB invalidations without it. The kext ships mtl_guc_70.bin (GuC 70.53.0). Expect the failure VedCloud2/CoreUltraGraphics hit ('Enabling uc failed (-5)'); debug.xegfx_env can set compat.linuxkpi.i915_enable_guc for experiments. Done when a no-op batch completes on RCS0.

watchthelight 2026-10-21

Worth knowing for this one: VedCloud's later Meteor Lake port gets past the GuC failure CoreUltraGraphics hit. It runs an i915-derived driver on XNU with GuC 70.53.0 and has Metal and Vulkan working on a Dell Latitude 5350 (8086:7D45) under macOS 15: https://github.com/VedCloud/Meteor-Lake-Xe-LPG-Metal-Graphics

Their research/ folder and the "current blocker" and "failure signatures" sections of the README are the first place to look when the CT channel or the first request stalls here.

watchthelight 2026-10-22

Upstream scout, 2026-10-22: VedCloud's Meteor Lake port (i915 on LinuxKPI inside XNU, same idea as XeGfx) runs GuC submission on both GTs with Linux's own unchanged mtl_guc_70.bin (70.53.0), plus DMC 2.23, HuC 8.5.4 and GSC 102.1.15. So the firmware itself isn't the problem on MTL. Two bugs they hit on the way: a LinuxKPI lost wake-up that looked like GuC TLB-invalidation timeouts (see #4), and a context use-after-free in signal_irq_work fixed by the upstream patch "drm/i915/gt: Fix ce use-after-free in signal_irq_work()" (their kernel 1.0.14). README, v1.0.14

Also for Arrow Lake: some ARL parts use the newer Xe-LPG+ IP (12.74) rather than Xe-LPG (Phoronix); worth confirming which one 7D67 maps to in i915's device tables before the first GuC request. Write-up: https://github.com/watchthelight-labs/research/blob/main/scout/xe/2026-10-22.md

Reply on GitHub