DietPi icon indicating copy to clipboard operation
DietPi copied to clipboard
verified publisher icon MichaIng

RK3399 | No HDMI output with default mode

Open ihipop opened this issue 1 year ago • 20 comments

Creating a bug report/issue

  • [x] 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

ihipop avatar Jan 02 '25 02:01 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.

MichaIng avatar Jan 02 '25 11:01 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.

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

ihipop avatar Jan 02 '25 14:01 ihipop

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

MichaIng avatar Jan 03 '25 07:01 MichaIng

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

ihipop avatar Jan 03 '25 07:01 ihipop

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

MichaIng avatar Jan 03 '25 07:01 MichaIng

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 https://github.com/armbian/build/pull/2016

ihipop avatar Jan 03 '25 07:01 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

ihipop avatar Jan 03 '25 07:01 ihipop

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.

MichaIng avatar Jan 03 '25 08:01 MichaIng

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

ihipop avatar Jan 03 '25 08:01 ihipop

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.

MichaIng avatar Jan 03 '25 08:01 MichaIng

  • 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

ihipop avatar Jan 03 '25 09:01 ihipop

The bad news is that the HDMI of the CURRENT kernel is broken too the error of hdmi-audio-codec still exists

[   30.768380] hdmi-audio-codec hdmi-audio-codec.8.auto: Only one simultaneous stream supported!
[   30.769160] hdmi-audio-codec hdmi-audio-codec.8.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -22

so the HDMI is fixed when kernel is above 6.12 which curious me which commit fixed it

ihipop avatar Jan 03 '25 09:01 ihipop

Interesting, thanks for testing. There have been quite some patches removed/consolidated with Armbian's edge branch, some of them which could be done on current branch as well, after it has been migrated to Linux 6.12. I'll have a closer look, maybe we can do some of them on our fork.

But probably good to compare Linux 6.12 and 6.13 in Linux upstream first, maybe we missed something along the device tree includes.

MichaIng avatar Jan 03 '25 11:01 MichaIng

Sorry, I moreless forgot about this issue. Was digging into recent Rockchip kernel and HDMI while implementing Orange Pi 5 Ultra support, and indeed there have been some patches backported to Linux 6.12 in the meantime, and we removed an obsolete patch that doubled some definitions. Otherwise looks sane.

Could you retest with recent testing build:

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

MichaIng avatar Jun 02 '25 21:06 MichaIng

Edit: This could be a different issue (RK3588, which I am using on my OPI5+), but it does seem the major upstreaming progress focuses on RK3588, including the patches merged in 6.13 specifically for supporting HDMI output, as briefed in this article: https://www.collabora.com/news-and-blog/news-and-events/rockchip-rk3588-upstream-support-progress-future-plans.html

Hi Michal, I can confirm that with the above kernel, as of today (it seems there have been new versions uploaded under the above URL), HDMI NOT work on my OrangePi 5 Plus (running Armbian for now). This is more or less expected, though. Thanks for the effort of investigating! Here are some kernel logs I got from journalctl -k:

Aug 22 23:09:20 orangepi5-plus kernel: rockchip-drm display-subsystem: bound fdd90000.vop (ops vop2_component_ops [rockchipdrm])
Aug 22 23:09:20 orangepi5-plus kernel: dwhdmiqp-rockchip fde80000.hdmi: registered DesignWare HDMI QP I2C bus driver
Aug 22 23:09:20 orangepi5-plus kernel: rockchip-drm display-subsystem: bound fde80000.hdmi (ops dw_hdmi_qp_rockchip_ops [rockchipdrm])
Aug 22 23:09:20 orangepi5-plus kernel: [drm] Initialized rockchip 1.0.0 for display-subsystem on minor 0
Aug 22 23:09:20 orangepi5-plus kernel: panthor fb000000.gpu: [drm] clock rate = 198000000
Aug 22 23:09:20 orangepi5-plus kernel: panthor fb000000.gpu: [drm] mali-g610 id 0xa867 major 0x0 minor 0x0 status 0x5
Aug 22 23:09:20 orangepi5-plus kernel: panthor fb000000.gpu: [drm] Features: L2:0x7120306 Tiler:0x809 Mem:0x301 MMU:0x2830 AS:0xff
Aug 22 23:09:20 orangepi5-plus kernel: panthor fb000000.gpu: [drm] shader_present=0x50005 l2_present=0x1 tiler_present=0x1
Aug 22 23:09:20 orangepi5-plus kernel: rockchip-rga fdb80000.rga: HW Version: 0x03.02
Aug 22 23:09:20 orangepi5-plus kernel: rockchip-rga fdb80000.rga: Registered rockchip-rga as /dev/video0
Aug 22 23:09:20 orangepi5-plus kernel: panthor fb000000.gpu: [drm] Firmware protected mode entry not be supported, ignoring
Aug 22 23:09:20 orangepi5-plus kernel: panthor fb000000.gpu: [drm] CSF FW v1.1.0, Features 0x0 Instrumentation features 0x71
Aug 22 23:09:20 orangepi5-plus kernel: [drm] Initialized panthor 1.0.0 for fb000000.gpu on minor 1
Aug 22 23:09:20 orangepi5-plus kernel: rockchip_vdec2: module is from the staging directory, the quality is unknown, you have been warned.
Aug 22 23:09:20 orangepi5-plus kernel: rkvdec2 fdc40000.video-decoder: missing multi-core support, ignoring this instance
Aug 22 23:09:20 orangepi5-plus kernel: hantro-vpu fdb50000.video-codec: Adding to iommu group 1
Aug 22 23:09:20 orangepi5-plus kernel: hantro-vpu fdb50000.video-codec: registered rockchip,rk3328-vpu-dec as /dev/video2
Aug 22 23:09:20 orangepi5-plus kernel: hantro-vpu fdba0000.video-codec: Adding to iommu group 2
Aug 22 23:09:20 orangepi5-plus kernel: hantro-vpu fdba0000.video-codec: registered rockchip,rk3588-vepu121-enc as /dev/video3
Aug 22 23:09:20 orangepi5-plus kernel: hantro-vpu fdba4000.video-codec: Adding to iommu group 3
Aug 22 23:09:20 orangepi5-plus kernel: hantro-vpu fdba4000.video-codec: missing multi-core support, ignoring this instance
Aug 22 23:09:20 orangepi5-plus kernel: hantro-vpu fdba8000.video-codec: Adding to iommu group 4
Aug 22 23:09:20 orangepi5-plus kernel: hantro-vpu fdba8000.video-codec: missing multi-core support, ignoring this instance
Aug 22 23:09:20 orangepi5-plus kernel: hantro-vpu fdbac000.video-codec: Adding to iommu group 5
Aug 22 23:09:20 orangepi5-plus kernel: hantro-vpu fdbac000.video-codec: missing multi-core support, ignoring this instance
Aug 22 23:09:20 orangepi5-plus kernel: hantro-vpu fdc70000.video-codec: registered rockchip,rk3588-av1-vpu-dec as /dev/video4

CL-Jeremy avatar Aug 22 '25 21:08 CL-Jeremy

Let me reopen this, since @StephanStS also faces HDMI issues on two other RK3399 SBCs with Linux 6.12. Linux 6.16 (edge) solves it, but otherwise the default mode chosen by the driver does not seem to work with the HDMI driver/port for unknown reasons. It works when enforcing 50Hz via video= kernel command-line parameter, e.g. via dietpi-display, using 1920x1080@50 as custom mode.

@CL-Jeremy I assume on RK3588 it is a different issue. By default, it uses a pretty different kernel, based on Rockchip's Linux 6.1 sources, instead of mainline Linux. If you installed the current-rockchip64 kernel above, you switched to mainline, which generally works as well, but e.g. does not support the NPU and limited VPU and GPU acceleration, using panthor kernel driver and hantro for the VPU, as can be seen in your logs.

This should be however the same on Armbian, same kernel sources, same package build system. Your Armbian image also runs Linux 6.1 vendor-rk35xx kernel, right? They also offer images with mainline Linux, but the vendor kernel one should be still the prominently offered default. So if you get HDMI output with the Armbian image, a closer look at the package versions would be interesting:

dpkg -l | grep linux-

Probably it uses an older version, and some issue has been introduced more recently. Or, less likely but possible, Armbian updated their packages very recently, and they contain a fix. That would be great, as then easy to fix our end with a kernel rebuild.

Ah, and do you use a CLI image from Armbian, or a desktop image? Because an X11 or Wayland session is something entirely different than a plain Linux console session. X11 might also choose a different resolution etc. On DietPi, you can try different resolutions with dietpi-display, using also different refresh rates with a custom mode, like the example at the top of this comment. Though I would prefer this being tested with the vendor kernel, as this is still our default, and else we may compare apples with pears when taking Armbian and reference:

apt autopurge linux-{dtb,image}-current-rockchip64
apt install --reinstall linux-{dtb,image}-vendor-rk35xx

I can test it on my Orange Pi 5 Plus next week. This weekend busy with DietPi v9.16 release, with heavy Debian Trixie and software implementation focus. Next release cycle has more focus and hardware-specific issues, hopefully new SBC support etc.

MichaIng avatar Aug 22 '25 22:08 MichaIng

To describe the behaviour at my NanoPi M4v2 as well as NanoPi NEO4 more clear:

Kernel 6.12 (linux-image-current-rockchip64):

  • HDMI output does not work out of the box
  • Using dietpi-display works if set to these "custom values":
    • 1920x1080@50
    • 1280x720@50
    • also some other settings with lower resolutions work
  • Using dietpi-display does not work if set to these "custom values":
    • 1600x900@50 resp. 1600x900
    • 1280x720
    • 1920x1080

Kernel 6.16 (linux-image-edge-rockchip64):

  • HDMI output works out of the box and sets the resolution to 1600x900 (60 Hz)
  • Using dietpi-display works if set to these "custom values":
    • 1920x1080@50
    • 1600x900 resp. 1600x900@50
    • 1280x720 resp. 1280x720@50
    • also some other settings with lower resolutions work
  • Using dietpi-display does not work if set to these "custom values":
    • 1920x1080 (gives a wrong output on my screen)

This is the dialog of dietpi-display to set the resolution:

Image

StephanStS avatar Aug 23 '25 13:08 StephanStS

@MichaIng Hi, sorry for the late reply. I linked the above article on RK3588 since it is where I found the source (they authored the patch) of the problem discussed in the Armbian forum, where it was shown that a 6.13 rc kernel solved the HDMI output for that board. I have always been on mainline (due to security concerns), previously on current (6.12) and, soon after posting the above log, switched to edge (6.16) which solved the issue, which seems to coincide with what was reported in this issue for RK3399. I mentioned my case initially with the intention of testing out 6.12 series with backported patched from 6.13.x, since for RK3588 anything above 6.13 should have the HDMI issues fixed and nobody but you has come to the idea of backporting the relevant fixes to an LTS mainline kernel.

CL-Jeremy avatar Aug 24 '25 20:08 CL-Jeremy

@MichaIng : Shall we "re-close" this issue due to CL-Jeremy's response?

StephanStS avatar Aug 27 '25 21:08 StephanStS

It might be two dedicated issues, and I want to have another look into Linux 6.12 vs 6.13 as well as Armbian patches. It will take a while until "current" is switched. We don't even know which Linux version will be next LTS. Maybe we can fix something until then.

MichaIng avatar Aug 27 '25 21:08 MichaIng