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 Message-
From: Andrew Fish [mailto:af...@apple.com]
Sent: Wednesday, April 30, 2014 10:39 AM
To: edk2-devel@lists.sourceforge.net
S
