Date   

Re: Can DXE drivers be included in executable EFI binary?

joseph@...
 

Hello Laszlo,

Thanks for your answer.

I looked at this a bit more today.
The cause is not that there is no driver, but it seems that Notify does not work properly for the protocol after installing the driver.

Immediately after booting, the EFI Shell recognizes NVMe devices but not partitions and filesystems.
If run `map -u` after loading anything filesystem driver (e.g. ext4) the NVMe partition and filesystems are recognized.

Do you know why?
And how can I Notify to gEfiSimpleFileSystemProtocolGuid?

Immediately after booting,
GetHandleListByProtocol(&gEfiSimpleFileSystemProtocolGuid);
Has a value of 2.

After installing any filesystem driver, its value will be 3.

Thanks.


Re: Can DXE drivers be included in executable EFI binary?

Laszlo Ersek
 

Dropping <joseph@zeronsoftn.com> from the address list, because the RH
SMTP server keeps telling me that the domain for that email address
(i.e., "zeronsoftn.com") is unidentifiable. Comments below.

On 02/21/21 07:55, joseph via groups.io wrote:
Hello,

Some computers (what I checked was an LG laptop) do not recognize the NVMe SSD as a block device in the EFI program.
Of course, the OS on the NVMe SSD is bootable.
But when I boot with Shellx64.efi in USB flash memory I can't find that disk.
In this case, load NvmExpressDxe and will be able to find the SSD.

So, I want to include NvmExpressDxe in my executable EFI Binary.
Or, after making the multiple files into FV, can make the FV into an executable EFI file?
These are really bad ideas.

"MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf" is a UEFI_DRIVER.
It is supposed to stay resident, and to provide various protocol services.

Your program is (AIUI) a UEFI_APPLICATION module. When it exits, it's gone.

This shows that, what you're considering, would fundamentally break the
UEFI driver model.

If your platform does not provide an NVMe driver, consider distributing
an NvmExpressDxe driver binary (in accordance with its license) on the
same USB disk as your own application. Users can load it or start it
manually, or they can create a Driver#### option too, for auto-loading it.

Laszlo


Can DXE drivers be included in executable EFI binary?

joseph@...
 

Hello,

Some computers (what I checked was an LG laptop) do not recognize the NVMe SSD as a block device in the EFI program.
Of course, the OS on the NVMe SSD is bootable.
But when I boot with Shellx64.efi in USB flash memory I can't find that disk.
In this case, load NvmExpressDxe and will be able to find the SSD.

So, I want to include NvmExpressDxe in my executable EFI Binary.
Or, after making the multiple files into FV, can make the FV into an executable EFI file?

Thanks.


Re: Questions about unusual PCI location when using EFI_PCI_IO_PROTOCOL in ARM system

gustavo.marcello@...
 

Hi Laszlo Ersek,
Thanks for the style comments, I appreciate it, I will do these changes.

And, for the questions, I agree, for the first question, that seems to be a platform driver bug and, for the second one, it seems something related to the platform as you said. I will try to contact the manufacturer to clarify if it's correct.

Thanks so much for your reply, it was very helpful!


Re: Questions about unusual PCI location when using EFI_PCI_IO_PROTOCOL in ARM system

Laszlo Ersek
 

On 02/16/21 14:41, gustavo.marcello via groups.io wrote:
Hello,

I am learning about PCI and trying to write an application that lists PCI controllers in UEFI environment, using EFI_PCI_IO_PROTOCOL and EDK2. I want to list some information from Configuration Space Header and the Bus/Device/Function location for each instance.

The system that I am executing the application is an ARM, which has a Qualcomm
Snapdragon SoC. The code simply locates all handles for EFI_PCI_IO_PROTOCOL and reads some information from each one, as shown in this code snippet:

EFI_GUID gPciIo = EFI_PCI_IO_PROTOCOL_GUID;
EFI_PCI_IO_PROTOCOL *PciIo;
...

// Locate all handles with PciIo protocol
gBS->LocateHandleBuffer(ByProtocol, &gPciIo, NULL, &NoHandles, &Buffer);
Style comment: you should remove "gPciIo", and use the auto-generated
"gEfiPciIoProtocolGuid" variable instead.


// Scan all found handles
for (Index = 0, Count = 0; Index < NoHandles; Index++) {
// Get PciIo protocol for current handle
gBS->HandleProtocol (Buffer[Index], &gPciIo, (VOID**) &PciIo);
// Get some PCI information
PciIo->Pci.Read (PciIo, EfiPciIoWidthUint8, 0x00, 2, &VendorId);
Why not read it with a single EfiPciIoWidthUint16 operation?

Also, for the offset, PCI_VENDOR_ID_OFFSET would be more idiomatic.

...
// Check if VendorId is different from 0xFFFF
...

// Get location
PciIo->GetLocation (PciIo, &Segment, &Bus, &Device, &Function);

// Show PCI information
...
}

The information retrieved from EFI_PCI_IO_PROTOCOL seems to be OK, except the information from GetLocation that some USB controller handles are returning, as follows:

Class: Serial Bus Controller
Subclass: USB Controller
Bus: 0xFF
Device: 0x80
Function: 0x00

Class: Serial Bus Controller
Subclass: USB Controller
Bus: 0xFF
Device: 0x81
Function: 0x00

Class: Serial Bus Controller
Subclass: USB Controller
Bus: 0xFF
Device: 0x82
Function: 0x00

My questions are:

1 - I am not familiar with PCI, but, as far as I know, maximum device number is 32, since it comes from a 5 bits field, am I correct? If so, how can it be 0x80, 0x81 or 0x82, maybe a bug in EFI_PCI_IO_PROTOCOL code or am I missing something?
Yes, I would hazard that this is a bug in your platform's PCI host
bridge driver. (I assume they use the PCI bus driver from edk2 without
any modifications.)

Or maybe the MMCONFIG range is misconfigured somehow; not sure.

(I'm reminded of ARI too, which I don't have any practical experience
with, however. ARI seems to permit up to 256 functions, combining the 5
bits from the device number with the 3 bits from the function number.
But a *device* number as high as 0x80 -- and not a function number that
high -- looks a bit fishy still. ARI seems to eliminate the device
number completely.)


2 - Usually , the bus numbering use sequential numbers starting from 0 (afaik again), and since it's a simple small system with few PCI components (it does not have 255 buses), what does the number 0xFF for Bus indicates?
Assuming the bus number refers to a root bridge (and not a bridge behind
a root port, or the downstream port of a switch), the bus number is not
assigned by the PCI bus driver. It's just a platform trait. I don't
think it's necessarily a bug.

Hope this helps; I could only make some guesses.
Laszlo



PS: "pci" command in UEFI Shell do not show these USB controllers but "devtree" command shows these USB contollers with the same Device/Funcion numbers.

Thanks so much!





Questions about unusual PCI location when using EFI_PCI_IO_PROTOCOL in ARM system

gustavo.marcello@...
 

Hello,

I am learning about PCI and trying to write an application that lists PCI controllers in UEFI environment, using EFI_PCI_IO_PROTOCOL and EDK2. I want to list some information from Configuration Space Header and the Bus/Device/Function location for each instance.

The system that I am executing the application is an ARM, which has a Qualcomm
Snapdragon SoC. The code simply locates all handles for EFI_PCI_IO_PROTOCOL and reads some information from each one, as shown in this code snippet:

EFI_GUID gPciIo = EFI_PCI_IO_PROTOCOL_GUID;
EFI_PCI_IO_PROTOCOL *PciIo;
...

// Locate all handles with PciIo protocol
gBS->LocateHandleBuffer(ByProtocol, &gPciIo, NULL, &NoHandles, &Buffer);

// Scan all found handles
for (Index = 0, Count = 0; Index < NoHandles; Index++) {
// Get PciIo protocol for current handle
gBS->HandleProtocol (Buffer[Index], &gPciIo, (VOID**) &PciIo);
// Get some PCI information
PciIo->Pci.Read (PciIo, EfiPciIoWidthUint8, 0x00, 2, &VendorId);
...
// Check if VendorId is different from 0xFFFF
...

// Get location
PciIo->GetLocation (PciIo, &Segment, &Bus, &Device, &Function);

// Show PCI information
...
}

The information retrieved from EFI_PCI_IO_PROTOCOL seems to be OK, except the information from GetLocation that some USB controller handles are returning, as follows:

Class: Serial Bus Controller
Subclass: USB Controller
Bus: 0xFF
Device: 0x80
Function: 0x00

Class: Serial Bus Controller
Subclass: USB Controller
Bus: 0xFF
Device: 0x81
Function: 0x00

Class: Serial Bus Controller
Subclass: USB Controller
Bus: 0xFF
Device: 0x82
Function: 0x00

My questions are:

1 - I am not familiar with PCI, but, as far as I know, maximum device number is 32, since it comes from a 5 bits field, am I correct? If so, how can it be 0x80, 0x81 or 0x82, maybe a bug in EFI_PCI_IO_PROTOCOL code or am I missing something?

2 - Usually , the bus numbering use sequential numbers starting from 0 (afaik again), and since it's a simple small system with few PCI components (it does not have 255 buses), what does the number 0xFF for Bus indicates?

PS: "pci" command in UEFI Shell do not show these USB controllers but "devtree" command shows these USB contollers with the same Device/Funcion numbers.

Thanks so much!


UEFI-SCT: Support for UEFI-SCT for X86 architecture.

gauravpandya321@...
 

Hi,

I was trying to build the UEFI-SCT for EDK2 on my windows box running cygwin.
I follow edk2-test/uefi-sct/HowToBuild/How to build SCT.txt for build instruction. It says X64 is unsupported target architecture.

Also on CYGWIN i had to mention RVCT as tool chain and RVCT seems to support only ARM.
How can i build UEFI-SCT for EDK2 ?

There are some instruction to build UEFI-SCT for UDK2017:
edk2-test/uefi-sct/HowToBuild/How to build SCT in UDK2017.txt

But i want to build and test EDK2.

Thanks.


Re: Potentially missing CloseProtocol() call

Laszlo Ersek
 

On 02/09/21 13:33, Michael Brown wrote:
On 09/02/2021 11:54, Laszlo Ersek wrote:
On 02/08/21 16:28, Michael Brown wrote:
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?
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.

<snip>
Thank you!  I see that text in the documentation for the deprecated call
UninstallProtocolInterface(), which explains why I hadn't previously
noticed it.
Right, my apologies. I'm not sure why I wrote CloseProtocol(). Perhaps a
typo, or maybe I lost track of where I was in the PDF with "evince".


My comments:

(1) I don't really understand what the last quoted passage means by
"closing an agent".
Based on what the EDK2 implementation actually does, I'm pretty sure
this means that any opens recorded with attributes of
BY_HANDLE_PROTOCOL, GET_PROTOCOL, or TEST_PROTOCOL are simply discarded:

https://github.com/tianocore/edk2/blob/stable/202011/MdeModulePkg/Core/Dxe/Hand/Handle.c#L659-L674


The code that performed the BY_HANDLE_PROTOCOL, GET_PROTOCOL, or
TEST_PROTOCOL open is not notified in any way.

(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.
They are tracked, but as far as I can tell only for informative purposes
(e.g. debugging using the EFI shell "openinfo" command, or with iPXE's
DBG_EFI_OPENERS() call).

So: technically a leak, but a leak that is arguably useful from the
perspective of someone (e.g. quite often me) trying to debug what code
has tried to do something with a particular handle.  And a leak that
will get automatically cleaned up when the protocol is uninstalled.


But this still leaves my original problem: there is no way for code to
ever know that a protocol it opened with GET_PROTOCOL has ceased to be
valid, and nothing that stops said code from dereferencing the
potentially invalid pointer.
That seems to be the case, yes.

As far as I can tell, the only way to be notified when a protocol
pointer ceases to be valid is to open BY_DRIVER, and we can't open some
protocols (such as EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL) with BY_DRIVER
attributes because there will be multiple openers of that protocol.
Agreed.

Laszlo


Re: Potentially missing CloseProtocol() call

Michael Brown
 

On 09/02/2021 11:54, Laszlo Ersek wrote:
On 02/08/21 16:28, Michael Brown wrote:
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?
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.
<snip>
Thank you! I see that text in the documentation for the deprecated call UninstallProtocolInterface(), which explains why I hadn't previously noticed it.

My comments:
(1) I don't really understand what the last quoted passage means by
"closing an agent".
Based on what the EDK2 implementation actually does, I'm pretty sure this means that any opens recorded with attributes of BY_HANDLE_PROTOCOL, GET_PROTOCOL, or TEST_PROTOCOL are simply discarded:

https://github.com/tianocore/edk2/blob/stable/202011/MdeModulePkg/Core/Dxe/Hand/Handle.c#L659-L674

The code that performed the BY_HANDLE_PROTOCOL, GET_PROTOCOL, or TEST_PROTOCOL open is not notified in any way.

(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.
They are tracked, but as far as I can tell only for informative purposes (e.g. debugging using the EFI shell "openinfo" command, or with iPXE's DBG_EFI_OPENERS() call).

So: technically a leak, but a leak that is arguably useful from the perspective of someone (e.g. quite often me) trying to debug what code has tried to do something with a particular handle. And a leak that will get automatically cleaned up when the protocol is uninstalled.


But this still leaves my original problem: there is no way for code to ever know that a protocol it opened with GET_PROTOCOL has ceased to be valid, and nothing that stops said code from dereferencing the potentially invalid pointer.

As far as I can tell, the only way to be notified when a protocol pointer ceases to be valid is to open BY_DRIVER, and we can't open some protocols (such as EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL) with BY_DRIVER attributes because there will be multiple openers of that protocol.

Michael


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

341 - 360 of 888