Michael, I forgot to mention If the DXE phase does not produce all the protocols required to dispatch UEFI_DRIVERs you get a lot of DEBUG prints and an ASSERTs out of the DXE Core.
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c#L480 // // Display Architectural protocols that were not loaded if this is DEBUG build // DEBUG_CODE_BEGIN (); CoreDisplayMissingArchProtocols (); DEBUG_CODE_END (); // // Display any drivers that were not dispatched because dependency expression // evaluated to false if this is a debug build // DEBUG_CODE_BEGIN (); CoreDisplayDiscoveredNotDispatched (); DEBUG_CODE_END (); // // Assert if the Architectural Protocols are not present. // Status = CoreAllEfiServicesAvailable (); if (EFI_ERROR(Status)) { // // Report Status code that some Architectural Protocols are not present. // REPORT_STATUS_CODE ( EFI_ERROR_CODE | EFI_ERROR_MAJOR, (EFI_SOFTWARE_DXE_CORE | EFI_SW_DXE_CORE_EC_NO_ARCH) ); } ASSERT_EFI_ERROR (Status); > On May 17, 2017, at 11:09 PM, Andrew Fish <[email protected]> wrote: > >> >> On May 17, 2017, at 10:42 PM, Michael Zimmermann <[email protected] >> <mailto:[email protected]>> wrote: >> >> Michael, that's a good point but it only works for drivers which bind >> to a device. If you're just installing a protocol e.g. for virtual >> devices or special services which you don't want to turn into >> libraries then this doesn't work. >> >> Haojian, that's what I was thinking, I just wasn't sure if the order >> is reliable. >> > > Micheal, > > From a PI/UEFI architectural perspective the contract is the depex are > honored. If multiple drivers are TRUE at the same time the order they execute > is not defined. Basically it is implementation choice and you should not > write code that depends on this. This is why the A priori file exists, it is > the only architectural way to force order of dispatch. Well DXE has BEFORE > and AFTER. > > When I wrote the original dispatcher I ended up adding new drivers to the > tail of the list vs. the head. Both would have been legal from a spec point > of view. So by observing the current behavior you are conflating my > implementation choice with the contract provided by specification. > > >> Andrew, your description sounds like its about DXE_DRIVERs and their >> Depex sections, does this apply to UEFI_DRIVERs too when they're >> auto-loaded from the fdf(since they don't support the Depex section)? >> > > No Depex section for UEFI_DRIVERS implies this Depex: > > [Depex] > gEfiSecurityArchProtocolGuid AND > gEfiCpuArchProtocolGuid AND > gEfiMetronomeArchProtocolGuid AND > gEfiTimerArchProtocolGuid AND > gEfiBdsArchProtocolGuid AND > gEfiWatchdogTimerArchProtocolGuid AND > gEfiRuntimeArchProtocolGuid AND > gEfiVariableArchProtocolGuid AND > gEfiVariableWriteArchProtocolGuid AND > gEfiCapsuleArchProtocolGuid AND > gEfiMonotonicCounterArchProtocolGuid AND > gEfiResetArchProtocolGuid AND > gEfiRealTimeClockArchProtocolGuid > > This is how we glued PI (DXE_DRIVERS) and UEFI (UEFI_DRIVER) together. EFI > predates the concept of DXE in PI. > > The primary job of DXE_DRIVERS is to configure all the hardware required to > provide all the EFI Boot and Runtime Services. The above protocols are what > the DXE Core requires to produce all the EFI Boot and Runtime services. > > Thanks, > > Andrew Fish > >> Thanks for all your answers, >> Michael >> >> On Thu, May 18, 2017 at 7:21 AM, Andrew Fish <[email protected]> wrote: >>> >>>> On May 17, 2017, at 10:00 PM, Kinney, Michael D >>>> <[email protected]> wrote: >>>> >>>> Michael, >>>> >>>> The UEFI Driver Model and the Driver Binding Protocol >>>> provide support for this case. The idea is that a driver >>>> is loaded and started, but when a UEFI Driver is started, >>>> it only registers a Driver Binding Protocol. Then in the >>>> BDS phase, the devices required to boot are started using >>>> the UEFI Boot Service ConnectController() and >>>> ConnectController() calls the Driver Binding Protocol(s). >>>> >>>> The dependencies between UEFI Drivers are in their Driver >>>> Binding Protocols which are not used until after all of >>>> the UEFI Drivers are loaded and started. >>>> >>> >>> Micheal, >>> >>> 1st off no dependency is really a dependency on all the architecture >>> protocols, which is a fancy way of saying all the EFI Boot and Runtime >>> Services are available. >>> >>> Lets say you have a driver that depends on DiskIo. The DiskIo driver >>> depends on BlockIo. Now what happens when a disk driver is connected and >>> produces a BlockIO is the DiskIo driver can know get connected. The DXE >>> Core knows a protocol was added to the handle so it will keep trying to >>> connect drivers to that handle as long as new protocols get added. So this >>> is how the DriverBinding Support() is used to resolve the sequence issues. >>> >>> Thanks, >>> >>> Andrew Fish >>> >>>> Mike >>>> >>>>> -----Original Message----- >>>>> From: edk2-devel [mailto:[email protected]] On Behalf Of >>>>> Michael >>>>> Zimmermann >>>>> Sent: Wednesday, May 17, 2017 9:43 PM >>>>> To: edk2-devel-01 <[email protected]>; Zeng, Star >>>>> <[email protected]>; Dong, >>>>> Eric <[email protected]> >>>>> Subject: [edk2] UEFI_DRIVER dependencies >>>>> >>>>> I know that UEFI_DRIVERs don't need or support Depex sections, but >>>>> what if an UEFI_DRIVER depends on a protocol provided by another >>>>> UEFI_DRIVER? >>>>> Since they get loaded automatically because I put them in my >>>>> platform's fdf, it raises the question of the loading order. >>>>> >>>>> Will they get loaded in the order they're defined? How often will the >>>>> core retry if one of the drivers returns EFI_NOT_READY? >>>>> >>>>> Thanks, >>>>> Michael >>>>> _______________________________________________ >>>>> edk2-devel mailing list >>>>> [email protected] >>>>> https://lists.01.org/mailman/listinfo/edk2-devel >>>> _______________________________________________ >>>> edk2-devel mailing list >>>> [email protected] >>>> https://lists.01.org/mailman/listinfo/edk2-devel >>> >> _______________________________________________ >> edk2-devel mailing list >> [email protected] <mailto:[email protected]> >> https://lists.01.org/mailman/listinfo/edk2-devel >> <https://lists.01.org/mailman/listinfo/edk2-devel> > > _______________________________________________ > edk2-devel mailing list > [email protected] <mailto:[email protected]> > https://lists.01.org/mailman/listinfo/edk2-devel > <https://lists.01.org/mailman/listinfo/edk2-devel> _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
