Not just, in Window’s case, the Windows Boot Manager is known to be very aggressive in setting itself in the highest priority boot slot. So much so infact, that people who dual-boot are thankful when their laptop doesn’t follow the spec and allow the NVRAM modification from the OS.
But I digress, the UEFI spec specifies
ESP:/EFI/BOOT/BOOTX64.EFI as the default place to look for an efi binary if there is no entry in the NVRAM. I know
grub-install has an option for installing to the spec default location (using the
--removable option), and so does
refind-install (using the
--usedefault option), I use that location on my Arch install because I didn’t have to deal with adding an NVRAM entry. Regardless, there are various methods of checking and modifying the NVRAM, for example
Point is, that this is almost certainly the issue, and it’s also very easy to test. It’s -perhaps- a bit of a shame that the community wasn’t at all asked for troubleshooting help (especially considering that we were able to test this on the board itself). But then again it does seem on the surface to be a rather deep issue, so perhaps @jack and team didn’t think we’d be able to determine the source (again, a very fair assumption considering the issue appears complex), however, it would have been nice to have been given the chance…
Regardless, having the option of the eMMC be removable was nice as it provided added modularity and flexibility to the Rock Pi X.
Really? If that’s indeed the case, then why not (provided the eMMC was still removable) just bundle it with the device (i.e. a bonus choice of a free bundled eMMC)?