My understanding is that the UEFI image itself is PXE booted. But indeed, more clarity is always good

Adding the UefiPayloadPkg folks to the CC list. Thanks Laszlo

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

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

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

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

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

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

adding Pete and Ard

Hi, 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

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

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

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

Could be that the portion of the address space that PciIo->Map() can deal with gets fragmented in the part of code that you have now eliminated, by moving the call earlier. Laszlo

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.

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

Thanks a lot Laszlo. Regards, Rajesh

Small Update: I could fix the issue by moving the PCI->Map little early in the initialization but couldn't root cause it yet.