Re: [edk2] EndOfDxe?
Vincent --
I understand the business problems all too well. But the EDK2 reference
implementation should be able to comply as it exists today, even if we were to
put the signal at the last possible point before the connect console and
Driver processing. We perpetuate this problem on both the x86 side and ARM
by leaving it out but having EDK2 drivers depend on it.
Tim
-Original Message-
From: Zimmer, Vincent [mailto:vincent.zim...@intel.com]
Sent: Wednesday, April 30, 2014 6:36 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] EndOfDxe?
Tim:
I agree. First order business problem is evolving implementations to adhere to
strictures of PI spec about 3rd party code in volume 2 of the PI Spec from
uefi.org, viz,
5.1.2.1 End of DXE Event
Prior to invoking any UEFI drivers, applications, or connecting consoles, the
platform should signal the event EFI_END_OF_DXE_EVENT_GUID.
#define EFI_END_OF_DXE_EVENT_GROUP_GUID \ { 0x2ce967a, 0xdd7e, 0x4ffc, { 0x9e,
0xe7, 0x81, 0xc, \ 0xf0, 0x47, 0x8, 0x80 } }
>From SEC through the signaling of this event, all of the components
>should
be under the authority of
the platform manufacturer and not have to worry about interaction or corruption
by 3rd party extensible modules. As such, PI modules that need to lock or
protect their resources in anticipation of the invocation of 3rd party
extensible modules, such as UEFI drivers, should register for notification on
this event and effect the appropriate protections in their notification handler
Vincent
-Original Message-
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Wednesday, April 30, 2014 6:19 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] EndOfDxe?
Vincent --
Less worried about the exact location, but want it to meet the PI-imposed
requirements of before console connection or processing DriverOrder or
BootOrder.
Tim
-Original Message-
From: Zimmer, Vincent [mailto:vincent.zim...@intel.com]
Sent: Wednesday, April 30, 2014 6:06 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] EndOfDxe?
Tim:
I wanted to follow-up a bit on the complexity of doing this. Maybe relax the '
immediately upon calling the BdsEntry() function in BdsDxe.' language in your
initial message to 'somewhere within BdsEntry() of BdsDxe' if that wasn't
already your intent.
Why?
Signaling of the EndOfDxe event is a bit tricky since it may need to be done in
some intermediate portion of the platform Bds logic, not necessarily at the
top, for a given platform.
Specifically, if you were to simplify logic in
https://svn.code.sf.net/p/edk2/code/trunk/edk2/IntelFrameworkModulePkg/Unive
rsal/BdsDxe/BdsEntry.c
You might not signal the event at
VOID
EFIAPI
BdsEntry (
IN EFI_BDS_ARCH_PROTOCOL *This
)
{
LIST_ENTRY DriverOptionList;
LIST_ENTRY BootOptionList;
UINTN BootNextSize;
CHAR16 *FirmwareVendor;
EFI_STATUS Status;
UINT16 BootTimeOut;
UINTN Index;
EDKII_VARIABLE_LOCK_PROTOCOL*VariableLock;
SignalEndOfDxe here
But instead perhaps later in the code, prior to the code block:
//
// Set up the device list based on EFI 1.1 variables
// process Driver and Load the driver's in the
// driver option list
//
BdsLibBuildOptionFromVar (&DriverOptionList, L"DriverOrder");
if (!IsListEmpty (&DriverOptionList)) {
BdsLibLoadDrivers (&DriverOptionList);
}
//
// Check if we have the boot next option
//
mBootNext = BdsLibGetVariableAndSize (
L"BootNext",
&gEfiGlobalVariableGuid,
&BootNextSize
);
//
// Setup some platform policy here
//
PlatformBdsPolicyBehavior (&DriverOptionList, &BootOptionList,
BdsProcessCapsules, BdsMemoryTest);
PERF_END (NULL, "PlatformBds", "BDS", 0);
//
// BDS select the boot device to load OS
//
BdsBootDeviceSelect ();
Why?
Prior to loading drivers and doing connects, you may want the platform to be
open (assuming an EndOfDxe handler locks flash, for example).
Other examples in platform Bds's not in our open source one includes capsule
processing.
Perhaps the Bds logic there
BdsEntry()
{
Process capsule
If there exists a valid capsule, connect just my integrated gfx driver so that
I can provide output while processing capsules
Signal end of Dxe to lock flash
Load and run 3rd party drivers
Connect rest of consoles
etc
}
So I agree w/ need, but maybe each package owner needs to do the analysis on
where in their Bds to put this logic.
So this isn't so much a question of 'if' we should do it, which we all agree is
good, but perhaps 'where' in the respective Bds driver?
Thanks,
Vincent
-Original
Re: [edk2] EndOfDxe?
Tim:
I agree. First order business problem is evolving implementations to adhere
to strictures of PI spec about 3rd party code in volume 2 of the PI Spec
from uefi.org, viz,
5.1.2.1 End of DXE Event
Prior to invoking any UEFI drivers, applications, or connecting consoles,
the platform should signal
the event EFI_END_OF_DXE_EVENT_GUID.
#define EFI_END_OF_DXE_EVENT_GROUP_GUID \
{ 0x2ce967a, 0xdd7e, 0x4ffc, { 0x9e, 0xe7, 0x81, 0xc, \
0xf0, 0x47, 0x8, 0x80 } }
>From SEC through the signaling of this event, all of the components should
be under the authority of
the platform manufacturer and not have to worry about interaction or
corruption by 3rd party
extensible modules. As such, PI modules that need to lock or protect their
resources in anticipation
of the invocation of 3rd party extensible modules, such as UEFI drivers,
should register for
notification on this event and effect the appropriate protections in their
notification handler
Vincent
-Original Message-
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Wednesday, April 30, 2014 6:19 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] EndOfDxe?
Vincent --
Less worried about the exact location, but want it to meet the PI-imposed
requirements of before console connection or processing DriverOrder or
BootOrder.
Tim
-Original Message-
From: Zimmer, Vincent [mailto:vincent.zim...@intel.com]
Sent: Wednesday, April 30, 2014 6:06 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] EndOfDxe?
Tim:
I wanted to follow-up a bit on the complexity of doing this. Maybe relax
the ' immediately upon calling the BdsEntry() function in BdsDxe.' language
in your initial message to 'somewhere within BdsEntry() of BdsDxe' if that
wasn't already your intent.
Why?
Signaling of the EndOfDxe event is a bit tricky since it may need to be done
in some intermediate portion of the platform Bds logic, not necessarily at
the top, for a given platform.
Specifically, if you were to simplify logic in
https://svn.code.sf.net/p/edk2/code/trunk/edk2/IntelFrameworkModulePkg/Unive
rsal/BdsDxe/BdsEntry.c
You might not signal the event at
VOID
EFIAPI
BdsEntry (
IN EFI_BDS_ARCH_PROTOCOL *This
)
{
LIST_ENTRY DriverOptionList;
LIST_ENTRY BootOptionList;
UINTN BootNextSize;
CHAR16 *FirmwareVendor;
EFI_STATUS Status;
UINT16 BootTimeOut;
UINTN Index;
EDKII_VARIABLE_LOCK_PROTOCOL*VariableLock;
SignalEndOfDxe here
But instead perhaps later in the code, prior to the code block:
//
// Set up the device list based on EFI 1.1 variables
// process Driver and Load the driver's in the
// driver option list
//
BdsLibBuildOptionFromVar (&DriverOptionList, L"DriverOrder");
if (!IsListEmpty (&DriverOptionList)) {
BdsLibLoadDrivers (&DriverOptionList);
}
//
// Check if we have the boot next option
//
mBootNext = BdsLibGetVariableAndSize (
L"BootNext",
&gEfiGlobalVariableGuid,
&BootNextSize
);
//
// Setup some platform policy here
//
PlatformBdsPolicyBehavior (&DriverOptionList, &BootOptionList,
BdsProcessCapsules, BdsMemoryTest);
PERF_END (NULL, "PlatformBds", "BDS", 0);
//
// BDS select the boot device to load OS
//
BdsBootDeviceSelect ();
Why?
Prior to loading drivers and doing connects, you may want the platform to be
open (assuming an EndOfDxe handler locks flash, for example).
Other examples in platform Bds's not in our open source one includes capsule
processing.
Perhaps the Bds logic there
BdsEntry()
{
Process capsule
If there exists a valid capsule, connect just my integrated gfx driver so
that I can provide output while processing capsules
Signal end of Dxe to lock flash
Load and run 3rd party drivers
Connect rest of consoles
etc
}
So I agree w/ need, but maybe each package owner needs to do the analysis on
where in their Bds to put this logic.
So this isn't so much a question of 'if' we should do it, which we all agree
is good, but perhaps 'where' in the respective Bds driver?
Thanks,
Vincent
-Original Message-
From: Andrew Fish [mailto:af...@apple.com]
Sent: Wednesday, April 30, 2014 10:39 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] EndOfDxe?
On Apr 30, 2014, at 7:29 AM, Zimmer, Vincent
wrote:
> I agree w/ your concern and the proposed placement.
> This omission has caused a lot of confusion.
I've also seen issues porting EDK code..
Thanks,
Andrew Fish
> Vincent
>
> -Original Message-----
> From: Tim Lewis [mailto:tim.le...@insyde.com]
> Sent: Wednesday, April 30, 2014 10:10 AM
> To: edk2-devel@lists.sourceforge.
Re: [edk2] EndOfDxe?
Vincent --
Less worried about the exact location, but want it to meet the PI-imposed
requirements of before console connection or processing DriverOrder or
BootOrder.
Tim
-Original Message-
From: Zimmer, Vincent [mailto:vincent.zim...@intel.com]
Sent: Wednesday, April 30, 2014 6:06 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] EndOfDxe?
Tim:
I wanted to follow-up a bit on the complexity of doing this. Maybe relax the '
immediately upon calling the BdsEntry() function in BdsDxe.' language in your
initial message to 'somewhere within BdsEntry() of BdsDxe' if that wasn't
already your intent.
Why?
Signaling of the EndOfDxe event is a bit tricky since it may need to be done in
some intermediate portion of the platform Bds logic, not necessarily at the
top, for a given platform.
Specifically, if you were to simplify logic in
https://svn.code.sf.net/p/edk2/code/trunk/edk2/IntelFrameworkModulePkg/Unive
rsal/BdsDxe/BdsEntry.c
You might not signal the event at
VOID
EFIAPI
BdsEntry (
IN EFI_BDS_ARCH_PROTOCOL *This
)
{
LIST_ENTRY DriverOptionList;
LIST_ENTRY BootOptionList;
UINTN BootNextSize;
CHAR16 *FirmwareVendor;
EFI_STATUS Status;
UINT16 BootTimeOut;
UINTN Index;
EDKII_VARIABLE_LOCK_PROTOCOL*VariableLock;
SignalEndOfDxe here
But instead perhaps later in the code, prior to the code block:
//
// Set up the device list based on EFI 1.1 variables
// process Driver and Load the driver's in the
// driver option list
//
BdsLibBuildOptionFromVar (&DriverOptionList, L"DriverOrder");
if (!IsListEmpty (&DriverOptionList)) {
BdsLibLoadDrivers (&DriverOptionList);
}
//
// Check if we have the boot next option
//
mBootNext = BdsLibGetVariableAndSize (
L"BootNext",
&gEfiGlobalVariableGuid,
&BootNextSize
);
//
// Setup some platform policy here
//
PlatformBdsPolicyBehavior (&DriverOptionList, &BootOptionList,
BdsProcessCapsules, BdsMemoryTest);
PERF_END (NULL, "PlatformBds", "BDS", 0);
//
// BDS select the boot device to load OS
//
BdsBootDeviceSelect ();
Why?
Prior to loading drivers and doing connects, you may want the platform to be
open (assuming an EndOfDxe handler locks flash, for example).
Other examples in platform Bds's not in our open source one includes capsule
processing.
Perhaps the Bds logic there
BdsEntry()
{
Process capsule
If there exists a valid capsule, connect just my integrated gfx driver so that
I can provide output while processing capsules
Signal end of Dxe to lock flash
Load and run 3rd party drivers
Connect rest of consoles
etc
}
So I agree w/ need, but maybe each package owner needs to do the analysis on
where in their Bds to put this logic.
So this isn't so much a question of 'if' we should do it, which we all agree is
good, but perhaps 'where' in the respective Bds driver?
Thanks,
Vincent
-Original Message-
From: Andrew Fish [mailto:af...@apple.com]
Sent: Wednesday, April 30, 2014 10:39 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] EndOfDxe?
On Apr 30, 2014, at 7:29 AM, Zimmer, Vincent
wrote:
> I agree w/ your concern and the proposed placement.
> This omission has caused a lot of confusion.
I've also seen issues porting EDK code..
Thanks,
Andrew Fish
> Vincent
>
> -Original Message-
> From: Tim Lewis [mailto:tim.le...@insyde.com]
> Sent: Wednesday, April 30, 2014 10:10 AM
> To: edk2-devel@lists.sourceforge.net
> Subject: [edk2] EndOfDxe?
>
> I see that more and more drivers are adding callbacks for the
> PI-defined EndOfDxe event group. However, none of the EDK2
> implementations signal this event group. As a result, we are seeing
> widely varying implementations as to its placement, and a lot of
> assumptions about what is completed at that point. For example, is PCI
> enumeration complete? IMO, you can't assume that because no UEFI
> devices have been connected. As the PI spec says: " Prior to invoking
> any UEFI drivers, applications, or connecting consoles, the platform
should signal the event EFI_END_OF_DXE_EVENT_GUID."
>
> So it seems appropriate that the signaling of this event should be
> immediately upon calling the BdsEntry() function in BdsDxe.
>
> Thoughts?
>
> Tim
>
> --
> --
> --
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> unparallele
Re: [edk2] EndOfDxe?
Tim:
I wanted to follow-up a bit on the complexity of doing this. Maybe relax
the ' immediately upon calling the BdsEntry() function in BdsDxe.' language
in your initial message to 'somewhere within BdsEntry() of BdsDxe' if that
wasn't already your intent.
Why?
Signaling of the EndOfDxe event is a bit tricky since it may need to be done
in some intermediate portion of the platform Bds logic, not necessarily at
the top, for a given platform.
Specifically, if you were to simplify logic in
https://svn.code.sf.net/p/edk2/code/trunk/edk2/IntelFrameworkModulePkg/Unive
rsal/BdsDxe/BdsEntry.c
You might not signal the event at
VOID
EFIAPI
BdsEntry (
IN EFI_BDS_ARCH_PROTOCOL *This
)
{
LIST_ENTRY DriverOptionList;
LIST_ENTRY BootOptionList;
UINTN BootNextSize;
CHAR16 *FirmwareVendor;
EFI_STATUS Status;
UINT16 BootTimeOut;
UINTN Index;
EDKII_VARIABLE_LOCK_PROTOCOL*VariableLock;
SignalEndOfDxe here
But instead perhaps later in the code, prior to the code block:
//
// Set up the device list based on EFI 1.1 variables
// process Driver and Load the driver's in the
// driver option list
//
BdsLibBuildOptionFromVar (&DriverOptionList, L"DriverOrder");
if (!IsListEmpty (&DriverOptionList)) {
BdsLibLoadDrivers (&DriverOptionList);
}
//
// Check if we have the boot next option
//
mBootNext = BdsLibGetVariableAndSize (
L"BootNext",
&gEfiGlobalVariableGuid,
&BootNextSize
);
//
// Setup some platform policy here
//
PlatformBdsPolicyBehavior (&DriverOptionList, &BootOptionList,
BdsProcessCapsules, BdsMemoryTest);
PERF_END (NULL, "PlatformBds", "BDS", 0);
//
// BDS select the boot device to load OS
//
BdsBootDeviceSelect ();
Why?
Prior to loading drivers and doing connects, you may want the platform to be
open (assuming an EndOfDxe handler locks flash, for example).
Other examples in platform Bds's not in our open source one includes capsule
processing.
Perhaps the Bds logic there
BdsEntry()
{
Process capsule
If there exists a valid capsule, connect just my integrated gfx driver so
that I can provide output while processing capsules
Signal end of Dxe to lock flash
Load and run 3rd party drivers
Connect rest of consoles
etc
}
So I agree w/ need, but maybe each package owner needs to do the analysis on
where in their Bds to put this logic.
So this isn't so much a question of 'if' we should do it, which we all agree
is good, but perhaps 'where' in the respective Bds driver?
Thanks,
Vincent
-Original Message-
From: Andrew Fish [mailto:af...@apple.com]
Sent: Wednesday, April 30, 2014 10:39 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] EndOfDxe?
On Apr 30, 2014, at 7:29 AM, Zimmer, Vincent
wrote:
> I agree w/ your concern and the proposed placement.
> This omission has caused a lot of confusion.
I've also seen issues porting EDK code..
Thanks,
Andrew Fish
> Vincent
>
> -Original Message-
> From: Tim Lewis [mailto:tim.le...@insyde.com]
> Sent: Wednesday, April 30, 2014 10:10 AM
> To: edk2-devel@lists.sourceforge.net
> Subject: [edk2] EndOfDxe?
>
> I see that more and more drivers are adding callbacks for the
> PI-defined EndOfDxe event group. However, none of the EDK2
> implementations signal this event group. As a result, we are seeing
> widely varying implementations as to its placement, and a lot of
> assumptions about what is completed at that point. For example, is PCI
> enumeration complete? IMO, you can't assume that because no UEFI
> devices have been connected. As the PI spec says: " Prior to invoking
> any UEFI drivers, applications, or connecting consoles, the platform
should signal the event EFI_END_OF_DXE_EVENT_GUID."
>
> So it seems appropriate that the signaling of this event should be
> immediately upon calling the BdsEntry() function in BdsDxe.
>
> Thoughts?
>
> Tim
>
> --
> --
> --
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> unparalleled scalability from the best Selenium testing platform
available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
> -
Re: [edk2] EndOfDxe?
On Apr 30, 2014, at 7:29 AM, Zimmer, Vincent wrote: > I agree w/ your concern and the proposed placement. > This omission has caused a lot of confusion. I’ve also seen issues porting EDK code…. Thanks, Andrew Fish > Vincent > > -Original Message- > From: Tim Lewis [mailto:tim.le...@insyde.com] > Sent: Wednesday, April 30, 2014 10:10 AM > To: edk2-devel@lists.sourceforge.net > Subject: [edk2] EndOfDxe? > > I see that more and more drivers are adding callbacks for the PI-defined > EndOfDxe event group. However, none of the EDK2 implementations signal this > event group. As a result, we are seeing widely varying implementations as to > its placement, and a lot of assumptions about what is completed at that > point. For example, is PCI enumeration complete? IMO, you can't assume that > because no UEFI devices have been connected. As the PI spec says: " Prior > to invoking any UEFI drivers, applications, or connecting consoles, the > platform should signal the event EFI_END_OF_DXE_EVENT_GUID." > > So it seems appropriate that the signaling of this event should be > immediately upon calling the BdsEntry() function in BdsDxe. > > Thoughts? > > Tim > > > -- > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE > Instantly run your Selenium tests across 300+ browser/OS combos. Get > unparalleled scalability from the best Selenium testing platform available. > Simple to use. Nothing to install. Get started now for free." > http://p.sf.net/sfu/SauceLabs > ___ > edk2-devel mailing list > edk2-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/edk2-devel > -- > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE > Instantly run your Selenium tests across 300+ browser/OS combos. Get > unparalleled scalability from the best Selenium testing platform available. > Simple to use. Nothing to install. Get started now for free." > http://p.sf.net/sfu/SauceLabs___ > edk2-devel mailing list > edk2-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/edk2-devel -- "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] EndOfDxe?
I agree w/ your concern and the proposed placement. This omission has caused a lot of confusion. Vincent -Original Message- From: Tim Lewis [mailto:tim.le...@insyde.com] Sent: Wednesday, April 30, 2014 10:10 AM To: edk2-devel@lists.sourceforge.net Subject: [edk2] EndOfDxe? I see that more and more drivers are adding callbacks for the PI-defined EndOfDxe event group. However, none of the EDK2 implementations signal this event group. As a result, we are seeing widely varying implementations as to its placement, and a lot of assumptions about what is completed at that point. For example, is PCI enumeration complete? IMO, you can't assume that because no UEFI devices have been connected. As the PI spec says: " Prior to invoking any UEFI drivers, applications, or connecting consoles, the platform should signal the event EFI_END_OF_DXE_EVENT_GUID." So it seems appropriate that the signaling of this event should be immediately upon calling the BdsEntry() function in BdsDxe. Thoughts? Tim -- "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel smime.p7s Description: S/MIME cryptographic signature -- "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] EndOfDxe?
I see that more and more drivers are adding callbacks for the PI-defined EndOfDxe event group. However, none of the EDK2 implementations signal this event group. As a result, we are seeing widely varying implementations as to its placement, and a lot of assumptions about what is completed at that point. For example, is PCI enumeration complete? IMO, you can't assume that because no UEFI devices have been connected. As the PI spec says: " Prior to invoking any UEFI drivers, applications, or connecting consoles, the platform should signal the event EFI_END_OF_DXE_EVENT_GUID." So it seems appropriate that the signaling of this event should be immediately upon calling the BdsEntry() function in BdsDxe. Thoughts? Tim -- "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
