ROCK(Pro)64 won't boot with Linux 6.12

Troubleshooting
41

Here’s what ended up working for me:

Flashed an older DietPi build and booted from USB.

As soon as I got SSH access, I hit Ctrl + C to interrupt the auto-update and ran:

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

After rebooting, I installed mtd-utils to enable SPI flashing:

apt update  
apt install mtd-utils

Then flashed the SPI bootloader:

source /usr/lib/u-boot/platform_install.sh  
write_uboot_platform_mtd "$DIR"

Rebooted again, then finally ran:

dietpi-update

The device is now booting fine with the new kernel!

Note: On the older DietPi build I used (v9.12), dietpi-config only had the option to update the MMC bootloader — not the SPI bootloader. I guess that was added later, as I now see the option to update the SPI in v9.14.

Thanks everyone for the help — much appreciated!

2 Likes
42

Yes exactly, it was added it for ROCK64 and ROCKPro64 with DietPi v9.14, hence the need to call the write_uboot_platform_mtd manually until then.

Okay great that this got all finally sorted. Not sure what the issue with the old bootloader and new kernel was, most likely some too narrow addresses to load the grown kernel and/or initramfs to, so that some parts were overwriting each other. So in the end my original guess was right, and it was the very same thing with the 2017 U-Boot on SPI, matching also the report at the Armbian forum: ROCK(Pro)64 won't boot with Linux 6.12 - #14 by MichaIng

But what I was not aware of is that on both SBCs, the SPI bootloader is always used with priority, if present. Maybe it makes sense to define an own set of functional load addresses for each kernel, not relying on the bootloader to do this with enough space for recent kernel and initramfs.