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.
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.
After getting the device to boot with the new bootloader flashed, I noticed an issue with reboots.
If I run sudo reboot, the device doesn’t come back online — it just hangs silently.
However, if I run sudo poweroff, then physically disconnect and reconnect the power, it boots fine every time.
So cold boots work, but warm reboots (via reboot) don’t.
I got a personal server with this issue, and I didn’t want to try the update since I would be very annoyed if it couldn’t reboot, so I was preparing another one in my free time, expecting to move services on the other when it is ready, but there is still a lot to do because I don’t have much time for it actually.
So after each upgrade, I just reinstalled the last kernel package that worked form me (24.11.0-trunk-dietpi1) until now, and it was all I needed until my secondary server becomes ready.
But today, after the last update, I couldn’t reinstall kernel 24.11.0-trunk-dietpi1 anymore, so I was stuck with a machine I couldn’t reboot anymore because I really need it working…
I then tried to update my SPI with the methods given in this thread, but I had several issues:
With dietpi-config, the install ends with:
flashcp: invalid option – ‘p’
So I tried the manual way, and noticed I had to change the package name from linux-u-boot-rock64-current.deb to linux-u-boot-rockpro64-current.deb. Both are so close I didn’t notice the example was for Rock64, not for RockPro64. Then I launched the following commends, until write_uboot_platform_mtd, and got again:
flashcp: invalid option – ‘p’
I had a look in /boot/dietpi/dietpi-config and found the flash command, but without any ‘p’ option. I found however the write_uboot_platform_mtdb but I can’t find it anywhere in the system or in the aliases. I have no idea where it comes from, but the problem seems to lie there….
I am stucked with a freshly upgraded machine I can’t reboot for now, because I know it can’t reboot at all for now… could it be possible to have some help, either giving me a way to find my old kernel, or by providing a way to correct this write_uboot_platform_mtdb command ?
After some more researches, I discovered the source command I didn’t know. So I had a look in /usr/lib/u-boot/platform_install.sh, found the write_uboot_platform_mtd function and removed the -p option from the line containing flashcp, then it seemed to work this time.
I would be glad, however, if someone could tell me if this is really fine, or if something supposed to be handled by this -p option may be missing… it doesn’t seem to be the case to me, but a more expert opinion would be appreciated.
Yes, I am using a Bullseye system since I need to prepare another server to take over in case something goes wrong when upgrading to Bookworm, or even Trixie if possible, and I had little time to work on it for a while.
In fact, the -p option doesn’t exist on my flashcp version. This is what caused the failure.
But the description i get from flascp -h tells that flashcp [options] do the job, so it should work without the -p option… am I right ?
Okay good to know. I’ll apply a function rewrite to remove the -p flag on Bullseye systems. It makes flashcp write only changed bits to the SPI flash, so it works well without it, just a little slower.
Just a quick update from my side:
Over the last 3–4 upgrades, the original issue has started to reappear. After applying updates, the board no longer reboots cleanly — the only way I can get it to come back up and running is
I have two of these devices, running from various ages of install and I have no problems with updates, reboots, restarts, apt update, apt upgrade, dietpi-upgrade etc…. Basically whenever I realize an update is out I install it and no problems so far.
Hey All - I just tried to bring to life a ROCK64 I had running on DietPi Buster (yay, pandemic project!). After updating it, it would not boot.
I tried doing a fresh headless automated install with DietPi Bookworm and Trixie (and even just Armbian Bookworm), but there seems to be some issue at the … PHY layer? (detects ethernet, but can’t get a link)
So two questions:
1 - Is this at all related to the latest kernels and needing to update the SPI bootloader? I’m guessing now, but after trying various builds and configs, I’m grasping at straws.
2 - If not, is there any best practice for debugging a headless install, as I only seem to find first boot logs and the HDMI out also doesn’t want to work.
