Linux 7.0 HDMI not working

Dragon Series Q6A
1

My HDMI port is not working properly after upgrade my Linux kernel from 6.18.2 to 7.0.11. Here are the details:

I can reproduce this issue on a Radxa Dragon Q6A.

System

- Board: Radxa Dragon Q6A

- OS: Ubuntu 24.04.4 LTS

- Working kernel: “6.18.2-4-qcom”

- Broken kernel: “7.0.11-4-qcom”

- Upgrade command: “apt full-upgrade”

The broken kernel was installed from the official Radxa repository:

linux-image-7.0.11-4-qcom:

Installed: 7.0.11-4

Candidate: 7.0.11-4

The upgrade changed:

linux-image-radxa-dragon-q6a:

6.18.2-4 → 7.0.11-4

linux-headers-radxa-dragon-q6a:

6.18.2-4 → 7.0.11-4

embloader:

0.6 → 0.7

Problem

UEFI video output works normally. After Linux 7.0.11 starts, the HDMI display loses signal and remains black.

The system itself continues running and is accessible over SSH.

Under Linux 7.0.11:

$ uname -r

7.0.11-4-qcom

$ cat /sys/class/drm/card1-HDMI-A-1/status

disconnected

Relevant kernel messages:

msm_dpu ae01000.display-controller: bound ae90000.displayport-controller

[drm:msm_dp_aux_isr [msm]] *ERROR* Unexpected DP AUX IRQ 0x00000008 when not busy

[drm] Initialized msm 1.13.0 for ae01000.display-controller

msm_dpu ae01000.display-controller: [drm] Cannot find any crtc or sizes

Tests performed

1. Forced HDMI mode

Adding a forced “video=HDMI-A-1:1280x720@60e” mode did not resolve the underlying disconnected connector state.

2. Linux 7.0.11 with the Linux 6.18 device tree

I tested:

Kernel: 7.0.11-4-qcom

Initramfs: 7.0.11-4-qcom

DTB: qcs6490-radxa-dragon-q6a.dtb from 6.18.2-4

HDMI still failed.

This suggests the regression is not limited to the device tree.

3. Full rollback to Linux 6.18.2

After booting the complete Linux 6.18.2 kernel, initramfs and DTB:

$ uname -r

6.18.2-4-qcom

HDMI output immediately worked again with the same board, display, cable and userspace installation.

Suspected area

This appears to be a regression in the Qualcomm MSM DisplayPort path used with the Dragon Q6A DP-to-HDMI bridge, possibly involving HPD/AUX handling or DP link training.

The important comparison is:

6.18.2-4-qcom: HDMI works

7.0.11-4-qcom: HDMI connector is disconnected

7.0.11 kernel + 6.18 DTB: still disconnected

Could the Radxa team confirm this regression and provide a fixed QCOM kernel package?

Please also consider preventing “linux-image-radxa-dragon-q6a” from selecting “7.0.11-4” until HDMI operation is restored.

2 Likes
2

I can confirm another regression after upgrading from 6.18.2-4-qcom to 7.0.11-4-qcom on a Radxa Dragon Q6A.

In my case I am running the board headless (no HDMI/DP monitor connected).

After upgrading to 7.0.11-4-qcom, both htop and btop consistently report CPU0 at around 50-60% usage while the system is idle.

However:

  • top shows almost no CPU load.

  • ps does not show any process consuming CPU0.

  • /proc/stat does not indicate a heavily loaded CPU0.

  • CPU temperature remains stable.

After booting back into 6.18.2-4-qcom, the issue disappears immediately and CPU0 idles normally, with no other system changes.

Since another regression already affects the MSM Display/DisplayPort subsystem in 7.0.11-4-qcom, this may be related to changes introduced in the same kernel series.

3

I have the same problem

4

I also have the same problem. I used claude to troubleshoot it. I asked it to generate a bug report:

Confirming this on my Dragon Q6A too — Ubuntu 24.04.4, kernel 7.0.11-4-qcom.

Same symptom as the OP: boot logo shows fine via simpledrm, goes black the moment msm_dpu takes over. A few things I dug up that might help narrow it down further:

  1. The exact failure point in dmesg, right as msm_dpu binds the DP controller:
    [4.803545] [drm:msm_dp_aux_isr [msm]] ERROR Unexpected DP AUX IRQ 0x00000008 when not busy
    [5.055938] msm_dpu ae01000.display-controller: [drm] Cannot find any crtc or sizes
    [5.059482] msm_dpu ae01000.display-controller: [drm] Cannot find any crtc or sizes
    No further DP/HPD/AUX log lines appear for the rest of uptime.

  2. Confirmed it’s not just a one-off boot race — with the system fully up and the monitor connected, /sys/class/drm/card1-HDMI-A-1/status reads disconnected (0-byte
    EDID). I physically unplugged and replugged the HDMI cable and checked both the sysfs status and journalctl -k for any hpd/dp_aux/msm_dp/drm/hdmi line — nothing,
    at all, in either. So this isn’t a slow/missed retry, hotplug detection appears to be completely dead for the rest of the session after that first AUX IRQ gets
    logged as unexpected.

  3. Don’t try unbind/rebind as a workaround — I tried it (echo ae01000.display-controller > /sys/bus/platform/drivers/msm_dpu/{unbind,bind}) hoping a fresh probe
    would re-trigger detection. Unbind throws GEM/scheduler teardown warnings (msm_gem.c:884 !is_vunmapable, msm_gem.c:170 msm_obj->pin_count, “Tearing down scheduler
    with active entities!”), and the following rebind hard-crashes with a NULL pointer deref in power_allocator_manage (thermal cooling device registration, called from
    adreno_bind/msm_gpu_init). Needed a full reboot to recover — no /sys/class/drm/card* at all after that. So the driver’s bind/unbind lifecycle is broken too, on top
    of the HPD issue.

5

Has anyone in this topic tried/used the standard distro kernel (e.g. 7.1.8+deb14-arm64 in Debian Sid ATM)?

7.0 is already unlisted on kernel.org I see and in a week or so there is already 7.2

Some apt pinning is needed, am not sure how that would work in Ubuntu 24 or 26, but Debian Trixie works fine with Sid kernel on RK3588. I would expect this should also work OK on QCS6490 although the extra DP-to-HDMI is maybe a sort of showstopper.

6

I found a workaround that allows me to boot Linux 7.0 on the Q6A.

First, I updated/flashed the latest SPI firmware. This resolved several boot issues and made the system bootable again.

After that, Linux 7.0 boots with a black screen, but a long press of the Power button resolved the issue.

In my case:

  • sudo reboot → black screen (with new SPI) / does not boot (with old SPI)

  • sudo poweroff, followed by a normal short Power-button press → black screen

  • long press of the Power button → Linux 7.0 boots successfully

So if anyone is stuck with a black screen after upgrading to kernel 7.x, try updating the SPI firmware first, then boot using a long Power-button press.

It looks like this may be related to warm reset / power-state handling rather than Linux 7.0 being completely unable to boot on the Q6A.

1 Like
7

Does this really mean also nothing on serial console ? Or haven’t you looked at that?

Same question for ssh access.

8

Can ssh in OK - all seemed to be OK, e.g. mounts of network shares, so I assumed an HDMI driver type issue. The update also upset audio, leaving a boot into 6.18.4 with no audio devices found.

9

Just got one of this boards and i can confirm the issue. I was trying to install Proxmox and faced this issue immediately. As the official arm version of Proxmox is very recent there are no builds with kernel 6. Would love to see Radxa support this by fixing this bug asap and committing the mainstream kernel.

10

Do you need HDMI/desktop for a computer hosting virtual machines?

As suggested earlier a standard 7.1 distro kernel might get something running now and no need to wait for a qcom variant.

11

I do not need a HMDI as soon as it gets installed, configured and integrated into the cluster. But i do need it at least to configure networking to be able to ssh into and configure it.
I will try the automated install option but flying blind doesn’t help.

Didn’t see anything on this thread about kernel 7.1 but that info already helps :slight_smile:.
Thanks for the tip

12

Get a USB-TTL serial cable, they cost almost nothing and always good to have permanently connected for an important server in case something get wrong with networking. The EDK2 UEFI based bootloaders/firmware also work (in color) via such a serial cable, at least on RK3588 and BCM2711, so really no HDMI monitor cables etc needed. Just a laptop to plug-in the USB-TTL serial cable.

You can of course prepare the image in such a way that it always connects to IP networking with known address and ssh login enabled. It is pretty default for RPi if you use their imager or Armbian as well.

7.1 kernel (or already 7.2) is something you need to get yourself, I am using apt pinning on Debian based Trixie to have the Debian Sid kernel, both on RK3588 and BCM2711. Both run VMs 24/7.

1 Like
13

HDMI works now after the latest kernel updates.