Radxa Cubie A5E — SD card ignored in favor of NVMe once SPI boot firmware is flashed

I’m running Armbian off NVMe, and flashed the U-Boot SPI firmware (u-boot-sunxi-with-spl.bin → /dev/mtdblock0) so I no longer need an SD card inserted just to get it booting. That part works great. But now I’d like to be able to pop in an SD card occasionally to try other distros/images without disturbing my NVMe install — and it seems that’s not currently possible: with an SD card inserted, the board still boots straight from NVMe and ignores the card entirely.

Dug into it a bit over serial console:

  • The default boot_targets is fel nvme0 mmc_auto usb0 pxe dhcp — NVMe is checked before the SD/eMMC. Radxa hit the same issue on the RK3588 boards and fixed it upstream (radxa/u-boot#25, “give SD higher boot priority than NVME”). Would be great to see the same fix applied here.

  • I tried working around it manually (setenv boot_targets 'mmc0 mmc1 nvme0 usb0 pxe dhcp'), which does work for that boot — SD is picked up correctly when present. But saveenv fails with “Unable to use mmc 0:1… Failed (1)”, so the change doesn’t survive a reboot. Looks like this build uses CONFIG_ENV_IS_IN_FAT targeting mmc 0:1, but the Armbian SD image ships a single ext4 partition there (confirmed with fstype mmc 0:1 → ext4), so the environment can never actually be saved.

Is this a known limitation, or is there a recommended way to get persistent SD-over-NVMe priority on this board right now?

All sorts of info missing. What U-Boot version? from where? What OS release or image etc etc.

Sorry, should have included that up front. Details:

Board: Radxa Cubie A5E
OS image:
BOARD=radxa-cubie-a5e
BOARD_NAME=“Cubie A5E”
BOARDFAMILY=sun55iw3
BUILD_REPOSITORY_URL=GitHub - armbian/build: The official build framework for the Armbian Linux distribution. This repository contains the complete toolchain and scripts required to compile custom OS images from source, including kernel configuration, U-Boot handling, and board-specific tweaks for various ARM and ARM64 single-board computers. · GitHub
BUILD_REPOSITORY_COMMIT=cc103cb0f
LINUXFAMILY=sunxi64
ARCH=arm64
BOOT_SOC=
IMAGE_TYPE=user-built
BOARD_TYPE=csc
INITRD_ARCH=arm64
KERNEL_IMAGE_TYPE=Image
KERNEL_TARGET=current,edge
KERNEL_TEST_TARGET=current,edge
FORCE_BOOTSCRIPT_UPDATE=
FORCE_UBOOT_UPDATE=
OVERLAY_DIR=“/boot/dtb/allwinner/overlay”
VENDOR=“Armbian-unofficial”
VENDORCOLOR=“247;16;0”
VENDORDOCS=“https://docs.armbian.com/”
VENDORURL=“" at DuckDuckGo
VENDORSUPPORT=“https://community.armbian.com/”
VENDORBUGS=“https://armbian.atlassian.net/”
BOOTSCRIPT_FORCE_UPDATE=“no”
BOOTSCRIPT_DST=“boot.cmd”
VERSION=26.08.0-trunk
REVISION=26.08.0-trunk
BRANCH=current

U-Boot package/version:
ii linux-u-boot-radxa-cubie-a5e-current 26.08.0-trunk arm64 Das U-Boot for radxa-cubie-a5e
ii u-boot-tools 2025.01-3 arm64 companion tools for Das U-Boot bootloader
Kernel:
Linux a5e 6.18.36-current-sunxi64 #1 SMP PREEMPT Fri Jun 19 19:44:16 CST 2026 aarch64 GNU/Linux

What I did: Flashed the board’s U-Boot to SPI NOR with:

sudo dd if=/usr/lib/linux-u-boot-current-radxa-cubie-a5e/u-boot-sunxi-with-spl.bin of=/dev/mtdblock0

This fixed booting without an SD card present, but now an inserted SD card is ignored in favor of NVMe.

Diagnosis so far (via serial console, 115200 8N1 on GPIO pins 6/8/10):

Default environment:

boot_targets=fel nvme0 mmc_auto usb0 pxe dhcp

Setting boot_targets=mmc0 mmc1 nvme0 usb0 pxe dhcp and running boot manually works correctly — SD is picked up over NVMe when present:

Scanning mmc 0:1…
Found U-Boot script /boot/boot.scr

However this doesn’t persist. saveenv fails:

Saving Environment to FAT… Unable to use mmc 0:1…
Failed (1)

Checked the SD card’s partition table and filesystem:

Part Start Sector Num Sectors UUID Type
1 8192 61693952 f3e87223-01 83

=> fstype mmc 0:1
ext4

So this build is configured with CONFIG_ENV_IS_IN_FAT targeting mmc 0:1, but Armbian’s actual SD image uses a single ext4 partition there — meaning the environment can never be saved, regardless of what’s inserted.

Two things I think need fixing upstream: default boot_targets should put SD before NVMe (same as the RK3588 fix, radxa/u-boot#25), and the environment storage location should point somewhere that actually matches the partition layout Armbian ships (or somewhere persistent on-board, like SPI flash, rather than the removable SD card).

If a board has SPI-flash for storing bootloader, the preferred method IMO would be to store various settings in that same SPI-flash. That is how it is on PC’s and also with RK3588 boards with SPI-flash chip. Works great on my ROCK5B, stores even URI for different OSses on the same NVME.

If you want to change, build U-Boot yourself and/or do pull request on Armbian for this board or even generic build infra.

If you explicitly want to use other bootloader, you need additional change I think. I have a ROCK3A, that has a jumper to disable SPI-flash, so then sure it takes the bootloader from SD-card. But a SW based ‘chainloading’ is different board, not sure how that is implemented. I know from long time ago with lilo or grubv1 on BIOS PC’s, but read info about that in U-Boot configs or docs or so.