No HDMI output after 8.21.1 update on Orange Pi 5

I ran dietpi-update to update Orange Pi 5 to the latest version. However, the update caused the system not to recognize the HDMI output from the Orange Pi 5 to the monitor. Logging into the machine with ssh worked as intended. Just no HDMI output with 8.21.1.

Luckily I ran dietpi-backup and restored the system back to 8.20.1, and HDMI output from Orange Pi 5 to the monitor worked fine.

Is anyone else having this issue?

1 Like

hmm maybe related to the kernel update? :thinking:

ping @MichaIng

HDMI works fine here on both of my OPi’s, 5 and 5 Plus :thinking:. @Joulinar and @StephanStS does it work for you (when you find time for testing)?

@Pr3259
Can you check for kernel errors on SSH?

dmesg -l 0,1,2,3

There are many, so don’t worry, but I want to compare your output with mine. Probably there is some difference giving a hint.

Here is the output from 8.21.1 as requested:

[    3.214472] fiq_debugger fiq_debugger.0: IRQ fiq not found
[    3.214484] fiq_debugger fiq_debugger.0: IRQ wakeup not found
[    3.214493] fiq_debugger_probe: could not install nmi irq handler
[    3.857982] rk-pcie fe190000.pcie: IRQ msi not found
[    3.858020] rk-pcie fe190000.pcie: Missing *config* reg space
[    3.858246] rk-pcie fe190000.pcie: Missing *config* reg space
[    3.858290] rk-pcie fe190000.pcie: invalid resource
[    3.863776] mpp-iep2 fdbb0000.iep: allocate roi buffer failed
[    3.865488] mpp_rkvdec2 fdc38100.rkvdec-core: shared_niu_a is not found!
[    3.865496] rkvdec2_init:1022: No niu aclk reset resource define
[    3.865503] mpp_rkvdec2 fdc38100.rkvdec-core: shared_niu_h is not found!
[    3.865510] rkvdec2_init:1025: No niu hclk reset resource define
[    3.866252] mpp_rkvdec2 fdc48100.rkvdec-core: shared_niu_a is not found!
[    3.866259] rkvdec2_init:1022: No niu aclk reset resource define
[    3.866267] mpp_rkvdec2 fdc48100.rkvdec-core: shared_niu_h is not found!
[    3.866273] rkvdec2_init:1025: No niu hclk reset resource define
[    3.867256] mpp_rkvenc2 fdbd0000.rkvenc-core: dev_pm_opp_set_regulators: no regulator (venc) found: -19
[    3.867278] rkvenc_init:1814: failed to add venc devfreq
[    3.867863] mpp_rkvenc2 fdbe0000.rkvenc-core: dev_pm_opp_set_regulators: no regulator (venc) found: -19
[    3.867880] rkvenc_init:1814: failed to add venc devfreq
[    3.887829] dw-dp fde50000.dp: error -ENOENT: failed to get hdcp clock
[    3.921949] rk806 spi2.0: no sleep-setting state
[    3.921960] rk806 spi2.0: no reset-setting pinctrl state
[    3.921968] rk806 spi2.0: no dvs-setting pinctrl state
[    3.928283] rk_gmac-dwmac fe1c0000.ethernet: no regulator found
[    3.928311] rk_gmac-dwmac fe1c0000.ethernet: Can not read property: rx_delay.
[    3.928320] rk_gmac-dwmac fe1c0000.ethernet: set rx_delay to 0xffffffff
[    3.928352] rk_gmac-dwmac fe1c0000.ethernet: cannot get clock mac_clk_rx
[    3.928362] rk_gmac-dwmac fe1c0000.ethernet: cannot get clock mac_clk_tx
[    3.928380] rk_gmac-dwmac fe1c0000.ethernet: cannot get clock clk_mac_speed
[    4.242489] Error: Driver 'Goodix-TS' is already registered, aborting...
[    4.357248] Goodix-TS 2-0014: i2c test failed attempt 1: -6
[    4.383910] Goodix-TS 2-0014: i2c test failed attempt 2: -6
[    4.410417] Goodix-TS 2-0014: I2C communication failure: -6
[    4.557225] Goodix-TS 7-0014: i2c test failed attempt 1: -6
[    4.583882] Goodix-TS 7-0014: i2c test failed attempt 2: -6
[    4.610388] Goodix-TS 7-0014: I2C communication failure: -6
[    4.611655] rkcifhw fdce0000.rkcif: failed to get iclk_host0
[    4.676819] arm-scmi firmware:scmi: Failed. SCMI protocol 17 not active.
[    4.709207] ES8323 6-0010: ASoC: error at soc_component_write_no_lock on ES8323.6-0010: -5
[    4.818472] debugfs: Directory 'fb000000.gpu-mali' with parent 'vdd_gpu_s0' already present!
[    4.819886] rkcifhw fdce0000.rkcif: failed to get iclk_host0
[    4.822021] rockchip-dmc dmc: failed to get vop bandwidth to dmc rate
[    4.822033] rockchip-dmc dmc: failed to get vop pn to msch rl
[    4.822227] rockchip-dmc dmc: could not find power_model node
[    4.823613] dw-dp fde50000.dp: error -ENOENT: failed to get hdcp clock
[    4.837399] RKNPU fdab0000.npu: can't request region for resource [mem 0xfdab0000-0xfdabffff]
[    4.837444] RKNPU fdab0000.npu: can't request region for resource [mem 0xfdac0000-0xfdacffff]
[    4.837470] RKNPU fdab0000.npu: can't request region for resource [mem 0xfdad0000-0xfdadffff]
[    4.843363] debugfs: Directory 'fdab0000.npu-rknpu' with parent 'vdd_npu_s0' already present!
[    4.872829] RKNPU fdab0000.npu: failed to find power_model node
[    4.872886] RKNPU fdab0000.npu: RKNPU: failed to initialize power model
[    4.872914] RKNPU fdab0000.npu: RKNPU: failed to get dynamic-coefficient
[    5.232527] cma: cma_alloc: cma: alloc failed, req-size: 512 pages, ret: -12

@MichaIng actually having a different challenge an my OPi5 as it’s not booting anymore from NVMe. I definitely need to get a USB to serial adapter :wink:

Also since the kernel upgrade? Also the bootloader package was upgraded, but not flashed.

I get more errors than you :sweat_smile:, many related to Ethernet, likely because I have an Ethernet cable attached and you probably not? And then two related to PCIe, probably because I have no NVMe SSD attached, and you do? And your OPi 5 boots 3 seconds faster than mine, at least all these errors are up to 3 seconds earlier *hmpf*.

But I do not have the following ones:

[    3.887829] dw-dp fde50000.dp: error -ENOENT: failed to get hdcp clock
[    4.611655] rkcifhw fdce0000.rkcif: failed to get iclk_host0
[    5.232527] cma: cma_alloc: cma: alloc failed, req-size: 512 pages, ret: -12

The first is about the DisplayPort, which is the second USB-C port. Do you have something attached there? As you say HDMI, I guess the screen is attached to the HDMI port? There is a report with the same error message on a repo which provides RK3588 Ubuntu images with the same kernel sources, latest image also with 5.10.160: Screen over usbc doesn't work · Issue #101 · Joshua-Riek/ubuntu-rockchip · GitHub
They seem to have issues when using the HDMI and USB-C port concurrently.

The second is actually about CSI camera device/host. But sometimes output and capture devices/drivers are somehow tied.

The last is about CMA, the RAM allocated from system memory to the GPU. I know this exact error message from RPi, which did contain a bug in the past where this memory allocation failed. However, this was when KMS was still experimental on RPi. Do you have the 4, 8 or 18 GiB RAM model?

So all those have something to do with video stuff, suspicious :thinking:. Do you have another HDMI screen, or even just another (shorter or stronger) HDMI cable to reduce possible signal strength needs?

I have a USB hub attached to a USB 3 port, with nothing attached to the hub. The HDMI cable is plugged from the Orange Pi 5’s HDMI port directly to the HDMI port of the monitor. I am not using the USB-C at all. I have the 8 GiB model.

I have the ethernet cable attached. No issue with networking. I am also booting from the NVME, no issues.

I don’t have another HDMI screen, so I can’t test that option. I tried another cable, same result. I also unplugged the USB hub, same result.

Okay, I have the 8 GiB model as well. I just thought that some kernel bug might lead to CMA being tried to be allocated from an address above 4 GiB on 4 GiB model would cause the issue.

I also have no Ethernet issues despite the additional error messages on my end. The error indicates that it fails to read and write a MAC address. But finally it assigns one.

However, Ethernet is not the issue. But one difference is that you boot from NVMe, hence via SPI bootloader, while I boot from SD card via the bootloader that ships with our image, which probably initialises things a little different. Do you have a spare SD card to test whether this makes a difference?

And do you know which bootloader is flashed on the SPI? Is it still the original one, or one from Armbian or was it flashed from our image via dietpi-config?

My results are:

  • Starting from DietPi v8.16.2
    • Kernel (uname -r): 5.10.110-rockchip-rk3588
    • LAN connection via RJ45
    • HDMI works fine
    • Booting from nvme works fine
    • ssh to OPi5 works fine
  • Updating to DietPi v8.21.1
    • Kernel (uname -r): 5.10.160-rk35xx
    • LAN connection via RJ45
    • HDMI does not work after reboot
    • Booting from nvme works fine
    • ssh to OPi5 works fine
    • The reboot worked from nvme (ssh login, but no HDMI), but doing a full power cycle afterwards does lead to a ?non booting system?, at least a system not accessible via ssh and the system is not ping’able.
1 Like

Hmm, why does everything work well on my end? The only difference you both have is NVMe. So same thing, if you have an SD card to test with, that would be great.

something I will do tomorrow

There are two reports related to HDMI output at the Armbian forum:

I’ll also do new builds of kernel and bootloader, just in case something has changed within the last month.

ok the OPi5 is booting of SD card with HDMI but there is nothing using NVMe. It’s not booting at all.

Loading the DietPi 8.21.1 from the SD card worked fine (with HDMI output). However, after removing the SD card, the system wouldn’t boot from the existing NVMe card. Booting again from the SD card, I re-flashed the SPI partition using the dietpi-config, but this did nothing. Still no boot from the NVMe, and no HDMI output.

I tried installing the Armbian (with Linux 5.10.160-rk35xx kernel), and HDMI output worked at boot, and the system booted from NVMe. After switching HDMI inputs on the monitor, I can’t seem to get back HDMI output to work. But HDMI output worked immediately after boot, and ssh still works.

Impressive, @StephanStS. I had exactly the same experience after latest dietpi (kernel) upgrade (I boot from SD card though) - also ended with non-booting system after power-off using on board button.

I made some experiments before system re-flash, including NVMe drive disconnection. I will update later on this thread after doing few more tests and reading Armbian forum posts shared here by @MichaIng.

@Pr3259, @StephanStS - from practical point of view:

  • I ordered a spare TF card, USB-C-to-HDMI cable and USB-to-TTL module - once I have it with me, I will reproduce the problem (including, I hope, unbootable system) and will file a defect. If you can do it earlier, please, help with the same. Unfortunately I can’t describe repro steps (with correspondent states) from memory, so I will have to do it again. What I can say for sure, it is the key for successful repro, since new installation worked fine in my case:

dietpi-update : Run now to update DietPi from v8.20.1 to v8.21.1

Update:

I did further tests with the OPi 5 Armbian image converted to a DietPi system.

Test #1: Using the actual Bookworm Armbian image
Result: This works with HDMI also when I moved the system to the nvme disk and booted from it.

My output showing the booting from the nvme disk:

root@opi5:~# lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
mtdblock0    31:0    0    16M  0 disk
zram0       254:0    0     0B  0 disk
nvme0n1     259:0    0 238,5G  0 disk
├─nvme0n1p1 259:1    0   256M  0 part /boot
└─nvme0n1p2 259:2    0     7G  0 part /

Used base image from Armbian: https://redirect.armbian.com/region/EU/orangepi5/Bookworm_legacy_minimal.

Also booting the system with disconnected HDMI monitor and connecting it after the boot process has finished shows an HDMI output.

Test #2: Using the actual DietPi Bookworm image
Result: This works with HDMI also when I moved the system to the nvme disk and booted from it.

Used DietPi image: https://dietpi.com/downloads/images/DietPi_OrangePi5-ARMv8-Bookworm.7z.

Test #3: Using an older (03/2023) DietPi Bullseye image
Result: During the first run installation the HDMI output became dark, the update finished (I did it via ssh). The following reboot did not work any more, no booting occured.

I would assume it is identical to the actual downloadable Bullseye image: https://dietpi.com/downloads/images/DietPi_OrangePi5-ARMv8-Bullseye.7z (did not test it).

Conclusions
Did the guys with the failing HDMI output start from an Bullseye image? If yes, please set up your system (from scratch) with the actual DietPi Bookworm image and share your results.

I can confirm your observation, with a new Bookworm image, boot from nvme and HDMI are working

1 Like

@Pr3259: Can you tell us what your starting point was? Was it a converted bullseye system or a fresh bookworm installation?

@MichaIng: I observed a couple of times that my bullseye-to-bookworm converted systems had some troubles later on. No idea, what the causes for these problems were, I did not investigate further. The next time I get this status I will try to investigate this together with you.

@StephanStS: Great find; I think this may be closer to the solution.Originally I started with the bullseye system which was converted to bookworm via the DietPi update script. After the conversion to bookworm, no HDMI. I also did a test by flashing a brand new bookworm DietPi image on an SD card, and it all went fine. From that image I flashed the same DietPi bookworm image onto the NVMe card, but this did not want to boot at all. I did not investigate further.