[RK3399] Type-C DP Alt Mode display not working at boot (requires unplug/replug)

[thai hoang]

Hardware & OS Details:

Board/SoC: SOM-RK3399

OS: Ubuntu 24.04 Base (Console tty only, no desktop GUI)

Interface: DisplayPort 1.2 Alt Mode via USB Type-C (card0-DP-1)

Bootloader: Image file on wiki page.

Kernel cmdline: storagemedia=emmc androidboot.storagemedia=emmc androidboot.mode=normal androidboot.dtbo_idx=0 earlycon=uart8250,mmio32,0xff1a0000 swiotlb=1 coherent_pool=1m rw root=/dev/mmcblk2p8 rootfstype=ext4 rootflags=discard data=/dev/mmcblk2p9 console=ttyFIQ0 consoleblank=0 cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1

 

Issue Description:

When booting the SOM with the Type-C cable pre-plugged into an external monitor, the display stays blank/asleep. However, if I hot-unplug and replug the Type-C cable after the system has finished booting, the display immediately wakes up and shows the tty1 console login screen normally.

Checking sysfs shows DRM recognizes the port and supported EDID modes (cat /sys/class/drm/card0-DP-1/status returns connected, and /modes lists 1366x768), but the display pipeline/link training fails to establish automatically on cold boot.

Attempted Workarounds & Debugging Logs:

Resetting cdn-dp driver:

Triggering unbind on fec00000.dp causes an immediate Kernel crash:

Bash

echo "fec00000.dp" > /sys/bus/platform/drivers/cdn-dp/unbind # Result: Segmentation fault

Resetting FUSB302 over I2C:

Unbinding and rebinding 4-0022 under /sys/bus/i2c/drivers/fusb302/ executes cleanly, but does not trigger DP link renegotiation or wake the screen.

 

DRM events & Framebuffer:

 

Writing detect to /sys/class/drm/card0-DP-1/status and change to /sys/class/drm/card0/uevent did not wake the screen.

 

echo 0 > /sys/class/graphics/fb0/blank executes without error, but screen remains blank.

 

setterm -blank poke fails with Inappropriate ioctl for device.

 

Question:

Is there a known DTS patch or a safe software method to force DP link training on boot without crashing the cdn-dp driver?

[Werner]

Providing logs with 

armbianmonitor -u

 helps with troubleshooting and significantly raises chances that issue gets addressed.

[Boardcon_yang]

Hi thai hoang,
Since this is console-only, one thing worth ruling out first: nothing may ever be requesting a mode on that connector at cold boot. status=connected
just mirrors HPD — fbcon only sets a mode after the DRM hotplug path fires, which is exactly what your replug gives you. The standard test is to force it from the kernel cmdline:  video=DP-1:1366x768e   

(the trailing e forces the connector enabled at boot, bypassing the hotplug dependency).

 

If that lights the screen, you have the answer and the workaround in one — and modetest -s from libdrm-tests does the same from userspace if you'd rather test without a reboot. If it stays dark with e, then it's genuinely link training, and drm.debug=0x1e will show which side gives up (PHY training vs. cdn-dp firmware handshake). The early-boot dmesg lines (cdn-dp / tcpm / fusb302)
would tell which case you're in — Werner's armbianmonitor covers it. On the unbind segfault — that's a real bug in cdn-dp's remove path, not
just noise on your end. The driver doesn't tear down cleanly when the PHY/firmware is in a partial state. Worth reporting separately with the
oops trace if you have it; either way, unbind isn't a safe reset on this driver.