Okay, that mystery solved. So both PINE64 Rockchip SBCs affected it seems?
We really need someone with a UART adapter to check serial console logs. If there is no output on HDMI, we otherwise have no real chance to check what is going wrong. So far I could not find any matching report at Armbian or commit there or upstream.
If you have time to test, I created new U-Boot builds. E.g. my ROCK Pi S required a new U-Boot binary to accept the device tree of Linux 6.12:
On ROCK64:
cd /tmp
wget https://dietpi.com/downloads/binaries/testing/linux-u-boot-rock64-current.deb
dpkg -i linux-u-boot-rock64-current.deb
/boot/dietpi/func/dietpi-set_hardware flash-uboot-mmc
reboot
On ROCKPro64:
cd /tmp
wget https://dietpi.com/downloads/binaries/testing/linux-u-boot-rockpro64-current.deb
dpkg -i linux-u-boot-rockpro64-current.deb
/boot/dietpi/func/dietpi-set_hardware flash-uboot-mmc
reboot
If you boot from USB or similar via SPI bootloader, flash that as well:
source /usr/lib/u-boot/platform_install.sh
write_uboot_platform_mtd "$DIR"
EDIT: Now found a topic at Armbian forum, which suggest that there might be some overlap between the memory spaces used by kernel, dtb, and initramfs: rock64: "Wrong Ramdisk Image Format" after upgrade to 6.12.9 - Rockchip - Armbian Community Forums
Maybe the size has increased a bit too much, so the addresses need to be set with larger offset between each other. This might be even fixed in newer U-Boot, since that is what sets these addresses. Our boot script does not override them for Rockchip SBCs. And the OP from the Armbian forum thread really used an ancient U-Boot build from 2017.
I can check the addresses on my NanoPi R4S (same kernel), which are hopefully the same on other Rockchip SBCs, and see whether they are possibly too close.