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.
Also since the kernel upgrade? Also the bootloader package was upgraded, but not flashed.
I get more errors than you , 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 . 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?
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.
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.
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.
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
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.
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.
@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.