ArtP

After upgrading to kernel 6.10.1-edge-rockchip-rk3588 I started getting: fdee0000.hdmi_receiver: hdmirx_wait_lock_and_get_timing: HDMI pull out, return on the console. This repeats constantly and quite rapidly, and just doesn't stop. I can silence it by plugging a monitor into HDMI port, but... I prefer to run my board headless (serial + net). Does anybody know any other way to get rid of this? This "feature" was absent with the -rc7 kernel.

@Spo0lsh This makes sense!. This looks like an equivalent of the "vendor-provided fix" I got from Orange Pi folks. Re-flash SPi with current, good u-boot, and all of sudden things work again. It seems that the DDR driver included with u-boot might be the culprit. I originally had V1.08 20220617 and it was unstable. With the update, I have DDR d5483af87d cym 23/11/23-16:15:24,fwver: v1.15 and things are looking good. The commit message in rockchip-linux/rkbin (place where si0ls/u-boot-orangepi5 gets its blobs from) says "rk3588: ddr: update ddrbin to v1.16". So, chances are, the u-boot there has a DDR driver v1.16 Armbian latest 24.5.1 bookworm image seems to contain u-boot with DDR driver version V1.08 20220617. So, if this gets flashed in SPI, Orange pi5 plus (32 GB version) will become unstable. In hindsite, this is what happened to me.

I ran into OPI5+ 32GB stability issues as well. It would throw kernel panic under heavy load. It would throw kernel panic consistently when I did my favourite test: copy the eMMC (or /dev/nvme0n1) to /dev/null using dd. First 4-5 GB would copy, and then - kernel panic. So... I reached out to the manufacturer. Luckily, i bought my board via their Amazon store front. Ultimately, their latest image offered updated u-boot with a new DDR driver. Once I reflashed the SPI flash, my test started working. It is working with the orange pi image and with Armbian image sitting on my /dev/nvme0n1. No crashes so far.