Rock64 - Cannot Boot from USB After Updating SPI U-Boot (DietPi v9.19.2 Trixie)

Troubleshooting
1

Help, this is the result of many hours of trying all sorts of stuff to get the rock64 to boot off a USB using trixie. It was working flawlessly on my bullseye install and broke when I upgraded to the latest dietpi.

– What Works

:white_check_mark: Rock64 V2, 1GB ram, boots perfectly from SD card with Trixie
:white_check_mark: Rock64 boots from SD card after SPI U-Boot update
:white_check_mark: Updated U-Boot package is correctly installed and flashed to SPI
:white_check_mark: USB drive works perfectly when booted from SD (can mount, read/write)
:white_check_mark: All multiple Rock64 boards in my possession (I have several)

– What Doesn’t Work

:cross_mark: Rock64 will not boot from USB when SD card is removed
:cross_mark: Result: All three LEDs solid (red, white, green) = boot failure
:cross_mark: No network activity, cannot SSHCreating a bug report/issue

– Verified boot loader install:

root@DietPi:~# dpkg -l | grep linux-u-boot-rock64-current
ii  linux-u-boot-rock64-current    26.02.0-trunk-dietpi1          arm64        Das U-Boot for rock64
root@DietPi:~# dd if=/dev/mtd0 bs=1M count=1 2>/dev/null | wc -c
1048576

– Issues found and fixed along the way:

Missing Journal

sudo tune2fs -j /dev/sda1

USB missing boot flag

echo -e "a\n1\nw" | sudo fdisk /dev/sda

Filesystem Not Expanded

# After booting from SD card 
echo -e "d\nn\n\n32768\n\nw" | sudo fdisk /dev/sda
sudo e2fsck -f /dev/sda1
sudo resize2fs /dev/sda1

– USB drives, ports and boards

I have multiple boards and multiple USB drives. I tried both USB 2.0 ports. Alwasy solid LED lights.

– Other test

Clone sd card to the USB with dd

# Booted from SD card
sudo dd if=/dev/mmcblk0 of=/dev/sda bs=4M status=progress conv=fsync
# Successfully copied 7.9GB in ~342 seconds

# Then expanded to full USB capacity
echo -e "d\nn\n\n32768\n\nw" | sudo fdisk /dev/sda
sudo e2fsck -f /dev/sda1
sudo resize2fs /dev/sda1

# Re-set boot flag (lost during fdisk operation)
echo -e "a\n1\nw" | sudo fdisk /dev/sda

– Bash command outputs

fdisk

fdisk -l
Disk /dev/mtdblock0: 16 MiB, 16777216 bytes, 32768 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mmcblk0: 7.4 GiB, 7948206080 bytes, 15523840 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x177980de

Device         Boot Start      End  Sectors  Size Id Type
/dev/mmcblk0p1 *    32768 15523839 15491072  7.4G 83 Linux


Disk /dev/sda: 29.88 GiB, 32080200192 bytes, 62656641 sectors
Disk model: Flash Drive FIT
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xf7138353

Device     Boot Start      End  Sectors  Size Id Type
/dev/sda1  *    32768 62656640 62623873 29.9G 83 Linux

ls /mnt/usb/boot

root@DietPi:~# sudo mount /dev/sda1 /mnt/usb
root@DietPi:~# ls -la /mnt/usb/boot/
total 61144
drwxr-xr-x  4 root root     4096 Dec 16 02:15 .
drwxr-xr-x 19 root root     4096 Dec 16 02:14 ..
lrwxrwxrwx  1 root root       34 Dec 15 07:03 Image -> vmlinuz-6.12.61-current-rockchip64
-rw-r--r--  1 root root  5561030 Dec  7 17:38 System.map-6.12.61-current-rockchip64
-rw-r--r--  1 root root     3153 Nov 16 01:56 boot.cmd
-rw-r--r--  1 root root     3225 Nov 16 01:57 boot.scr
-rw-r--r--  1 root root   259201 Dec  7 17:38 config-6.12.61-current-rockchip64
drwxr-xr-x  4 root root     4096 Dec 15 07:06 dietpi
-rw-r--r--  1 root root    18092 Nov 15 23:05 dietpi-LICENSE.txt
-rw-r--r--  1 root root    16637 Nov 15 23:05 dietpi-README.md
-rw-------  1 root root     3950 Jan  1  2021 dietpi-wifi.txt
-rw-r--r--  1 root root    19847 Dec 15 07:05 dietpi.txt
-rw-r--r--  1 root root      370 Jan  1  2021 dietpiEnv.txt
lrwxrwxrwx  1 root root       30 Dec 15 07:03 dtb -> dtb-6.12.61-current-rockchip64
drwxr-xr-x  3 root root     4096 Dec 15 07:00 dtb-6.12.61-current-rockchip64
lrwxrwxrwx  1 root root       37 Dec 15 07:03 initrd.img -> initrd.img-6.12.61-current-rockchip64
-rw-r--r--  1 root root 18809585 Dec 15 07:03 initrd.img-6.12.61-current-rockchip64
-rw-r--r--  1 root root 37878272 Dec  7 17:38 vmlinuz-6.12.61-current-rockchip64
2

Maybe a problem with SPI flash. Did you tried something described on this? linux-build/recipes/flash-spi.md at a6f5693455d4d7fe204079019b7d28a92b2c3784 · ayufan-rock64/linux-build · GitHub

Maybe @MichaIng has some other ideas

3

Hello,
the Rock64 can not boot from USB. The bootloader must stay on the SD card or on the SPI flash.
So copying the SD to USB is useless.

But it looks like the SPI-U-boot is installed correctly.
Sometimes the USB devices are not initialized fast enough so u-boot can not find it in time.
Do you use USB sticks or what kind of USB devices?

And can you double-checke the boot order you have set as well as the contents of boot.cmd?
And it would be very helpful if you have an UART adapter so we could check what is happening during the boot process.

4

Generally it works/worked, as somewhat recently the kernel/initramfs size was raising above a limit older/vendor U-Boot builds on SPI could handle (memory address overlaps), so after a kernel upgrade, a bunch of PINE64 SBCs could not boot from USB/NVMe anymore, like ROCK64 and ROCKPro64. Flashing our current linux-u-boot-rock(pro)64-current solved that. In the same turn, I added the “Flash SPI bootloader” entry for ROCK64 to dietpi-config advanced options. @supervenicianfrog you used that option to flash the bootloader, right?

Do you have a UART adapter to check serial console output?

That is expected: Our images ship without ext4 journal, but it is created on first boot after filesystem expansion, so it gets a proper size and location, based on final filesystem size. In case of ROCK64 (any image with an initramfs), this implies one reboot, since fsck in the initramfs needs to be forced once to import the generated /.journal file to the hidden inode 8. Without forcing this once, the system will hang in initramfs on next reboot, and requires an additional manual power cycle to solve. However, this all happens after bootloader stage, while in your case, with all LEDs remaining solid, I think it fails in bootloader stage, not reaching the point of partition and filesystem expansion.

That you adding the journal did not solve it, kinda proves that this was not the issue.

Not needed, not taken into account by U-Boot.

I’ll check for recent changes done in U-Boot or Armbian patches for the ROCK64.

You could test some older U-Boot versions, check available ones:

apt policy linux-u-boot-rock64-current

EDIT: Nah, the U-Boot sources are the same since a long time, v2022.07 (don’t ask me why Armbian defaults to a >3 years old version), and last patch commit was 7 months ago, and unrelated to such potential problem. But the ROCK64 has a lot of revisions, maybe it never worked with this one. @supervenicianfrog which U-Boot version/build did your Bullseye system use? Our builds are distro version-agnostic, so the very same packages are shipped for Bullseye and Trixie. Hence there must be some other underlying difference, like you used a vendor U-Boot build or so.

5

Thanks for the reply. I did run the “Flash SPI bootloader” from the ROCK64 dietpi-config. For my working bullseye setup, it was a while back but I believe it was using the GitHub - ayufan-rock64/linux-u-boot version. Once installed I definitely didn’t need an SD card. So, as far as I can tell bullseye + ayufan-rock64 worked and trixie + linux-u-boot-rock64-current is not working.

I suppose I can use the u-boot-erase-spi-rock64.img.xz image and reinstall ayufan-rock64/linux-u-boot , and then see if a fresh bullseye install works.

Do you have any other suggestions? Which is the latest dietpi to use for this? I got into this trouble during an automatic trixie upgrade that occured as I was adding a new package to my install.

I’m trying to run a squeezelite and a home assistant server on the same machine. it’s a rock64 v2.0 with 1 gb ram, 2017 0713

6

Use a Trixie image, we drop Bullseye (“oldoldstable”) support with next release. The kernel is the same anyway.

Would be interesting to see serial console output with linux-u-boot-rock64-current on SPI, if there is a chance.