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:[email protected]] Sent: Wednesday, April 30, 2014 6:36 PM To: [email protected] 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:[email protected]] Sent: Wednesday, April 30, 2014 6:19 PM To: [email protected] 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:[email protected]] Sent: Wednesday, April 30, 2014 6:06 PM To: [email protected] 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:[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 ---------------------------------------------------------------------------- -- "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
