No display over HDMI-out on M2 Mac Mini (j473ap) about m1n1

[3405691582]

This is now working as of recent releases, and with the same hardware, I can see U-Boot on the screen. Closing.

[leio]

proxyclient/tools/chainload.py -r path/to/stage2/m1n1.bin
provided you have the udev rules to get /dev/m1n1 and co symlinks for a stable ttyACM link (sometimes it's ttyACM0, sometimes ttyACM1). Or you can prepend or export M1N1DEVICE env var for what you have it on at the time iirc.
The udev rules can be seen at https://github.com/AsahiLinux/m1n1/blob/main/udev/80-m1n1.rules

At one point of time in earlier iterations, I also chainloaded stage2 twice to get the picture to light up - back when I didn't have any HDMI out supporting code in stage1 yet.

[jannau]

According to the log everything work as expected:

TTY> display: connected:1 timing_cnt:35 color_cnt:10
TTY> display: timing mode: valid=1 1920x1080 60.00 Hz
TTY> display: color mode: valid=1 colorimetry=1 eotf=1 encoding=1 bpp=32

dcp has a connection to the display and will use 1 1920x1080 60.00 Hz as mode

TTY> display: swapped! (swap_id=0)
TTY> display: Modeset took 4425 ms
TTY> display: Sleeping DCP (external)
TTY> DCP: dcp_shutdown(sleep=true) is broken with dptx-port, quiesce instead
TTY> fb init: 1920x1080 (30) [s=1920] @0x9e5064000

m1n1 has set the framebuffer and reconfigured internally for 1920x1080 display.

What display is this? Does it support 1920x1080 60Hz as mode on other devices? It acts as if nothing is connected?

[3405691582]

It's a HP 22cwa. In macOS, this works fine and is reported as 1920x1080 at 60Hz in System Settings, it behaves normally when driven by other devices and graphics cards, and this is a mode it supports in its published specifications.

When the device boots for m1n1, the attached display remains in sleep mode and doesn't power up.

[leio]

At least with earlier iterations of the M2 HDMI m1n1 patches, it needed both stage1 and stage2 to have the support to reliably turn it on. I still usually don't see picture from stage1 unless I did a warm reboot, though with a new monitor I'm not sure it's just not the monitor being slow to light up (haven't startup cycled much yet).

That is to ask for an additional data point - does it also not work if you chainload stage2 m1n1-1.4.3+ after a stage1 m1n1-1.4.3+?

[3405691582]

does it also not work if you chainload stage2 m1n1-1.4.3+ after a stage1 m1n1-1.4.3+?

Let me report back. I can try and figure out how to do that, or do you have a quick reference for how I can chainload stage2 from the prompt?

[niggowai]

What version of m1n1 are you using in the 2nd stage?
I experienced Problems when running pacman -Syu last monday. The server didn't came up after an update and I wasn't at home...
After saving the data I reinstalled Asahi with the patched installer I used before. Asahi came up without problems but when I dated up, after a reboot, the same problem again. After another reinstall, with excluding m1n1 from the update, the reboot worked!

Tomorrow I'll try to track down the problem and open an issue to get the problem fixed.

You can try to use an older version, but then you may have to build m1n1 to support display on m2 Mac mini. If it helps, i can provide you the package I installed Asahi with.

[3405691582]

Sorry for the delay. I tried to chainload an m1n1 stage2. By reading the wiki carefully, I assume that the same stage2 binary can be obtained from https://cdn.asahilinux.org/os/uefi-only-20231012-1.zip, essentially. Subsequently extracting at ../u and trying env M1N1DEVICE=/dev/ttyACM0 ./proxyclient/tools/chainload.py -r ../u/esp/m1n1/boot.bin did not yield any better results; the connection drops (presumably as this stage2 is "release" and drops proxy mode, or something), and the monitor didn't wake. If there's a better stage2 payload I can use, if you upload the blob somewhere, I can try that, otherwise I have to try and construct one myself.

In the meantime, I'll see if I can try with an alternate monitor.

[3405691582]

HP 23xw and LG 27GP850-B also exhibited these symptoms.