Skip to content

j475d (Mac Studio M2 Ultra): dcpext RTKit boot times out (-62), apple-drm never binds — HDMI and Thunderbolt displays all stuck on simpledrm #428

New issue
New issue
Open
Open
j475d (Mac Studio M2 Ultra): dcpext RTKit boot times out (-62), apple-drm never binds — HDMI and Thunderbolt displays all stuck on simpledrm#428

Description

@jcrowthe
jcrowthe
opened on Nov 8, 2026

Mac and installed build

Apple Mac Studio (M2 Ultra, 2023). Board apple,j475d, SoC apple,t6022.

Omarchy 4.5.0-3, stock packages, no local kernel or bootloader patches.

  • uname -r: 7.2.11-14-1-ARCH
  • linux-aurora 7.2.11.aurora14-1
  • m1n1-aurora 1.6.1.aurora22-1
  • uboot-aurora 2026.07.aurora6-1
  • omarchy-mac 0.2.3-2
  • mesa-aurora 1:26.3.0_devel.20261031.231483.a1969111475-1
  • iBoot: mBoot-18000.161.10 / iBoot-8422.141.2
  • Kernel command line includes user4k=on
asahi,os-fw-version: 13.5
asahi,system-fw-version: 26.6.2

/proc/device-tree/chosen has no asahi,dcp-handoff-reason.

Displays attached

  • Dell monitor on the built-in HDMI port
  • LG 40WP95C over Thunderbolt (enumerates as thunderbolt 0-1)
  • LG 27" over USB-C/Thunderbolt (shows up as a Type-C partner, not on the Thunderbolt bus)

Reproduction, expected result, and actual result

Boot with the displays attached. Happens on this boot. A manual rebind later in the same boot fails the same way.

Expected: apple-dcp binds and HDMI comes up at the monitor's native mode with an EDID. The Thunderbolt displays get KMS connectors.

Actual: the only enabled DCP, 2289c00000.dcp (apple,t6020-dcpext, on die 1, which I believe is the HDMI pipe), times out during RTKit endpoint discovery. The failure takes down the whole apple-drm aggregate. The only DRM output left is simpledrm Unknown-1 at 1920×1080. Its EDID is 0 bytes and it offers no other mode. The two LG monitors stay dark.

This looks like the same failure as #379 (j375c) and #394 (j473), seen here on t6022.

Relevant error lines

At boot:

apple-dcp 2289c00000.dcp: DCP index:1 dptx target phy: 4 dptx die: 1
apple-dcp 2289c00000.dcp: RTKit: endpoint discovery failed: -62
apple-dcp 2289c00000.dcp: error -ETIME: Failed to boot RTKit: -62
apple-drm soc@200000000:display-subsystem: failed to bind 2289c00000.dcp (ops dcp_comp_ops [appledrm]): -62
apple-drm soc@200000000:display-subsystem: adev bind failed: -62
apple-dcp 2289c00000.dcp: probe with driver apple-dcp failed with error -62

A manual rebind (echo 2289c00000.dcp > /sys/bus/platform/drivers/apple-dcp/bind) gives an identical result about 1 s later. The DCP firmware logs no RTKit syslog lines between probe and timeout:

16:06:40 apple-dcp 2289c00000.dcp: DCP index:1 dptx target phy: 4 dptx die: 1
16:06:41 apple-dcp 2289c00000.dcp: RTKit: endpoint discovery failed: -62
16:06:41 apple-drm soc@200000000:display-subsystem: adev bind failed: -62

The LG 40WP95C enumerates over Thunderbolt and a DP tunnel is attempted, but with no KMS device it is torn down:

thunderbolt-apple-nhi 701f00000.nhi: device links to tunneled native ports are missing!
thunderbolt 0-1: LG Electronics 40WP95C
thunderbolt-apple-nhi 701f00000.nhi: 0:5 <-> 1:13 (DP): not active, tearing down
thunderbolt-apple-nhi 701f00000.nhi: 0:6 <-> 1:13 (DP): not active, tearing down

The same monitor works over Thunderbolt at 5120x2160@72 on aurora14 on an M1 Pro (#374), so the tunnel side is probably not the problem here.

Device tree observation (t6022)

Only one of the four dcpext nodes is enabled in the stock tree:

soc@200000000/dcp@289c00000   status=disabled  apple,t6020-dcpext
soc@200000000/dcp@315c00000   status=disabled  apple,t6020-dcpext
soc@2200000000/dcp@289c00000  status=okay      apple,t6020-dcpext
soc@2200000000/dcp@315c00000  status=disabled  apple,t6020-dcpext

So even once the RTKit timeout is fixed, the rear and front Thunderbolt ports seem to have no DCP to drive a display. Is t6022 / j475d covered by the Thunderbolt display work in #9 and #373, or does it need its own dcpext wiring?

Graphics or session details

Hyprland 0.56.2. One monitor: Unknown-1, 1920×1080, with empty make, model and description. The GPU probes normally (asahi on 406400000.gpu, render node only).

I can test patches or branch kernels on this machine.

Activity

  1. jcrowthe commented on Nov 13, 2026

    @jcrowthe
    jcrowthe
    on Nov 13, 2026
    Author

    Update: root cause found and HDMI now works on this j475d with a patched m1n1 stage 2. The kernel is stock.

    Cause (same as #379)

    This was re-tested on the edge channel (linux-aurora 7.2.11.aurora16-1, m1n1-aurora 1.6.1.aurora23-2), and the stock build still fails the same way. m1n1 stage 2's own log (sudo sh -c 'tr -d "\0" < /dev/mtd0ro') shows the HDMI DCP abandoned mid-handshake because its DART is locked:

      Target: J475d
  Chip-ID: 0x6022
display: External display found, reconfiguring
dart: dart /arm-io/dart-dcpext4 at 0x228930c000 is a t8110 (locked)
dart: dart /arm-io/dart-dispext4 at 0x2289304000 is a t8110 (locked)
rtkit(dcp): booting with version 12
rtkit(dcp): failed to DART map (size 0x4000)
rtkit(dcp): unable to allocate buffer
rtkit(dcp): failed to handle system message 0x04: 10400000000000
dcp: failed to boot RTKit
display: failed to initialize DCP

    This is the failure riopierrefrancois diagnosed on j375c in #379. On the Ultra, the HDMI pipe is dcpext4 behind a locked T8110 DART on die 1.

    Fix tested

    I built stage 2 from ba130ffb (the m1n1-aurora 1.6.1.aurora23 source) with three changes:

    An unpatched build with the PKGBUILD recipe is byte-identical to the packaged /usr/lib/asahi-boot/m1n1.bin once the cargo path is remapped (RUSTFLAGS=--remap-path-prefix=$HOME/.cargo=/home/builder/.cargo), so the patches are the only difference. I installed it with M1N1=... update-m1n1. Stage 1, U-Boot and the kernel are stock.

    m1n1 log on the patched boot:

    dart: dart /arm-io/dart-dcpext4 at 0x228930c000 is a t8110 (locked)
dart: /arm-io/dart-dcpext4 is locked; mapping through its existing roots
rtkit(dcp): booting with version 12
display: connected:1 timing_cnt:53 color_cnt:22
display: timing mode: valid=1 1920x1080 60.00 Hz
display: Modeset took 363 ms
display: Sleeping DCP (external)

    Linux: apple-drm binds 2289c00000.dcp, and card2-HDMI-A-1 comes up with a real EDID. Hyprland runs the Dell U2718Q at 3840x2160@60, where it was stuck on 1080p simpledrm before.

    Still open on this machine

    1. Black gap at boot (kernel side). This is the same as ytgconsulting's M2 Max report. The first dcp_dptx_connect times out about 2 s after HPD is enabled. The picture only comes back when the monitor drops and reasserts HPD itself:

      [ 3.240] dcp_enable_dp2hdmi_hpd: DP2HDMI HPD connected:1
[ 5.281] dcp_dptx_connect: timed out waiting for port 0 link configuration
[ 5.281] RTKit: syslog message: ... unplug_gated(...): display HPD removed
[ 6.305] AppleDCPDPTXRemotePort (chan:9) service call group 0 cmd 7 failed to complete: -110
[ 7.739] DP2HDMI HPD irq, connected:0
[ 8.238] DP2HDMI HPD irq, connected:1
[ 9.761] AppleDCPDPTXRemotePort (chan:9) service call group 0 cmd 12 failed to complete: -110
[ 9.761] dcp_dptx_connect: failed to validate DPTX target 1:4: -110
[20.360] DP2HDMI HPD irq, connected:0
[20.859] DP2HDMI HPD irq, connected:1
[22.338] [drm] fb0: appledrmfb frame buffer device

      The first re-assert at ~8 s still fails with -110. The second, at ~20 s, recovers.

    2. Thunderbolt/USB-C displays still have no DCP. This is unchanged from the original report. Only soc@2200000000/dcp@289c00000 is okay in the t6022 tree, and the other three dcpext nodes are disabled. So the monitors on the rear Thunderbolt ports stay dark even with HDMI fixed.

    I can test a proper T602x m1n1 branch or kernel patches on this j475d.

  2. jcrowthe commented on Nov 13, 2026

    @jcrowthe
    jcrowthe
    on Nov 13, 2026
    Author

    Update on the second point above (Thunderbolt/USB-C displays have no DCP): DP alt mode on the four rear USB-C ports now works on this J475d with a device tree change only, in #462.

    macOS drives a USB-C DisplayPort display on the rear ports from DCPEXT1 (die 0) through the display crossbar, the same controller the M2 Max Studio and M2 Pro mini already use in Linux. Those routes were inside APPLE_T602X_NON_ULTRA. With the guard narrowed to the USB4/PCIe-C wiring, and dispext1_dart added to the J475d display iommus, dcpext1 boots cold, binds next to the HDMI DCP and creates DP-1 to DP-4. An LG UltraFine 4K over a USB-C to DisplayPort cable runs at 3840x2160@60 on all four rear ports, coldplug and hotplug, at the same time as HDMI. The kernel is stock aurora16.

    Still open here: the HDMI black gap at boot, the front USB-C ports (die 1) and Thunderbolt tunnelling. The repeated wake while locked turned out to be the Dell dropping HPD in standby combined with Hyprland's backend, reported as hyprwm/aquamarine#495.

  3. jcrowthe commented on Nov 13, 2026

    @jcrowthe
    jcrowthe
    on Nov 13, 2026
    Author

    Thunderbolt displays now work on this J475d too, in #463 (stacked on #462). An LG 40WP95C over Thunderbolt runs at 5120x2160@72 on rear ports 1 and 2, with hotplug and DPMS cycles, at the same time as a DP alt mode display and HDMI, all three DCPs running. #463 has KUnit runs (including a negative control) and the full test table.

    PCIe over Thunderbolt (a U.2 enclosure) still fails on t6022 with PCIe-C is not initialized by m1n1 or the kernel. The built-in pcie-apple cold-init list also lacks t6022. That's left for a separate change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions