RK3399 | No HDMI output with default mode

[ihipop]

Creating a bug report/issue

• I have searched the existing open and closed issues

Required Information

• DietPi version:

G_DIETPI_VERSION_CORE=9
G_DIETPI_VERSION_SUB=9
G_DIETPI_VERSION_RC=0
G_GITBRANCH='master'
G_GITOWNER='MichaIng'

• Distro version : bookworm
• Kernel version: [ 0.000000] Linux version 6.6.56-current-rockchip64 (build@armbian) (aarch64-linux-gnu-gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #1 SMP PREEMPT Thu Oct 10 10:50:06 UTC 2024
• SBC model: NanoPC T4
• Power supply used: 12V2A
• SD card used: SanDisk Ultra

Steps to reproduce

1. Download the SD image from https://dietpi.com/downloads/images/DietPi_NanoPCT4-ARMv8-Bookworm.img.xz
2. flash it to SD card and boot

Expected behaviour

• HDMI is working

Actual behaviour

• black screen

Extra details

• ttl boot messages are normal
• ssh is working

[MichaIng]

Are there any kernel errors?

dmesg -l 0,1,2,3

And did you try a different HDMI screen, just to rule out it is related to it, like HDMI signal not strong enough/cable too long or such thing? SBCs behave differently than PCs or Laptops.

[ihipop]

Are there any kernel errors?

dmesg -l 0,1,2,3

And did you try a different HDMI screen, just to rule out it is related to it, like HDMI signal not strong enough/cable too long or such thing? SBCs behave differently than PCs or Laptops.

I can confirm that it isn't a cable's issue because it works well with armbian with kernel 5.x
When it comes to the kernel 6.x of armbian 23.x/24.x, The HDMI is broken too

[MichaIng]

Ah, Linux 5.x is too old to consider, and not maintained anymore by anyone. But indeed there are related reports at Armbian as well (the last one from you), from which we imported the issue:

• https://forum.armbian.com/topic/29462-any-commands-to-help-further-confirm-my-hdmi-output-is-broken/
• https://forum.armbian.com/topic/45633-nanopc-t4-images-not-booting/
• https://forum.armbian.com/topic/48372-hdmi-output-for-nanopc-t4-is-broken-since-linux-kernel-6x/

Interesting that features of such an old long mainline-supported board break. There have not been any significant changes recently, or at all, and its device tree does not define any HDMI-related thing anyway, while it works on other RK3399 boards: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts

It is actually a good circumstance to test the new Linux 6.12 kernel build. Maybe it even fixes the issue:

cd /tmp
wget https://dietpi.com/downloads/binaries/linux-{dtb,image}-current-rockchip64.deb
dpkg -i linux-{dtb,image}-current-rockchip64.deb
reboot

If not, then the slightly newer edge kernel could be tested as well:

apt install linux-{dtb,image}-edge-rockchip64
reboot

[ihipop]

and its device tree does not define any HDMI-related thing anyway

The HDMI is defined in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi#n208 and include by https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts#n12

[MichaIng]

Yeah, and that is included by all other RK3399 boards, where HDMI works, and the part has no been touched in a while, as far as I can see: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi

[ihipop]

Thank you for being willing to discuss this with me, you are the only one for now

do we use an armbian kernel ?, if it's true , may be related armbian/build#2016

[ihipop]

I tried the edge kernel, it works with HDMI
but I still want to know why because

the part has no been touched in a while

[MichaIng]

While this patch is not present anymore, is has later been disabled again, in a different way: https://github.com/armbian/build/pull/3260/files
And this patch is still in place: https://github.com/armbian/build/tree/main/patch/u-boot/u-boot-rockchip64

I mean it is HDMI for U-Boot only, not for the actual OS kernel. That time, obviously it did not break anything, but fixed HDMI, and today it does not break HDMI for any other board. But we can do a test build with the patch removed. Actually U-Boot messages on HDMI are quite appealing. The argumentation on the PR, that one cannot do inputs anyway, is misleading, since usually one does not want to change something in U-Boot, but simply wants to see logs/output in case the board does not boot. Otherwise one requires a USB-UART adapter for that. Probably HDMI audio is bot broken anymore by that, so that we can remove the patch in our Armbian fork, re-enabling U-Boot output on HDMI for all RK3399 boards.

But please test the newer kernel builds first, as every change on our fork is a maintenance burden, which I want to avoid, if possible.

[ihipop]

But please test the newer kernel builds first, as every change on our fork is a maintenance burden, which I want to avoid, if possible.

I'm testing the EDGE kernel for now
including HDMI and HDMI sound

I will post any result if I finish it

[MichaIng]

Great. Would be nice to know if the latest "current" kernel works as well. I have also no idea what might have changed. Probably a faulty (kernel) patch was dropped. Linux 6.6 to 6.12/6.13 also is quite something.

[ihipop]

• HDMI and HDMI audio is working!
  there are some errors during boot about audio, but it works

dmesg |grep codec
[    9.501996] rkvdec ff660000.video-codec: Adding to iommu group 2
[    9.502341] hantro-vpu ff650000.video-codec: Adding to iommu group 3
[    9.504116] hantro-vpu ff650000.video-codec: registered rockchip,rk3399-vpu-enc as /dev/video1
[    9.538688] hantro-vpu ff650000.video-codec: registered rockchip,rk3399-vpu-dec as /dev/video2
[   21.562365] hdmi-audio-codec hdmi-audio-codec.8.auto: Only one simultaneous stream supported!
[   21.563144] hdmi-audio-codec hdmi-audio-codec.8.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -22

• codec seems to work
  but I still need some way to test if it's using software or hardware codec decoding

• I tested it with LXQT, it's blazing fast with DeitPI

• the testing of the CURRENT kernel is on the way