It is perceived that boot sequence steps of FreeBSD (x64) in UEFI environment are as below. It is pedigreed process written on manpages.
currdev
or loaddev
.
The UEFI firmware gets BOOTX64.EFI up in EFI system partition. Next it runs the boot1.efi, then the loader.efi is lunched, and finally the kernel boots up. Actually the process is supposed to move ahead as BOOTX64.EFI → laoder.efi → kernel because boot1.efi is copied as BOOTX64.EFI
The reason why I say ambiguously is because, as you know, it is different between the implementation and manpages' description. It looks like that the loader.efi has been used as BOOTX64.EFI in FreeBSD 12.0-RELEASE. (Corresponding commit.) It seems that these implementations are now work-in-progress, so there is a moderate improved patch to generate an ESP.
You can find the same hash values between BOOTX64.EFI and loader.efi when mounting the ESP generated by FreeBSD 12.2-RELEASE installer.
So, the final stage bootloader goes straight skipping over the 1st stage in fact.
This way is no problem in most environments, but it probably can't boot the system placed on another storage because the loader.efi seems to only look for system partitions from the storage which it is loaded from. That's a fine how-do-you-do!
Workaround is to replace the BOOTX64.EFI with boot1.efi or to set currdev
and load the kernel and zfs.ko
manually in bootloader prompt remaining the loader.efi as EFI bootloader.
The former is clearly easier than the latter.
According to source codes of the loader.efi, it looks like the loader can boot the system by an undocumented way. I will try it after.