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:[email protected]] Sent: Wednesday, April 30, 2014 10:39 AM To: [email protected] Subject: Re: [edk2] EndOfDxe? On Apr 30, 2014, at 7:29 AM, Zimmer, Vincent <[email protected]> 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:[email protected]] > Sent: Wednesday, April 30, 2014 10:10 AM > To: [email protected] > 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 > [email protected] > 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 > [email protected] > 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 [email protected] 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 [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
