Following is the corrected error log by removing unwanted/misleading spaces.

*Error Log*
-----------------
Thu Feb 4 08:34:24 2021: | ERROR: Execution of '/tmp/yocto_builds/20519231_s9xxxx-bcm9xxxxi/poky/build/tmp/work/bcm9xxxxi-poky-linux/brcm-edk2/gitAUTOINC+f30940e557_56f32f8dd9_3574ef9b13_31754d4ffc_31754d4ffc_e2e09d9fba_61687168fe-r0/temp/run.do_deploy.19127' failed with exit code 1:
Thu Feb 4 08:34:24 2021: | install: cannot stat '/tmp/yocto_builds/20519231_s9xxxx-bcm9xxxxi/poky/build/tmp/work/bcm9xxxxi-poky-linux/brcm-edk2/gitAUTOINC+f30940e557_56f32f8dd9_3574ef9b13_31754d4ffc_31754d4ffc_e2e09d9fba_61687168fe-r0/git/Build/StingrayPkg/RELEASE_GCC5/AARCH64/Sbsa.efi': No such file or directory
Thu Feb 4 08:34:24 2021: | WARNING: exit code 1 from a shell command.
Thu Feb 4 08:34:24 2021: |-
Thu Feb 4 08:34:24 2021: NOTE: recipe brcm-edk2-gitAUTOINC+f30940e557_56f32f8dd9_3574ef9b13_31754d4ffc_31754d4ffc_e2e09d9fba_61687168fe-r0: task do_deploy: Failed
Thu Feb 4 08:34:24 2021: ERROR: Task (mc:stingray:/tmp/yocto_builds/20519231_s9xxxx-bcm9xxxxi/poky/build/../meta-brcm/common/recipes-bsp/edk2/brcm-edk2.bb:do_deploy) failed with exit code '1'

Regards,
Rajesh

I'm seeing the same error even after picking the commit id: 020ec963048340c9eaf9799471167d769239bcfc by updating edk2 repository.
i.e. I'm seeing Yocto build failures only when path length is long due to platform name being slightly longer by a some 10-15 characters more.
Same repository build is passing with Yocto for platform whose name length is smaller by some 0-15 characters

*Error Log*
-----------------
Thu Feb 4 08:34:24 2021: | ERROR: Execution of '/tmp/yocto_builds/20519231_s9xxxx-bcm9xxxxi/poky/build/tmp/work/bcm9xxxxi-poky-linux/brcm-edk2/gitAUTOINC+ <--f30940e557_56f32f8dd9_3574ef9b13_31754d4ffc_31754d4ffc_e2e09d9fba_61687168fe-r0/temp/run.do_deploy.19127' failed with exit code 1:
Thu Feb 4 08:34:24 2021: | install: cannot stat '/tmp/yocto_builds/20519231_s9xxxx-bcm9xxxxi/poky/build/tmp/work/bcm9xxxxi-poky-linux/brcm-edk2/gitAUTOINC+ <--f30940e557_56f32f8dd9_3574ef9b13_31754d4ffc_31754d4ffc_e2e09d9fba_61687168fe-r0/git/Build/StingrayPkg/RELEASE_GCC5/AARCH64/Sbsa.efi': No such file or directory
Thu Feb 4 08:34:24 2021: | WARNING: exit code 1 from a shell command.
Thu Feb 4 08:34:24 2021: |-
Thu Feb 4 08:34:24 2021: NOTE: recipe brcm-edk2-gitAUTOINC+f30940e557_56f32f8dd9_3574ef9b13_31754d4ffc_31754d4ffc_e2e09d9fba_61687168fe-r0: task do_deploy: Failed
Thu Feb 4 08:34:24 2021: ERROR: Task (mc:stingray:/tmp/yocto_builds/20519231_s9xxxx-bcm9xxxxi/poky/build/../meta-brcm/common/recipes-bsp/edk2/brcm-edk2.bb:do_deploy) failed with exit code '1'

Regards,
Rajesh

UEFI Payload from EDK2 2017 seems to be pretty old.

Below are some of my recommendations:
- Enable serial debug console in UEFI payload so that you don't depend on USB KB for input. Once you booted to Shell using serial console, further info can be collected to root cause USB issue.
- If you saw the hang at "[Bds]BdsWait(3)..Zzzz...", it could be timer related issue. I saw some instances where the ACPI timer base was reported incorrectly to UEFI payload and ACPI timer base was wrong. That would cause the dead loop in delay function.
- Try out the latest UefiPayload in EDK2 to see if it works for you.

Regards
Maurice

On 02/04/21 13:35, Michael Brown wrote:

On 04/02/2021 08:56, Laszlo Ersek wrote:

I've attempted to wrap my brain around the initial report in this
thread, and honestly I'm lost. My standard answer would be "BDS behavior
is platform policy, so look into whatever PlatformBootManagerLib
instance is used by the RPi firmware" (and I understand that Ard's
response is somehow consistent with this). But honestly I can't figure
out whether the problem is related to the part of the RPi firmware that
runs *before* TianoCore. What exactly is PXE-booted before what else?...
I think we'd need a much more detailed issue report here.

My 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

O_o

Thank you for the explanation. Not that I can help Werner in any way,
but now I understand the issue at least.

Thanks,
Laszlo

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.

Thanks,

Michael

On 04/02/2021 08:56, Laszlo Ersek wrote:

I've attempted to wrap my brain around the initial report in this
thread, and honestly I'm lost. My standard answer would be "BDS behavior
is platform policy, so look into whatever PlatformBootManagerLib
instance is used by the RPi firmware" (and I understand that Ard's
response is somehow consistent with this). But honestly I can't figure
out whether the problem is related to the part of the RPi firmware that
runs *before* TianoCore. What exactly is PXE-booted before what else?...
I think we'd need a much more detailed issue report here.

My 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.

Thanks,

Michael

On Thu, 4 Feb 2021 at 09:56, Laszlo Ersek <lersek@redhat.com> wrote:

On 02/04/21 01:22, Michael Brown wrote:

On 02/02/2021 17:06, Ard Biesheuvel wrote:

On Tue, 2 Feb 2021 at 17:41, Laszlo Ersek <lersek@redhat.com> wrote:

On 01/29/21 23:45, wernerbuck@gmail.com wrote:

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.

I think you might be able to trick the BDS into loading iPXE as the
shell if you set the correct file GUID for it in the right PCD.

I'm interested to know the outcome of this experiment.

Also: the motivation behind creating https://github.com/ipxe/pipxe was
because the Pi's VC4 PXE boot code turned out to be incredibly
unreliable (with a ~10% boot failure rate) - this is why I personally
gave up on getting the Pi to network boot without an SD card as a
bootstrap.

Thanks for commenting.

I've attempted to wrap my brain around the initial report in this
thread, and honestly I'm lost. My standard answer would be "BDS behavior
is platform policy, so look into whatever PlatformBootManagerLib
instance is used by the RPi firmware" (and I understand that Ard's
response is somehow consistent with this). But honestly I can't figure
out whether the problem is related to the part of the RPi firmware that
runs *before* TianoCore. What exactly is PXE-booted before what else?...
I think we'd need a much more detailed issue report here.

My understanding is that the UEFI image itself is PXE booted.

But indeed, more clarity is always good

On 02/02/21 13:16, sent888@gmail.com wrote:

Hi,

I have generated a payload from edk2 2017. When i booting with payload i got struck after the below message. The keyboard is not detecting so i can't press any key. Mouse got powered up. Even i exchanged the usb ports but still keyboard not detecting. I am using coreboot and edk2 payload. I am using Coffeelake processor. If i use the uefi payload binary from Intel. Everything is working and able to select device in the boot manager and load OS.

LastBlock : 4FFFFF

F2 or Down to enter Boot Manager Menu.
ENTER to boot directly.

[Bds]OsIndication: 0000000000000000
[Bds]=============Begin Load Options Dumping ...=============
Driver Options:
SysPrep Options:
Boot Options:
Boot0000: UiApp 0x0109
Boot0001: UEFI SM659GXC CDZ A0519022617060000001 0x0001
Boot0002: UEFI Shell 0x0001
PlatformRecovery Options:
PlatformRecovery0000: Default PlatformRecovery 0x0001
[Bds]=============End Load Options Dumping=============
[Bds]BdsWait ...Zzzzzzzzzzzz...
[Bds]BdsWait(3)..Zzzz...

Adding the UefiPayloadPkg folks to the CC list.

Thanks
Laszlo

On 02/04/21 01:22, Michael Brown wrote:

On 02/02/2021 17:06, Ard Biesheuvel wrote:

On Tue, 2 Feb 2021 at 17:41, Laszlo Ersek <lersek@redhat.com> wrote:

On 01/29/21 23:45, wernerbuck@gmail.com wrote:

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.

I think you might be able to trick the BDS into loading iPXE as the
shell if you set the correct file GUID for it in the right PCD.

I'm interested to know the outcome of this experiment.

Also: the motivation behind creating https://github.com/ipxe/pipxe was
because the Pi's VC4 PXE boot code turned out to be incredibly
unreliable (with a ~10% boot failure rate) - this is why I personally
gave up on getting the Pi to network boot without an SD card as a
bootstrap.

Thanks for commenting.

I've attempted to wrap my brain around the initial report in this
thread, and honestly I'm lost. My standard answer would be "BDS behavior
is platform policy, so look into whatever PlatformBootManagerLib
instance is used by the RPi firmware" (and I understand that Ard's
response is somehow consistent with this). But honestly I can't figure
out whether the problem is related to the part of the RPi firmware that
runs *before* TianoCore. What exactly is PXE-booted before what else?...
I think we'd need a much more detailed issue report here.

Laszlo

On 02/02/2021 17:06, Ard Biesheuvel wrote:

On Tue, 2 Feb 2021 at 17:41, Laszlo Ersek <lersek@redhat.com> wrote:

On 01/29/21 23:45, wernerbuck@gmail.com wrote:

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.

I think you might be able to trick the BDS into loading iPXE as the
shell if you set the correct file GUID for it in the right PCD.

I'm interested to know the outcome of this experiment.

Also: the motivation behind creating https://github.com/ipxe/pipxe was because the Pi's VC4 PXE boot code turned out to be incredibly unreliable (with a ~10% boot failure rate) - this is why I personally gave up on getting the Pi to network boot without an SD card as a bootstrap.

Michael

On Tue, 2 Feb 2021 at 17:41, Laszlo Ersek <lersek@redhat.com> wrote:

adding Pete and Ard

On 01/29/21 23:45, wernerbuck@gmail.com 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.

I think you might be able to trick the BDS into loading iPXE as the
shell if you set the correct file GUID for it in the right PCD.

Hi,

I have generated a payload from edk2 2017. When i booting with payload i got struck after the below message. The keyboard is not detecting so i can't press any key. Mouse got powered up. Even i exchanged the usb ports but still keyboard not detecting. I am using coreboot and edk2 payload. I am using Coffeelake processor. If i use the uefi payload binary from Intel. Everything is working and able to select device in the boot manager and load OS.

LastBlock : 4FFFFF

F2 or Down to enter Boot Manager Menu.
ENTER to boot directly.

[Bds]OsIndication: 0000000000000000
[Bds]=============Begin Load Options Dumping ...=============
Driver Options:
SysPrep Options:
Boot Options:
Boot0000: UiApp 0x0109
Boot0001: UEFI SM659GXC CDZ A0519022617060000001 0x0001
Boot0002: UEFI Shell 0x0001
PlatformRecovery Options:
PlatformRecovery0000: Default PlatformRecovery 0x0001
[Bds]=============End Load Options Dumping=============
[Bds]BdsWait ...Zzzzzzzzzzzz...
[Bds]BdsWait(3)..Zzzz...

Regards,
gsen

Hi all,

ESRT now is using AllocatePool() to allocate memory and published to ConfigurationTable. ConfigurationTable should be valid after calling ExitBootServices().
So why not using AllocateRuntimePool to allocate memory for ESRT, is it a mistake?

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

I think it’s actually going to be in MdeModulePkg under BDS (maybe MdeModulePkg/Universal/BdsDxe?). There’s also the BootManagerPolicyDxe and a few other libs that get used, but I’d have to dig into the code to name the exact place.

- Bret

From: wernerbuck via groups.io<mailto:wernerbuck=gmail.com@groups.io>
Sent: Tuesday, February 2, 2021 3:57 AM
To: discuss@edk2.groups.io<mailto:discuss@edk2.groups.io>
Subject: [EXTERNAL] [edk2-discuss] Compile EDK2 to set boot order to PXE

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

adding Pete and Ard

Hi,

On 02/02/21 07:16, gauravpandya321@gmail.com wrote:

Hello Everyone,
Where is the best place to get information about each package in EDK2 repo for a beginner. I want to understand what functionality each package provides, documentation about each package.

the edk2 wiki seems to have an intro text for each package; for example:

https://github.com/tianocore/tianocore.github.io/wiki/MdePkg

Thanks
Laszlo

Hello Everyone,
Where is the best place to get information about each package in EDK2 repo for a beginner. I want to understand what functionality each package provides, documentation about each package.

Thanks.

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

On 02/01/21 14:38, UdayS via groups.io wrote:

Hi,
I have two pci drivers (1) full driver with all functionality, (2) Driver which subset of (1).
Both drivers are working fine. Load/Unload at run time smoothly works when each of them are done independently.

Issue:
1. Load driver (1) and unload (1) now if I load driver (2), shell hangs.

I have verified loading/unloading of driver, multiple iterations, i.e. it cleanups all protocols installed.
But if I follow the issue procedure above, it hangs. I don't see error during initialization of second driver.

Need advise to debug this issue further.

Thank in advance.

Unloading driver (1) could leave the hardware in such a state that
driver (1) can deal with, when loaded (again), but driver (2) cannot,
when loaded (for the first time after (1)).

Laszlo

On 02/02/21 03:14, wenyi,xie via groups.io wrote:

Hi all,
May I ask a question.
In what conditions will we update submodules. Will we update the sbumodule when it only fixes a vulnerability, or any other conditions should be meet before updating.

I don't think we've formalized this. I would think: we update a
submodule when there's a reason to. Important bugfix (security or
otherwise), or a new feature that we'd like to consume in an edk2 module.

Just my impressions.

Thanks
Laszlo