U-Boot mainline to SPI on Rock 5B

ROCK 5 Series 5B/5B+
1

I’ve been trying unsuccessfully to get “mainline” u-boot on Rock 5B.

The repositories

In /home/foxx/src/c:

# TF-A
git clone https://github.com/ARM-software/arm-trusted-firmware.git 

# mainline u-boot
git clone https://source.denx.de/u-boot/u-boot.git

# Rockchip's blobs
git clone https://github.com/rockchip-linux/rkbin.git

Building

cd arm-trusted-firmware
make PLAT=rk3588

# ./build/rk3588/release/bl31.elf will appear
export BL31=/home/foxx/src/c/arm-trusted-firmware/build/rk3588/release/bl31/bl31.elf

cd ../u-boot
export ROCKCHIP_TPL=/home/foxx/src/c/rkbin/bin/rk35/rk3588_ddr_lp4_2112MHz_lp5_2400MHz_v1.21.bin
# there's also an rk3588_ddr_lp4_1848MHz_lp5_2112MHz_v1.21.bin
# and there are also _eyescan_v1.20 bin equivalent files
# didn't try

make rock5b-rk3588_defconfig
make -j4

I end up with idbloader.img, u-boot.itb and a ~2 MB u-boot-rockchip-spi.bin.

Download, here it goes wrong

Initially I was manually downloading idbloader.img and u-boot.itb at the BSP recommended offsets and it was bricking the device:

!this bricks the bootloader!

sudo dd if=idbloader.img of=/dev/mtdblock0 bs=512 seek=64 conv=fsync status=progress
sudo dd if=u-boot.itb of=/dev/mtdblock0 bs=512 seek=16384 conv=fsync status=progress
sync

Bricked afterwards, as those offsets are fine for the Radxa bootloader, not for mainline u-boot. Had to recover with an USB cable on the PC and with the Maskrom button / procedure:

Maskrom recovery on the PC

git clone https://github.com/rockchip-linux/rkdeveloptool.git
make
# it will generate ./rkdeveloptool

# keep the recovery button pressed, connect the USB-C cable, then depress the recovery button
# the PC will detect the Maskrom USB device
# double check it's there
./rkdeveloptool ld

# turn off USB sleep on the PC, otherwise flashing will error out:
sudo echo -1 > /sys/module/usbcore/parameters/autosuspend

# flash recovery, which will facilitate the SPI
# have to download this exact file, I don't know what the equivalent on HEAD from rkbin is
./rkdeveloptool db rk3588_spl_loader_v1.08.111.bin
# flash the Radxa SPI
./rkdeveloptool wl 0 rock-5b-spi-image-gd1cf491-20240523.img
# reboot the device
./rkdeveloptool rd
# can unplug and switch back to normal usage after

Correct offsets for mainline u-boot

Turns out the current u-boot offsets are 0x8000 for idbloader.img and 0x60000 for u-boot.bin.

Also failed directly with the already aligned u-boot-rockchip-spi.bin

I looked with ImHex at u-boot-rockchip-spi.bin (also generated by runing make in mainline u-boot) and it seems to already be aligned as required.

cd u-boot

# extend u-boot-rockchip-spi.bin from ~2 MB to exactly 16 MB
SPI_SIZE=$((16 * 1024 * 1024))
rm -f rock5b-mainline-spi.img
truncate -s $SPI_SIZE rock5b-mainline-spi.img
# populate the first ~2 MB out of exactly 16 MB with all the ~2 MB of the mainline built SPI
dd if=u-boot-rockchip-spi.bin of=rock5b-mainline-spi.img bs=4K conv=notrunc
# overwrite the SPI device
dd if=rock5b-mainline-spi.img of=/dev/mtdblock0 bs=4M conv=fsync status=progress
sync

Ends up still bricked, have to get back to the Maskrom on PC procedure.

What might I be doing wrong?

2

I also tried the Radxa rkbin, did nothing with the RAM image for rk3588_ddr_lp4_2112MHz_lp5_2400MHz, version 1.22.

3

I didn’t try SPI on my board, but writing u-boot-rockchip-spi.img directly to SPI should work. Why did you extend it?

Did you try the SD image generated from the same build? Is that working? Is SPI working in U-boot when booted from the SD? I belive I saw a setting in U-boot menuconfig for generating SPI images instead of SD. I don’t think the defconfig works for both.

Are you at least seeing the uart output of the DDR training blob?

4

I extended it because it wasn’t working. Still dind’t work after extending.

I didn’t try the SD image, I don’t think I need it, the OS boots from the SD card in my case.

No UART cable at the moment, waiting for one.

5

Just updated u-boot on mine a few days ago following u-boot’s docs and it’s working just fine. Comparing with my bash history we pretty much did the same thing:

# build TF-A
git clone --depth 1 https://github.com/TrustedFirmware-A/trusted-firmware-a.git
cd trusted-firmware-a
make realclean
make CROSS_COMPILE=aarch64-linux-gnu- PLAT=rk3588
cd ..

# build latest stable u-boot release 
git clone --depth 1 https://github.com/rockchip-linux/rkbin
git clone --depth 1 --branch v2026.07 https://source.denx.de/u-boot/u-boot.git
cd u-boot
export BL31=../trusted-firmware-a/build/rk3588/release/bl31/bl31.elf
export ROCKCHIP_TPL=../rkbin/bin/rk35/rk3588_ddr_lp4_2112MHz_lp5_2400MHz_v1.21.bin
make rock5b-rk3588_defconfig
make CROSS_COMPILE=aarch64-linux-gnu-

# spi
dd if=u-boot-rockchip-spi.bin of=/dev/mtdblock0
# emmc 
dd if=idbloader.img of=/dev/mmcblk0 bs=512 seek=64
dd if=u-boot.itb of=/dev/mmcblk0 bs=512 seek=16384
1 Like
6

If you can’t see uart output, how do you know u-boot is not working? It could be a boot config problem (trying to boot from wrong partition?), a device tree problem or a kernel problem. You really shouldn’t mess with u-boot if you don’t have a working uart.

BTW, where’s the kernel and the device tree?

What boot method are you using? Boot script / $bootcmd, or extlinux? Or something else?

You need it for testing. If SD image doesn’t work either, you probably have a compiler problem.

BTW, I just noticed that you didn’t cross-compile like @Flonsch. On what system did you run the compiler? On Rock5 directly, or on a PC/laptop?

7

Built directly on the Rock5B. Using Arch with extlinux. A slight difference I’m seeing is that I’m using HEAD instead of using the specific v2026.07 for uboot. I shall have the uart cable tomorrow.

8

@Flonsch I ended up compiling on my AMD64 machine and it just worked

Here’s exactly what I used on my desktop machine:

cd /home/foxx/src/c/rk3588 # on the desktop computer this time
git clone https://github.com/radxa/rkbin.git
git clone https://github.com/TrustedFirmware-A/trusted-firmware-a.git
git clone https://source.denx.de/u-boot/u-boot.git

cd rkbin
git log -1 # commit d6072c00ce7f83870f4ee0b5a74126039cbd08d9 (HEAD -> develop-v2026.01, origin/develop-v2026.01, origin/HEAD)
export ROCKCHIP_TPL=/home/foxx/src/c/rk3588/radxa-rkbin/bin/rk35/rk3588_ddr_lp4_2112MHz_lp5_2400MHz_v1.22.bin

cd ../trusted-firmware-a
git log -1 # commit d6072c00ce7f83870f4ee0b5a74126039cbd08d9 (HEAD -> develop-v2026.01, origin/develop-v2026.01, origin/HEAD)
make realclean
export CROSS_COMPILE=aarch64-linux-gnu-
make PLAT=rk3588
export BL31=/home/foxx/src/c/rk3588/trusted-firmware-a/build/rk3588/release/bl31/bl31.elf

cd ../u-boot
git checkout v2026.07
git log -1 # commit ece349ade2973e220f524ce59e59711cc919263f (HEAD, tag: v2026.07, origin/master)
make rock5b-rk3588_defconfig
make # CROSS_COMPILE was already set above to prefix aarch64-linux-gnu-

# copy the 2.1 MB .bin and flash, no padding, no nothing:
scp u-boot-rockchip-spi.bin foxx@rock:~
ssh foxx@rock
sudo dd if=u-boot-rockchip-spi.bin of=/dev/mtdblock0 status=progress
sync && sudo reboot

It just works, I have HDMI video, and 7.1 runs just fine.
On the Rock 5B:

cat /boot/extlinux/extlinux.conf

label Archlinux
    kernel /boot/vmlinuz-linux-aarch64-rk3588-collabora-git
    initrd /boot/initramfs-linux-aarch64-rk3588-collabora-git.img
    devicetreedir /boot/dtbs/linux-aarch64-rk3588-collabora-git
    append root=UUID=92603a1f-99bd-4012-b3d1-1ed34df8e943 earlycon=uart8250,mmio32,0xfeb50000 console=ttyS2,1500000n8 console=tty1 consoleblank=0 loglevel=7 panic=10 rootwait rw init=/sbin/init rootfstype=btrfs cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 irqchip.gicv3_pseudo_nmi=0 switolb=1 coherent_pool=2M

uname -a
Linux rock 7.1.0-1-aarch64-rk3588-collabora-git-g566f27ab3305 #1 SMP PREEMPT Sat Jul 11 18:46:05 CEST 2026 aarch64 GNU/Linux

(the UUID is specific to the SSD it’s booting from).

The old 6.1 kernel Joshua adapted from the BSP I was running isn’t working anymore, it can’t read the SDCARD anymore. If I flash back to a Radxa bootloader it will work.

9

the edk efi bios seems like a better alternative these days

There’s quite a lot of forks getting updated quite frequently. I was thinking of maybe trying it on SPI but the only reason it would benefit me is perhaps if I wanted to boot from usb or directly off a btrfs partition but for now i’m happy to load it from microsd with a vfat boot partition.