Date   

Re: Potentially missing CloseProtocol() call

Laszlo Ersek
 

On 02/08/21 16:28, Michael Brown wrote:
On 08/02/2021 14:22, Laszlo Ersek wrote:
gBS->OpenProtocol() calls that pass the EFI_OPEN_PROTOCOL_GET_PROTOCOL
argument for the "Attributes" parameter *need not* be mirrored with
gBS->CloseProtocol() calls.

Please refer to the UEFI spec on the OpenProtocol() boot service,
Attributes=EFI_OPEN_PROTOCOL_GET_PROTOCOL:

     [...] The caller is also not required to close the protocol
     interface with EFI_BOOT_SERVICES.CloseProtocol().

So you *can* call CloseProtocol(), but you don't have to.
This reminds me of a very longstanding question I've had around
OpenProtocol(): is there any defined way for something that is an
ordinary consumer (rather than a driver or child controller) to obtain a
long-lived pointer to a protocol interface?

For example:
ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/MainTextEditor.c seems
to open EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL using just HandleProtocol()
and then continues to use the pointer for the lifetime of the
application.  But, as far as I can tell, there's nothing that guarantees
that this pointer remains valid?
The CloseProtocol() specification has parts as follows (relevant passage
is the last one below):

The caller is responsible for ensuring that there are no references
to a protocol interface that has been removed. In some cases,
outstanding reference information is not available in the protocol,
so the protocol, once added, cannot be removed. Examples include
Console I/O, Block I/O, Disk I/O, and (in general) handles to device
protocols.

[...]

EFI 1.10 Extension

The extension to this service directly addresses the limitations
described in the section above. There may be some drivers that are
currently consuming the protocol interface that needs to be
uninstalled, so it may be dangerous to just blindly remove a
protocol interface from the system. Since the usage of protocol
interfaces is now being tracked for components that use the
EFI_BOOT_SERVICES.OpenProtocol() and
EFI_BOOT_SERVICES.CloseProtocol() boot services, a safe version of
this function can be implemented.

[...]

Lastly, all of the agents that have the protocol interface open with
an attribute of EFI_OPEN_PROTOCOL_BY_HANDLE_PROTOCOL,
EFI_OPEN_PROTOCOL_GET_PROTOCOL, or EFI_OPEN_PROTOCOL_TEST_PROTOCOL
are closed. If there are any agents remaining that still have the
protocol interface open, the protocol interface is not removed from
the handle and EFI_ACCESS_DENIED is returned. In addition, all of
the drivers that were disconnected with the boot service
DisconnectController() earlier, are reconnected with the boot
service EFI_BOOT_SERVICES.ConnectController(). If there are no
agents remaining that are consuming the protocol interface, then the
protocol interface is removed from the handle as described above.

My comments:

(1) I don't really understand what the last quoted passage means by
"closing an agent".

(2) I've never tested this, nor attempted to verify it from the edk2
source, myself. It does suggest however that GET_PROTOCOL opens are
tracked too, and thus, *not* closing a GET_PROTOCOL open is technically
still a leak.

Thanks
Laszlo


Re: Potentially missing CloseProtocol() call

Satoshi Tanda
 

Hi Laszlo,

I was almost exclusively checking edk2 headers but should have checked with
the specs. Thank you for clarifying it for me.

Best,
Satoshi

On Mon, Feb 8, 2021 at 7:28 AM Michael Brown <mcb30@ipxe.org> wrote:

On 08/02/2021 14:22, Laszlo Ersek wrote:
gBS->OpenProtocol() calls that pass the EFI_OPEN_PROTOCOL_GET_PROTOCOL
argument for the "Attributes" parameter *need not* be mirrored with
gBS->CloseProtocol() calls.

Please refer to the UEFI spec on the OpenProtocol() boot service,
Attributes=EFI_OPEN_PROTOCOL_GET_PROTOCOL:

[...] The caller is also not required to close the protocol
interface with EFI_BOOT_SERVICES.CloseProtocol().

So you *can* call CloseProtocol(), but you don't have to.
This reminds me of a very longstanding question I've had around
OpenProtocol(): is there any defined way for something that is an
ordinary consumer (rather than a driver or child controller) to obtain a
long-lived pointer to a protocol interface?

For example:
ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/MainTextEditor.c seems
to open EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL using just HandleProtocol()
and then continues to use the pointer for the lifetime of the
application. But, as far as I can tell, there's nothing that guarantees
that this pointer remains valid?

Michael


Re: Potentially missing CloseProtocol() call

Michael Brown
 

On 08/02/2021 14:22, Laszlo Ersek wrote:
gBS->OpenProtocol() calls that pass the EFI_OPEN_PROTOCOL_GET_PROTOCOL
argument for the "Attributes" parameter *need not* be mirrored with
gBS->CloseProtocol() calls.
Please refer to the UEFI spec on the OpenProtocol() boot service,
Attributes=EFI_OPEN_PROTOCOL_GET_PROTOCOL:
[...] The caller is also not required to close the protocol
interface with EFI_BOOT_SERVICES.CloseProtocol().
So you *can* call CloseProtocol(), but you don't have to.
This reminds me of a very longstanding question I've had around OpenProtocol(): is there any defined way for something that is an ordinary consumer (rather than a driver or child controller) to obtain a long-lived pointer to a protocol interface?

For example: ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/MainTextEditor.c seems to open EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL using just HandleProtocol() and then continues to use the pointer for the lifetime of the application. But, as far as I can tell, there's nothing that guarantees that this pointer remains valid?

Michael


Re: Potentially missing CloseProtocol() call

Laszlo Ersek
 

Hi,

On 02/06/21 19:56, Satoshi Tanda wrote:
There are a number of places that do not call CloseProtocol() while it
appears to be required, in EDK2. Can someone confirm if (some of) those are
indeed errors, or there are actually cases where skipping CloseProtocol()
after OpenProtocol() is appropriate?

Here are the places I would expect a CloseProtocol() call but apparently
missing it.

MdeModulePkg/Universal/DebugSupportDxe/DebugSupport.c
- InitializeDebugSupportDriver().

ShellPkg/Library/UefiShellDriver1CommandsLib/Dh.c
- GetDriverName() / GetDriverImageName()

ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
- *ProtocolDumpInformation(). DevicePathProtocolDumpInformationEx() does
call it. So lack of call seems like an error to me.

ShellPkg/Library/UefiShellDriver1CommandsLib/DevTree.c
- DoDevTreeForHandle()

I am new to UEFI and trying to learn basics like how to use OpenProtocol().
I have not observed or encountered any concrete issue.
gBS->OpenProtocol() calls that pass the EFI_OPEN_PROTOCOL_GET_PROTOCOL
argument for the "Attributes" parameter *need not* be mirrored with
gBS->CloseProtocol() calls.

Please refer to the UEFI spec on the OpenProtocol() boot service,
Attributes=EFI_OPEN_PROTOCOL_GET_PROTOCOL:

[...] The caller is also not required to close the protocol
interface with EFI_BOOT_SERVICES.CloseProtocol().

So you *can* call CloseProtocol(), but you don't have to.

Thanks
Laszlo


Re: UEFI Payload Issue

Christian Walter
 

Hi,

we do have a updated fork here: github.com/9elements/edk2

This should be more stable than the current one - also we have at least build testing for the UEFIPayload branch.

Best,

Chris

On 2/6/21 9:56 AM, You, Benjamin wrote:
Hi,

If HPET works but 8254 does not work, further investigation could be on 8254
settings made by Coreboot.

Thanks,

- ben

-----Original Message-----
From: You, Benjamin
Sent: Saturday, February 6, 2021 4:41 PM
To: Ma, Maurice <maurice.ma@intel.com>; Laszlo Ersek <lersek@redhat.com>;
discuss@edk2.groups.io; sent888@gmail.com
Cc: Dong, Guo <guo.dong@intel.com>
Subject: RE: [edk2-discuss] UEFI Payload Issue

Hi,

Yes, timer could be a cause for this hang. Old Payload has the option of
USE_HPET_TIMER - you could try setting this to TRUE to use HPET instead of
8254

Thanks,

- ben

-----Original Message-----
From: Ma, Maurice <maurice.ma@intel.com>
Sent: Thursday, February 4, 2021 11:26 PM
To: Laszlo Ersek <lersek@redhat.com>; discuss@edk2.groups.io;
sent888@gmail.com
Cc: Dong, Guo <guo.dong@intel.com>; You, Benjamin
<benjamin.you@intel.com>
Subject: RE: [edk2-discuss] UEFI Payload Issue

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

-----Original Message-----
From: Laszlo Ersek <lersek@redhat.com>
Sent: Thursday, February 4, 2021 1:58
To: discuss@edk2.groups.io; sent888@gmail.com
Cc: Ma, Maurice <maurice.ma@intel.com>; Dong, Guo
<guo.dong@intel.com>; You, Benjamin <benjamin.you@intel.com>
Subject: Re: [edk2-discuss] UEFI Payload Issue

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
[0m [37m [40m
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


--
*Christian Walter*
*Head of Firmware Development / Cyber Security *



9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany
Email: christian.walter@9elements.com
Phone: _+49 234 68 94 188 <tel:+492346894188>_
Mobile: _+49 176 70845047 <tel:+4917670845047>_

Sitz der Gesellschaft: Bochum
Handelsregister: Amtsgericht Bochum, HRB 17519
Geschäftsführung: Sebastian Deutsch, Eray Basar

Datenschutzhinweise nach Art. 13 DSGVO <https://9elements.com/privacy>


Re: Bonding support for PXE Boot

Michael Brown
 

On 08/02/2021 10:59, UdayS via groups.io wrote:
We may have to see if we can implement something similar in UEFI driver.
One problem I see right away is : Incase port goes down and driver can add a capability to retry on other UP port, how to let UEFI SNP know of the change in MAC of new port. As PXE already has the address older interface.
If you were to choose to adopt iPXE's simple conceptual model then this would not be necessary. The boot firmware doesn't need to know or care that ports are participating in a bond: it just needs to be able to convince the switch to forward packets.

To illustrate: suppose that there are two physical interfaces on the host, connected to a switch that treats them as a bonded pair. Without any explicit configuration, an iPXE boot would go like this:

- iPXE opens the first interface ("net0") and starts sending DHCPDISCOVER

- The switch refuses to forward the DHCPDISCOVER packets and instead sends back LACP packets to check that the host is LACP-capable

- iPXE sees the LACP packet and sends back a response (which basically just says "yes, I can speak LACP, and this port is alive")

- iPXE defers timing out DHCP discovery while it waits for LACP to complete

- The switch sees the LACP response and starts forwarding packets

- Boot continues as expected

If there is a problem with the first port then iPXE would simply proceed to perform exactly the same process on the second port.

One major advantage of this scheme from the end-user perspective is that there is no need to configure anything bonding-related for the boot stage. It all Just Works with no user input required.

Michael


Re: UEFI Payload Issue

You, Benjamin <benjamin.you@...>
 

Hi,

If HPET works but 8254 does not work, further investigation could be on 8254
settings made by Coreboot.

Thanks,

- ben

-----Original Message-----
From: You, Benjamin
Sent: Saturday, February 6, 2021 4:41 PM
To: Ma, Maurice <maurice.ma@intel.com>; Laszlo Ersek <lersek@redhat.com>;
discuss@edk2.groups.io; sent888@gmail.com
Cc: Dong, Guo <guo.dong@intel.com>
Subject: RE: [edk2-discuss] UEFI Payload Issue

Hi,

Yes, timer could be a cause for this hang. Old Payload has the option of
USE_HPET_TIMER - you could try setting this to TRUE to use HPET instead of
8254

Thanks,

- ben

-----Original Message-----
From: Ma, Maurice <maurice.ma@intel.com>
Sent: Thursday, February 4, 2021 11:26 PM
To: Laszlo Ersek <lersek@redhat.com>; discuss@edk2.groups.io;
sent888@gmail.com
Cc: Dong, Guo <guo.dong@intel.com>; You, Benjamin
<benjamin.you@intel.com>
Subject: RE: [edk2-discuss] UEFI Payload Issue

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

-----Original Message-----
From: Laszlo Ersek <lersek@redhat.com>
Sent: Thursday, February 4, 2021 1:58
To: discuss@edk2.groups.io; sent888@gmail.com
Cc: Ma, Maurice <maurice.ma@intel.com>; Dong, Guo
<guo.dong@intel.com>; You, Benjamin <benjamin.you@intel.com>
Subject: Re: [edk2-discuss] UEFI Payload Issue

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
[0m [37m [40m
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


Re: UEFI Payload Issue

You, Benjamin <benjamin.you@...>
 

Hi,

Yes, timer could be a cause for this hang. Old Payload has the option of
USE_HPET_TIMER - you could try setting this to TRUE to use HPET instead of 8254

Thanks,

- ben

-----Original Message-----
From: Ma, Maurice <maurice.ma@intel.com>
Sent: Thursday, February 4, 2021 11:26 PM
To: Laszlo Ersek <lersek@redhat.com>; discuss@edk2.groups.io;
sent888@gmail.com
Cc: Dong, Guo <guo.dong@intel.com>; You, Benjamin
<benjamin.you@intel.com>
Subject: RE: [edk2-discuss] UEFI Payload Issue

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

-----Original Message-----
From: Laszlo Ersek <lersek@redhat.com>
Sent: Thursday, February 4, 2021 1:58
To: discuss@edk2.groups.io; sent888@gmail.com
Cc: Ma, Maurice <maurice.ma@intel.com>; Dong, Guo
<guo.dong@intel.com>; You, Benjamin <benjamin.you@intel.com>
Subject: Re: [edk2-discuss] UEFI Payload Issue

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
[0m [37m [40m
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


Re: How to link DXE_DRIVER from UEFI_APPLICATION?

Laszlo Ersek
 

On 02/06/21 05:49, joseph via [] wrote:
Hi Laszlo,

Thank you. But the problem is still not solved.

.../edk2/MyPkg/MyPkg.dsc(...): error 1001: Module type [UEFI_APPLICATION] is not supported by
library instance [.../edk2/SecurityPkg/Library/Tcg2PpVendorLibNull/Tcg2PpVendorLibNull.inf]
consumed by [.../edk2/MyPkg/MyApp/MyApp.inf]
After modifying several more steps through the method you suggested, the build was completed.
https://github.com/jc-lab/temp-edk2-tpm2-problem/commit/d9afc8f562d1bda190b27ac8db67df3b0a5bb24a
This is the bug (or, at least "one" bug) in your platform DSC file:

# TPM 2
Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2DeviceLibDTpm.inf
Tpm2DeviceLibTcg2|SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.inf

There is no such library class as "Tpm2DeviceLibTcg2".


Please refer to the commit message in the following commit:

https://github.com/tianocore/edk2/commit/0c0a50d6b3ff

Specifically, please see the part that starts with "Laszlo Ersek explained on the list why Tpm2DeviceLib..."

Thanks,
Laszlo

But I get the error like below.

/usr/bin/ld: Tpm2DeviceLibTcg2.obj (symbol from plugin): in function `mTcg2Protocol':
(.text+0x0): multiple definition of `Tpm2SubmitCommand'; Tpm2DeviceLibDTpm.obj (symbol from plugin):(.text+0x0): first defined here
/usr/bin/ld: Tpm2DeviceLibTcg2.obj (symbol from plugin): in function `mTcg2Protocol':
(.text+0x0): multiple definition of `Tpm2RequestUseTpm'; Tpm2DeviceLibDTpm.obj (symbol from plugin):(.text+0x0): first defined here
/usr/bin/ld: Tpm2DeviceLibTcg2.obj (symbol from plugin): in function `mTcg2Protocol':
(.text+0x0): multiple definition of `Tpm2RegisterTpm2DeviceLib'; Tpm2DeviceLibDTpm.obj (symbol from plugin):(.text+0x0): first defined here
collect2: error: ld returned 1 exit status
make: *** [GNUmakefile:375: ...MyApp.dll] Error 1
Can you help me a little more?


Re: Bonding support for PXE Boot

UdayS
 

Thanks Michael.
We may have to see if we can implement something similar in UEFI driver.
One problem I see right away is : Incase port goes down and driver can add a capability to retry on other UP port, how to let UEFI SNP know of the change in MAC of new port. As PXE already has the address older interface.


Re: Bonding support for PXE Boot

Michael Brown
 

On 06/02/2021 04:36, UdayS via groups.io wrote:
How can I support Bonding of ports and use new Virtual interface for PXE Boot in Hot-Standby mode in UEFI.
Is their any limitation on why it is NOT already supported yet.
Not sure if this would work in your boot scenario, but iPXE already allows you to PXE boot from a switch port that requires the use of port bonding via LACP (also known as IEEE 802.3ad or 802.1AX).

Network booting requires only a few seconds of data transfer that can trivially be retried if the link happens to be disrupted. iPXE therefore includes only a very simple LACP responder: any time it receives an LACP packet it will send a reply with some sane default values. For switch ports that have been configured to use port bonding with LACP, this is sufficient to convince the switch that the port is active.

I don't see any reference to port bonding within the EDK2 source code, so it doesn't look as though it's supported yet by standard UEFI PXE boot, sorry.

Hope that helps,

Michael


Re: How to execute Tpm2CommandClear with Physical Presence?

joseph@...
 

Using Tpm2DeviceLibTcg2 instead of Tpm2DeviceLibDTpm changed the error content.

Tpm2ClearControl - Device Error
ClearControl: Response Code error! 0x00000185
The contents of the error are the same even as execute the below code.
How can I use Platform Authentication?
Tcg2PhysicalPresenceLibSubmitRequestToPreOSFunction(TCG2_PHYSICAL_PRESENCE_CLEAR, 0);
Tcg2PhysicalPresenceLibProcessRequest(NULL);


Re: How to link DXE_DRIVER from UEFI_APPLICATION?

joseph@...
 

Oh, this was my mistake.
The above error was because the Tpm2DeviceLib and Tpm2DeviceLibTcg2 libraries were linked both.

Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2DeviceLibDTpm.inf
Tpm2DeviceLibTcg2|SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.inf
This discussion seems to be resolved.
I need to go to Bugzilla.

Thanks.


Re: Compile EDK2 to set boot order to PXE

Pete Batard
 

On 2021.02.06 16:01, Werner Buck wrote:
It is exactly as Micheal Brown put it. Thank you for all your thoughts into this!

> 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.
Actually this is what is surprising to me. When RPI4 UEFI is running it tries to boot `efi/boot/bootaa64.efi` as a first option but as the uefi is running from network boot is unable to find it. I would expect the firmware to then choose network boot but the pi actually does a reboot loop.
I believe the way Raspberry Pi defaults to network boot is actually by updating the boot options and issuing a reboot, per: https://github.com/tianocore/edk2-platforms/commit/8dd78ea11a38d2d7e8031c4783e9f2ca5569956b

In other words, we currently rely on hitting PlatformBootManagerUnableToBoot() once, so that we update the boot options, and then reboot the system into an environment that now has network boot as default.

You can validate this by simply extracting a newly built UEFI firmware (such as the one from the official archives) on USB/SD and powering up. You'll see that it takes one reboot, before it starts to look for network files.

But of course, that only works if you can save variables... which you can't do in this scenario. If you are downloading the same "pristine" UEFI firmware over and over, you will indeed hit a boot loop.

CCing Samer, who might have looked at alternatives to enable network boot by default, and could have some ideas of how we may achieve this, in a scenario where we can't save boot variables...

Regards,

/Pete

Mind that this is all without an SD card present currently. Should I raise a bug for this at the RPI4 platform side?
I am actually doing triple network boot here. And have actually had 0 reliability problems with network booting at least on the RPI4 with DHCP ISC server with the below config and having dnsmasq serve an tftp server.
Just for transparency this is what im running in an isc dhcp server:
```
# network boot coming in
if substring (option vendor-class-identifier,0,9) = "PXEClient" {
        option tftp-server-name "10.10.10.1";
        # raspberry pi defaults to loading bootcode.bin from tftp and i have the rpi4 uefi firmware just extracted on the tftproot.
        # when booted using uefi and starting network boot again architecture is 00:0b (uefi arm64) and we download iPXE
        if option arch = 00:0b {
           log(info, "This is UEFI ARM boot (raspberry pi), booting ipxe..");
           #specially compiled ipxe with 8gb
           filename "ipxe-pi.efi";
        }
}
# Detecting ipxe https flag so we point filename to the boot.ipxe filename.
if exists ipxe.https {
  log (info, "ipxe enabled");
  # matchbox server
  filename "http://10.10.10.1:8085/boot.ipxe <http://10.10.10.1:8085/boot.ipxe>";
}
```
Packing iPXE in some way and tricking UEFI with the PCD file GUID is what im going to try this weekend!
Thanks all I will keep you posted.
Werner Buck
Op do 4 feb. 2021 om 13:54 schreef Laszlo Ersek <lersek@redhat.com <mailto:lersek@redhat.com>>:
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
>


Potentially missing CloseProtocol() call

Satoshi Tanda
 

There are a number of places that do not call CloseProtocol() while it
appears to be required, in EDK2. Can someone confirm if (some of) those are
indeed errors, or there are actually cases where skipping CloseProtocol()
after OpenProtocol() is appropriate?

Here are the places I would expect a CloseProtocol() call but apparently
missing it.

MdeModulePkg/Universal/DebugSupportDxe/DebugSupport.c
- InitializeDebugSupportDriver().

ShellPkg/Library/UefiShellDriver1CommandsLib/Dh.c
- GetDriverName() / GetDriverImageName()

ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
- *ProtocolDumpInformation(). DevicePathProtocolDumpInformationEx() does
call it. So lack of call seems like an error to me.

ShellPkg/Library/UefiShellDriver1CommandsLib/DevTree.c
- DoDevTreeForHandle()

I am new to UEFI and trying to learn basics like how to use OpenProtocol().
I have not observed or encountered any concrete issue.

Best,
Satoshi


Re: Compile EDK2 to set boot order to PXE

wernerbuck@...
 

It is exactly as Micheal Brown put it. Thank you for all your thoughts into
this!

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.
Actually this is what is surprising to me. When RPI4 UEFI is running it
tries to boot `efi/boot/bootaa64.efi` as a first option but as the uefi is
running from network boot is unable to find it. I would expect the firmware
to then choose network boot but the pi actually does a reboot loop.
Mind that this is all without an SD card present currently. Should I raise
a bug for this at the RPI4 platform side?

I am actually doing triple network boot here. And have actually had 0
reliability problems with network booting at least on the RPI4 with DHCP
ISC server with the below config and having dnsmasq serve an tftp server.
Just for transparency this is what im running in an isc dhcp server:

```
# network boot coming in
if substring (option vendor-class-identifier,0,9) = "PXEClient" {
option tftp-server-name "10.10.10.1";
# raspberry pi defaults to loading bootcode.bin from tftp and i
have the rpi4 uefi firmware just extracted on the tftproot.
# when booted using uefi and starting network boot again
architecture is 00:0b (uefi arm64) and we download iPXE
if option arch = 00:0b {
log(info, "This is UEFI ARM boot (raspberry pi), booting
ipxe..");
#specially compiled ipxe with 8gb
filename "ipxe-pi.efi";
}
}
# Detecting ipxe https flag so we point filename to the boot.ipxe filename.
if exists ipxe.https {
log (info, "ipxe enabled");
# matchbox server
filename "http://10.10.10.1:8085/boot.ipxe";
}
```

Packing iPXE in some way and tricking UEFI with the PCD file GUID is what
im going to try this weekend!

Thanks all I will keep you posted.

Werner Buck


Op do 4 feb. 2021 om 13:54 schreef Laszlo Ersek <lersek@redhat.com>:

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


How to execute Tpm2CommandClear with Physical Presence?

joseph@...
 

Hi,

I want to Clear TPM.

So, I tried to execute Tpm2CommandClear, not work.
Tpm2ClearControl ...
Tpm2ClearControl - Not Found
How to clear TPM2 with Physical Presence?

Kind regards,
Joseph


Re: How to link DXE_DRIVER from UEFI_APPLICATION?

joseph@...
 

Hi Laszlo,

Thank you. But the problem is still not solved.

.../edk2/MyPkg/MyPkg.dsc(...): error 1001: Module type [UEFI_APPLICATION] is not supported by
library instance [.../edk2/SecurityPkg/Library/Tcg2PpVendorLibNull/Tcg2PpVendorLibNull.inf]
consumed by [.../edk2/MyPkg/MyApp/MyApp.inf]
After modifying several more steps through the method you suggested, the build was completed.
https://github.com/jc-lab/temp-edk2-tpm2-problem/commit/d9afc8f562d1bda190b27ac8db67df3b0a5bb24a
But I get the error like below.

/usr/bin/ld: Tpm2DeviceLibTcg2.obj (symbol from plugin): in function `mTcg2Protocol':
(.text+0x0): multiple definition of `Tpm2SubmitCommand'; Tpm2DeviceLibDTpm.obj (symbol from plugin):(.text+0x0): first defined here
/usr/bin/ld: Tpm2DeviceLibTcg2.obj (symbol from plugin): in function `mTcg2Protocol':
(.text+0x0): multiple definition of `Tpm2RequestUseTpm'; Tpm2DeviceLibDTpm.obj (symbol from plugin):(.text+0x0): first defined here
/usr/bin/ld: Tpm2DeviceLibTcg2.obj (symbol from plugin): in function `mTcg2Protocol':
(.text+0x0): multiple definition of `Tpm2RegisterTpm2DeviceLib'; Tpm2DeviceLibDTpm.obj (symbol from plugin):(.text+0x0): first defined here
collect2: error: ld returned 1 exit status
make: *** [GNUmakefile:375: ...MyApp.dll] Error 1
Can you help me a little more?
I will also create a Bugzilla ticket soon.

Kind regards,
Joseph


Bonding support for PXE Boot

UdayS
 

Hello Experts,
How can I support Bonding of ports and use new Virtual interface for PXE Boot in Hot-Standby mode in UEFI.
Is their any limitation on why it is NOT already supported yet.

-US


Re: [EXTERNAL] Re: [edk2-discuss] How to link DXE_DRIVER from UEFI_APPLICATION?

Bret Barkelew
 

Yeah, DxeTcg2PhysicalPresence could use some TLC. It’s a weird catch-all of stuff which should be refactored.
I’ve had it on my backlog forever.

- Bret

From: Laszlo Ersek via groups.io<mailto:lersek=redhat.com@groups.io>
Sent: Friday, February 5, 2021 7:47 AM
To: joseph@zeronsoftn.com<mailto:joseph@zeronsoftn.com>; discuss@edk2.groups.io<mailto:discuss@edk2.groups.io>
Subject: [EXTERNAL] Re: [edk2-discuss] How to link DXE_DRIVER from UEFI_APPLICATION?

On 02/05/21 15:44, joseph via [] wrote:
Hi, Laszlo

Thank you for reply.

My app does not use UefiDriverEntryPoint.
UefiDriverEntryPoint exists in DxeTcg2PhysicalPresenceLib.inf.
Ouch. That's a bug in "DxeTcg2PhysicalPresenceLib.inf", no doubt.

Let's see if there are some other library INF files that have a similar issue:

$ git grep -l -w UefiDriverEntryPoint -- '*inf' \
| xargs grep -l -w LIBRARY_CLASS

MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf
SecurityPkg/Library/DxeTcg2PhysicalPresenceLib/DxeTcg2PhysicalPresenceLib.inf
SecurityPkg/Library/DxeTcgPhysicalPresenceLib/DxeTcgPhysicalPresenceLib.inf

OK, so the bugged library INF files are:
- CustomizedDisplayLib.inf
- DxeTcg2PhysicalPresenceLib.inf
- DxeTcgPhysicalPresenceLib.inf

Can you please file a bugzilla ticket at <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2F&;data=04%7C01%7Cbret.barkelew%40microsoft.com%7Ca5ed4a8cc1d74674a28708d8c9ed6450%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637481368714208086%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=cUIKRsSv9HUywTgoybjzT%2FnavUVC4JLdCleHnpxjtg4%3D&amp;reserved=0>, about this? Those library instances should not depend on the UefiDriverEntryPoint class.


If forcibly delete UefiDriverEntryPoint from DxeTcg2PhysicalPresenceLib.inf, Another error occurs.
Instance of library class [Tcg2PpVendorLib] is not found
Wait, that's a different case.

When you delete UefiDriverEntryPoint from DxeTcg2PhysicalPresenceLib.inf, you actually fix a bug. And therefore the build process advances a bit further, before it runs into *another* problem.

This particular (new) problem is that your platform DSC file does not resolve the Tcg2PpVendorLib class to a library instance. DxeTcg2PhysicalPresenceLib depends on Tcg2PpVendorLib, but the build process doesn't know what instance of Tcg2PpVendorLib to use. Edk2 offers a Null instance of this library:

SecurityPkg/Library/Tcg2PpVendorLibNull/Tcg2PpVendorLibNull.inf

So in your DSC file, you could use:

[LibraryClasses]
Tcg2PpVendorLib|SecurityPkg/Library/Tcg2PpVendorLibNull/Tcg2PpVendorLibNull.inf

Hope this helps,
Laszlo

Adding the Tcg2PpVendorLib again gives me the "error 1001" error.

========== MyApp.inf =========
[LibraryClasses]
UefiApplicationEntryPoint
UefiLib
PcdLib
OpensslLib
Tpm2DeviceLibTcg2
Tcg2PhysicalPresenceLib

========== DxeTcg2PhysicalPresenceLib.inf =========
[LibraryClasses]
MemoryAllocationLib
UefiLib
UefiBootServicesTableLib
UefiDriverEntryPoint
UefiRuntimeServicesTableLib
BaseMemoryLib
DebugLib
PrintLib
HiiLib
HobLib
Tpm2CommandLib
Tcg2PpVendorLib

321 - 340 of 859