Date
1 - 1 of 1
Compile EDK2 to set boot order to PXE EFI_LOAD_OPTION
Andrew Fish
Werner,
From a UEFI Specification point of view the boot policy is controlled by NVRAM variables. The variables in EFI have a GUID/UUID and a Unicode string name. The variables owned by the UEFI Spec use the gEfiGlobalVariableGuid [1] namespace. The BootOrder variable is an array of UINT16 values that map into Boot##### variables. The ##### is the hex values of the BootOrder Entry. The Boot#### use an EFI_LOAD_OPTION [2] that contains an EFI_DEVICE_PATH_PROTOCOL. The EFI_DEVICE_PATH_PROTOCOL will point to the boot device and then a path for the file to boot.
The common way this works is an OS is installed on a system and the OS installer writes the nvram variable to point to the OS loader on the EFI System Partition. The Firmware BDS will carry some defaults (platform defined) and will typically default the variables based on some platform policy. The UI you launch from the BDS to boot likely will write the BootOrder (or reorder it) and add the Boot#### variables.
Also the old style PXE boot was more about telling the network what kind of device you are and the UUID and have the server send you back something useful. In this case the EFI_DEVICE_PATH_PROTOCOL is just going to point to the MAC address of the NIC. I think booting from files is more of an iPXE iSCSI kind of thing.
If you `git grep BootOrder` it looks like the ArmVirtPkg and OvmfPkg are doing work to set boot defaults that might be interesting for your work. The BootMaintenanceManagerUiLib is the UI to set the variables/boot policy.
Sorry this is just generic background and not the specific answer to your problem but the products I work on use a custom BDS so I don’t know the open source answer off the top of my mind. Maybe some one else will have a more specific answer.
Feel free to ask questions if you get stuck on specific bits of the solution like how to create the EFI_DEVICE_PATH_PROTOCOL.
[1] #define EFI_GLOBAL_VARIABLE \
{0x8BE4DF61,0x93CA,0x11d2,\
{0xAA,0x0D,0x00,0xE0,0x98,0x03,0x2B,0x8C}}
[2] This is a variable sized structure that you may need to lookup in the UEFI Spec see 3.1.3 : https://uefi.org/sites/default/files/resources/UEFI%20Spec%202.8B%20May%202020.pdf
Good Luck,
Andrew Fish
toggle quoted message
Show quoted text
From a UEFI Specification point of view the boot policy is controlled by NVRAM variables. The variables in EFI have a GUID/UUID and a Unicode string name. The variables owned by the UEFI Spec use the gEfiGlobalVariableGuid [1] namespace. The BootOrder variable is an array of UINT16 values that map into Boot##### variables. The ##### is the hex values of the BootOrder Entry. The Boot#### use an EFI_LOAD_OPTION [2] that contains an EFI_DEVICE_PATH_PROTOCOL. The EFI_DEVICE_PATH_PROTOCOL will point to the boot device and then a path for the file to boot.
The common way this works is an OS is installed on a system and the OS installer writes the nvram variable to point to the OS loader on the EFI System Partition. The Firmware BDS will carry some defaults (platform defined) and will typically default the variables based on some platform policy. The UI you launch from the BDS to boot likely will write the BootOrder (or reorder it) and add the Boot#### variables.
Also the old style PXE boot was more about telling the network what kind of device you are and the UUID and have the server send you back something useful. In this case the EFI_DEVICE_PATH_PROTOCOL is just going to point to the MAC address of the NIC. I think booting from files is more of an iPXE iSCSI kind of thing.
If you `git grep BootOrder` it looks like the ArmVirtPkg and OvmfPkg are doing work to set boot defaults that might be interesting for your work. The BootMaintenanceManagerUiLib is the UI to set the variables/boot policy.
Sorry this is just generic background and not the specific answer to your problem but the products I work on use a custom BDS so I don’t know the open source answer off the top of my mind. Maybe some one else will have a more specific answer.
Feel free to ask questions if you get stuck on specific bits of the solution like how to create the EFI_DEVICE_PATH_PROTOCOL.
[1] #define EFI_GLOBAL_VARIABLE \
{0x8BE4DF61,0x93CA,0x11d2,\
{0xAA,0x0D,0x00,0xE0,0x98,0x03,0x2B,0x8C}}
[2] This is a variable sized structure that you may need to lookup in the UEFI Spec see 3.1.3 : https://uefi.org/sites/default/files/resources/UEFI%20Spec%202.8B%20May%202020.pdf
Good Luck,
Andrew Fish
On Jan 29, 2021, at 2:45 PM, wernerbuck@... wrote:
Hi,
I am network booting the raspberry pi firmware. Unfortunately as its loaded from TFTP it does not retain settings nor do I believe I can give it settings.
I am already compiling my own version of RPi4 uefi with edk-platforms/../Rpi4/.dsc edited for some better defaults like setting higher memory.
However, I can't find an option to force a particular boot option as a default. Right now it tries to boot an .efi locally but that efi is not able to be found because we are booting from TFTP.
Instead I would like it to boot to PXE again where I can boot iPXE and control the boot process further. The end goal here is that I can boot UEFI -> iPXE without an SD card.
Could you help me find out what option/variable I can set in the platform dsc? I think the option should be in MdePkg.dec but I can't find any "DefaultBootOption" or override variable.
Kind regards,
Werner Buck