What a pity.
No idea why vendor U-boot can be so feature lack…
Rock5B SPI flash U-boot doesn't support UEFI runtime
There is very little arm system ever supports UEFI though, this is a pity but it is what we are having nowadays, and that’s the exact reason why the kernel need that much device tree files to support a wide range of systems.
The problem is, most default upstream Uboot configs have UEFI enabled.
The vendor debug U-boot (which can not even pass compile using modern toolchains) for SPI image should only need to enable EFI configs, unless the RK guys did extra hacks.
The UEFI is very common for sever grade ARM machines, and with UEFI runtime from U-boot, it can easily unify the boot sequence (traditional boards: U-boot -> UEFI bootloader -> kernel, while ARM servers: UEFI firmware -> UEFI bootloader -> kernel).
From the vendor kernel/U-boot tree, what I see is just a bunch of hacks to make things work (and sometimes even not work), not really understanding the standard.
They did this all the times. They hacked the kernel, they hacked the U-Boot, and they even hacked the user-land packages(like X11) to make the chip work, even if their hack would break certain software.
This IS the problem. Only arm servers need a unified boot sequence because users need to control the OS they want to use, but most of the client arm devices are highly vendor-customized devices that is only meant to run vendor-selected software which eliminates the reason to implement UEFI and makes vendors think this function is OK to be broken.