Any normal firmware lets you set up the boot order. Suporting NVMHCI in the ROM code would be an overkill, none of mask ROM codes provide such. it's definitely a job for the FW (don't confuse these, what Rockchip provides is not a FW, it's an "engine" for rolling out the FW). And of course, no matter where - UEFI, ARC or OF, support for NVMHCI (or USB mass storage or anything else) should be created to exist.
OF is an obsoleted standard, it doesn't evolve. UEFI does. And it is very extensible, it doesn't require to be GUI (but every self-respected vendor will provide it, since it's a useful feature for users), but also it provides its "shell" (command interpreter), and therefore - scripting capabilities and even has a byte code instruction set for architecture independent drivers. It integrates well with modern configuration standards like ACPI and given its implementation is not bloated AF, it will fit into even a couple of megs. I am not aware of someone working on OF for ARM. Linaro only pulled device trees out of it and brought them into linux, so did uboot following the latter unconditionally, but it's not OF. Any FW could be installed in any place where ROM code can locate it:
And then, the FW can boot (OS loader->OS) from whatever source it can reach - even from the network (iSCSI, PXE, TFTP). This is how it is on x86 and nothing prevents it to happen on ARM. the current inability to boot the OS from NVMe drives or USB ones is lacking features in uboot.
OF is an obsoleted standard, it doesn't evolve. UEFI does. And it is very extensible, it doesn't require to be GUI (but every self-respected vendor will provide it, since it's a useful feature for users), but also it provides its "shell" (command interpreter), and therefore - scripting capabilities and even has a byte code instruction set for architecture independent drivers. It integrates well with modern configuration standards like ACPI and given its implementation is not bloated AF, it will fit into even a couple of megs. I am not aware of someone working on OF for ARM. Linaro only pulled device trees out of it and brought them into linux, so did uboot following the latter unconditionally, but it's not OF. Any FW could be installed in any place where ROM code can locate it:
- - SPI
- - eMMC boot partitions (areas) - if ROM code can load from there
- - eMMC general purpose area
- - SD
- - all kinds of raw NAND devices
And then, the FW can boot (OS loader->OS) from whatever source it can reach - even from the network (iSCSI, PXE, TFTP). This is how it is on x86 and nothing prevents it to happen on ARM. the current inability to boot the OS from NVMe drives or USB ones is lacking features in uboot.
ANT - my hobby OS for x86 and ARM.