Based on this comment I understand that the EFI firmware environment does support some degree of TFTP.
However when testing this boot asset set from a TFTP root I see that it gets wedged after RPI_EFI.fd loads from the TFTP server. The Pi's firmware and its FS abstraction layer happily pull down all the assets to boot into the EFI environment and I'm able to use the menu etc. but the EFI environment doesn't re-DHCP to get the TFTP root and doesn't seem to honor the firmware's previously configured TFTP root so the /efi/boot/bootaa64.efi on the TFTP server doesn't get picked up.
This produces a BdsDxe: No bootable option or device was found. error and the system boots through to the EFI console which shows only the console and a local SD card as bootable options.
The same exact TFTP /boot tree if appropriately applied to an SD card works a treat and happily chainloads the /boot/efi/boot/bootaa64.efi.
Hey folks,
Based on this comment I understand that the EFI firmware environment does support some degree of TFTP.
However when testing this boot asset set from a TFTP root I see that it gets wedged after
RPI_EFI.fd
loads from the TFTP server. The Pi's firmware and its FS abstraction layer happily pull down all the assets to boot into the EFI environment and I'm able to use the menu etc. but the EFI environment doesn't re-DHCP to get the TFTP root and doesn't seem to honor the firmware's previously configured TFTP root so the/efi/boot/bootaa64.efi
on the TFTP server doesn't get picked up.This produces a
BdsDxe: No bootable option or device was found.
error and the system boots through to the EFI console which shows only the console and a local SD card as bootable options.The same exact TFTP
/boot
tree if appropriately applied to an SD card works a treat and happily chainloads the/boot/efi/boot/bootaa64.efi
.FS tree -
Should fetching
bootaa64.efi
from a TFTP root be working? Or am I off the reservation here.