On 04/02/2021 08:56, Laszlo Ersek wrote:
I've attempted to wrap my brain around the initial report in thisMy best guess (based on having tried to do something similar before) is:
- Pi has no local storage.
- Pi uses its builtin network boot (running on the VC4 GPU, not the CPU) to download bootcode.bin, config.txt, and an appropriate start*.elf via TFTP.
- The downloaded config.txt includes "armstub=RPI_EFI.fd". The VC4 GPU (now executing start*.elf, as far as I am aware) downloads RPI_EFI.fd and boots the ARM CPU into this.
- At this point, we have the CPU running the RPi UEFI firmware.
There is no non-volatile storage available and so no way to use EFI variables to control the boot order. The boot device will be whatever is the *compile-time* default for RPI_EFI.fd.
The intention is that the UEFI firmware should then attempt a network boot. This could be done in at least three ways:
1. UEFI firmware defaults to attempting a network boot if no SD card is present. This would allow the UEFI firmware to load iPXE via TFTP.
2. iPXE as a driver (specifically bin-arm64-efi/rpi.efidrv) is embedded within the RPI_EFI.fd image, and UEFI firmware defaults to attempting a network boot if no SD card is present.
3. iPXE as an application (specifically bin-arm64-efi/rpi.efi) is embedded within the RPI_EFI.fd image, and UEFI firmware somehow defaults to running this application (e.g. via the PCD file GUID trick suggested by Ard).
All three of these options would result in the RPi running UEFI iPXE as requested.
Werner: please correct me if I have misunderstood what you are trying to do.