Ah I see. So uboot is roughly equivalent to PC UEFI BIOS, but configuration is more open to the user.

Whether or not a particular strain of u-boot supports booting from a certain medium or interacting with a certain thing in general is often more a function of whether said strain of u-boot is new enough (measured through mainline) and whether the particular PHY and controller has a driver in u-boot. For example, the vendor u-boot on my RK3588 dev board can even PXE boot, because u-boot has that functionality and the vendor u-boot has GMAC and Ethernet PHY drivers.

Rockchip SoCs builtin "maskrom" can read u-boot (or whatever other bootloader you use, Quartz64 with its RK3566 actually has a Tianocore EDKII port for full UEFI) from either SPI flash, eMMC or SD. The boot mediums after that are entirely up to said bootloader.

This is not somehow special to ARM, your x86_64 PC motherboard just comes with an SPI flash chip that has firmware like this flashed to it from the factory. Some SBC vendors are doing this as well now, e.g. ODROID is shipping u-boot+Petitboot (which seems like a bad idea, kexec is fragile from what I know) right on a flash chip included on the board.

The difference with RK3328 as found on the ROCK64 and RK3399 as found on the ROCKPro64 or Pinebook Pro is that you are not at the mercy of your vendor to provide you with firmware updates. Everything (TF-A, u-boot, and kernel) is included in the main repository for those particular projects and will be maintained going forward, and you can build it from source and hack on it at any time. It's not a u-boot fork from 2017 languishing in some dumping ground of a GitHub repository.