Various points here:
-
You have the wrong file name; it should be BOOTRISCV64.EFI, not BOOTRISC64.EFI
-
There is no reason to put an ESP on the SD card. Using the SD card more than you need to will just slow things down (NVMe is not blazing fast but it sure does beat an SD card, plus NVMe is one of the first devices for U-Boot to probe, and the SD card the last, so you save a few seconds off the U-Boot boot time by not having to let it go all the way through the list), and it’s also just a pain to juggle multiple disks that’s totally unnecessary, just have the ESP on your NVMe drive and be done with it.
-
boot1.efi is deprecated as it serves little purpose other than to complicate the boot process.
-
… but even if you were using boot1.efi, it expects to load loader.efi from the root filesystem, not the ESP.
-
Having the ESP and root filesystem on different disks can actually cause weird issues. U-Boot probes block devices lazily, so depending on the boot order you can end up booting your ESP and not having the block device with the root filesystem partition on it available. I have run into this when copying development kernels back and forth on a USB stick, as my ESP (and root filesystem) live on the NVMe drive, so U-Boot doesn’t even bother running
usb start, meaning the FreeBSD boot loader cannot see any USB drives and thus I cannot manually load a kernel from it (the workaround for this is to drop to a U-Boot prompt and manually runpci enumandusb startbefore letting it boot). Moreover, loader’s heuristics are to prefer a root freebsd-ufs or freebsd-zfs partition on the same disk as the ESP, so if you grow a more complex setup your system could suddenly start trying to load a kernel from and mount as root the wrong partition.
Thus, the official way to do things is as zBeeble said in the original post: put the ESP on the same disk as your root partition, and use loader.efi as EFI/BOOT/BOOTRISCV64.EFI (no other files needed) in the ESP.