UEFI_DRIVER dependencies

UEFI_DRIVER dependencies

[Michael Zimmermann]

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

Re: UEFI_DRIVER dependencies

[Haojian Zhuang]

On 2017/5/18 12:43, Michael Zimmermann wrote:
> 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?
>

Just adjust the driver sequence in both dsc and fdf file. Then they will 
get loaded in your order.

Regards
Haojian

Re: UEFI_DRIVER dependencies

[Kinney, Michael D]

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.

Mike

> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Michael
> Zimmermann
> Sent: Wednesday, May 17, 2017 9:43 PM
> To: edk2-devel-01 <edk2-devel@lists.01.org>; Zeng, Star <star.zeng@intel.com>; Dong,
> Eric <eric.dong@intel.com>
> 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
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

Re: UEFI_DRIVER dependencies

[Andrew Fish]

> On May 17, 2017, at 10:00 PM, Kinney, Michael D <michael.d.kinney@intel.com> 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:edk2-devel-bounces@lists.01.org] On Behalf Of Michael
>> Zimmermann
>> Sent: Wednesday, May 17, 2017 9:43 PM
>> To: edk2-devel-01 <edk2-devel@lists.01.org>; Zeng, Star <star.zeng@intel.com>; Dong,
>> Eric <eric.dong@intel.com>
>> 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
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

Re: UEFI_DRIVER dependencies

[Michael Zimmermann]

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.

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)?

Thanks for all your answers,
Michael

On Thu, May 18, 2017 at 7:21 AM, Andrew Fish <afish@apple.com> wrote:
>
>> On May 17, 2017, at 10:00 PM, Kinney, Michael D <michael.d.kinney@intel.com> 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:edk2-devel-bounces@lists.01.org] On Behalf Of Michael
>>> Zimmermann
>>> Sent: Wednesday, May 17, 2017 9:43 PM
>>> To: edk2-devel-01 <edk2-devel@lists.01.org>; Zeng, Star <star.zeng@intel.com>; Dong,
>>> Eric <eric.dong@intel.com>
>>> 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
>>> edk2-devel@lists.01.org
>>> https://lists.01.org/mailman/listinfo/edk2-devel
>> _______________________________________________
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
>

Re: UEFI_DRIVER dependencies

[Andrew Fish]

> On May 17, 2017, at 10:42 PM, Michael Zimmermann <sigmaepsilon92@gmail.com> 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 <afish@apple.com> wrote:
>> 
>>> On May 17, 2017, at 10:00 PM, Kinney, Michael D <michael.d.kinney@intel.com> 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:edk2-devel-bounces@lists.01.org] On Behalf Of Michael
>>>> Zimmermann
>>>> Sent: Wednesday, May 17, 2017 9:43 PM
>>>> To: edk2-devel-01 <edk2-devel@lists.01.org>; Zeng, Star <star.zeng@intel.com>; Dong,
>>>> Eric <eric.dong@intel.com>
>>>> 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
>>>> edk2-devel@lists.01.org
>>>> https://lists.01.org/mailman/listinfo/edk2-devel
>>> _______________________________________________
>>> edk2-devel mailing list
>>> edk2-devel@lists.01.org
>>> https://lists.01.org/mailman/listinfo/edk2-devel
>> 
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

Re: UEFI_DRIVER dependencies

[Andrew Fish]

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 <afish@apple.com> wrote:
> 
>> 
>> On May 17, 2017, at 10:42 PM, Michael Zimmermann <sigmaepsilon92@gmail.com <mailto:sigmaepsilon92@gmail.com>> 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 <afish@apple.com> wrote:
>>> 
>>>> On May 17, 2017, at 10:00 PM, Kinney, Michael D <michael.d.kinney@intel.com> 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:edk2-devel-bounces@lists.01.org] On Behalf Of Michael
>>>>> Zimmermann
>>>>> Sent: Wednesday, May 17, 2017 9:43 PM
>>>>> To: edk2-devel-01 <edk2-devel@lists.01.org>; Zeng, Star <star.zeng@intel.com>; Dong,
>>>>> Eric <eric.dong@intel.com>
>>>>> 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
>>>>> edk2-devel@lists.01.org
>>>>> https://lists.01.org/mailman/listinfo/edk2-devel
>>>> _______________________________________________
>>>> edk2-devel mailing list
>>>> edk2-devel@lists.01.org
>>>> https://lists.01.org/mailman/listinfo/edk2-devel
>>> 
>> _______________________________________________
>> edk2-devel mailing list
>> edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org>
>> https://lists.01.org/mailman/listinfo/edk2-devel <https://lists.01.org/mailman/listinfo/edk2-devel>
> 
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org>
> https://lists.01.org/mailman/listinfo/edk2-devel <https://lists.01.org/mailman/listinfo/edk2-devel>

Re: UEFI_DRIVER dependencies

[Michael Zimmermann]

Andrew, doesn't that only address the case where an UEFI_DRIVER has
dependencies on certain dxe drivers?(which, as you said will always be
available).
It's still unclear to me how an UEFI_DRIVER can depend on another
UEFI_DRIVER this way without relying on the fdf-order or using the device
binding mechanism.

My usecase is that I want to install a protocol from within a uefi driver
which then can be used by other uefi drivers. It's a pure protocol and thus
doesn't use the binding mechanism to bind to a device.

Thanks,
Michael

On Thu, May 18, 2017 at 8:16 AM, Andrew Fish <afish@apple.com> wrote:

> 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 <afish@apple.com> wrote:
>
>
> On May 17, 2017, at 10:42 PM, Michael Zimmermann <sigmaepsilon92@gmail.com>
> 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 <afish@apple.com> wrote:
>
>
> On May 17, 2017, at 10:00 PM, Kinney, Michael D <
> michael.d.kinney@intel.com> 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:edk2-devel-bounces@lists.01.org
> <edk2-devel-bounces@lists.01.org>] On Behalf Of Michael
> Zimmermann
> Sent: Wednesday, May 17, 2017 9:43 PM
> To: edk2-devel-01 <edk2-devel@lists.01.org>; Zeng, Star <
> star.zeng@intel.com>; Dong,
> Eric <eric.dong@intel.com>
> 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
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>
>
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>
>
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>
>
>

Re: UEFI_DRIVER dependencies

[Zeng, Star]

Does it work for you if using the protocol notification?

Thanks,
Star
From: Michael Zimmermann [mailto:sigmaepsilon92@gmail.com]
Sent: Thursday, May 18, 2017 2:25 PM
To: Andrew Fish <afish@apple.com>
Cc: Kinney, Michael D <michael.d.kinney@intel.com>; edk2-devel-01 <edk2-devel@lists.01.org>; Dong, Eric <eric.dong@intel.com>; Zeng, Star <star.zeng@intel.com>
Subject: Re: [edk2] UEFI_DRIVER dependencies

Andrew, doesn't that only address the case where an UEFI_DRIVER has dependencies on certain dxe drivers?(which, as you said will always be available).
It's still unclear to me how an UEFI_DRIVER can depend on another UEFI_DRIVER this way without relying on the fdf-order or using the device binding mechanism.

My usecase is that I want to install a protocol from within a uefi driver which then can be used by other uefi drivers. It's a pure protocol and thus doesn't use the binding mechanism to bind to a device.

Thanks,
Michael

On Thu, May 18, 2017 at 8:16 AM, Andrew Fish <afish@apple.com<mailto:afish@apple.com>> wrote:
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 <afish@apple.com<mailto:afish@apple.com>> wrote:


On May 17, 2017, at 10:42 PM, Michael Zimmermann <sigmaepsilon92@gmail.com<mailto:sigmaepsilon92@gmail.com>> 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 <afish@apple.com<mailto:afish@apple.com>> wrote:



On May 17, 2017, at 10:00 PM, Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>> 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:edk2-devel-bounces@lists.01.org] On Behalf Of Michael
Zimmermann
Sent: Wednesday, May 17, 2017 9:43 PM
To: edk2-devel-01 <edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>>; Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; Dong,
Eric <eric.dong@intel.com<mailto:eric.dong@intel.com>>
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
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
https://lists.01.org/mailman/listinfo/edk2-devel

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
https://lists.01.org/mailman/listinfo/edk2-devel

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
https://lists.01.org/mailman/listinfo/edk2-devel

Re: UEFI_DRIVER dependencies

[Andrew Fish]

> On May 17, 2017, at 11:25 PM, Michael Zimmermann <sigmaepsilon92@gmail.com> wrote:
> 
> Andrew, doesn't that only address the case where an UEFI_DRIVER has dependencies on certain dxe drivers?(which, as you said will always be available).
> It's still unclear to me how an UEFI_DRIVER can depend on another UEFI_DRIVER this way without relying on the fdf-order or using the device binding mechanism.
> 
> My usecase is that I want to install a protocol from within a uefi driver which then can be used by other uefi drivers. It's a pure protocol and thus doesn't use the binding mechanism to bind to a device.
> 

Micheal,

To get a little pedantic a UEFI driver could run on a system that did not support PI and thus no dispatcher. The early Itanium systems worked this way for example. 

So if you are really a UEFI driver then you have to gBS->RegisterProtocolNotify() to deal with sequence of protocols that don't follow the EFI Driver Model. 

If you want to have a DEPEX then you are really a DXE_DRIVER (UEFI + PI). I guess you could take a UEFI_DRIVER rename it a DXE_DRIVER and add my example Depex and it would work the same way as a UEFI_DRIVER. You could then add your extra Depex. 

Thanks,

Andrew Fish

> Thanks,
> Michael
> 
> On Thu, May 18, 2017 at 8:16 AM, Andrew Fish <afish@apple.com <mailto:afish@apple.com>> wrote:
> 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 <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 <afish@apple.com <mailto:afish@apple.com>> wrote:
>> 
>>> 
>>> On May 17, 2017, at 10:42 PM, Michael Zimmermann <sigmaepsilon92@gmail.com <mailto:sigmaepsilon92@gmail.com>> 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 <afish@apple.com <mailto:afish@apple.com>> wrote:
>>>> 
>>>>> On May 17, 2017, at 10:00 PM, Kinney, Michael D <michael.d.kinney@intel.com <mailto:michael.d.kinney@intel.com>> 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:edk2-devel-bounces@lists.01.org <mailto:edk2-devel-bounces@lists.01.org>] On Behalf Of Michael
>>>>>> Zimmermann
>>>>>> Sent: Wednesday, May 17, 2017 9:43 PM
>>>>>> To: edk2-devel-01 <edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org>>; Zeng, Star <star.zeng@intel.com <mailto:star.zeng@intel.com>>; Dong,
>>>>>> Eric <eric.dong@intel.com <mailto:eric.dong@intel.com>>
>>>>>> 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
>>>>>> edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org>
>>>>>> https://lists.01.org/mailman/listinfo/edk2-devel <https://lists.01.org/mailman/listinfo/edk2-devel>
>>>>> _______________________________________________
>>>>> edk2-devel mailing list
>>>>> edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org>
>>>>> https://lists.01.org/mailman/listinfo/edk2-devel <https://lists.01.org/mailman/listinfo/edk2-devel>
>>>> 
>>> _______________________________________________
>>> edk2-devel mailing list
>>> edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org>
>>> https://lists.01.org/mailman/listinfo/edk2-devel <https://lists.01.org/mailman/listinfo/edk2-devel>
>> 
>> _______________________________________________
>> edk2-devel mailing list
>> edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org>
>> https://lists.01.org/mailman/listinfo/edk2-devel <https://lists.01.org/mailman/listinfo/edk2-devel>
> 

Re: UEFI_DRIVER dependencies

[peter.kirmeier]

Hello,

just a short question here: Isn't the Supported() method of the Driver Binding Protocol the place where one have to check the availabilities and dependencies?
As long the dependencies are not fulfilled the respective error code is returned until some other driver's Start() installed the required protocols and the own Support() method can then return success (and actually get Start()ed) ?

Best Regards,
  Peter

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Andrew Fish
Sent: Thursday, May 18, 2017 8:33 AM
To: Michael Zimmermann
Cc: Mike Kinney; edk2-devel-01; Dong, Eric; Zeng, Star
Subject: Re: [edk2] UEFI_DRIVER dependencies


> On May 17, 2017, at 11:25 PM, Michael Zimmermann <sigmaepsilon92@gmail.com> wrote:
> 
> Andrew, doesn't that only address the case where an UEFI_DRIVER has dependencies on certain dxe drivers?(which, as you said will always be available).
> It's still unclear to me how an UEFI_DRIVER can depend on another UEFI_DRIVER this way without relying on the fdf-order or using the device binding mechanism.
> 
> My usecase is that I want to install a protocol from within a uefi driver which then can be used by other uefi drivers. It's a pure protocol and thus doesn't use the binding mechanism to bind to a device.
> 

Micheal,

To get a little pedantic a UEFI driver could run on a system that did not support PI and thus no dispatcher. The early Itanium systems worked this way for example. 

So if you are really a UEFI driver then you have to gBS->RegisterProtocolNotify() to deal with sequence of protocols that don't follow the EFI Driver Model. 

If you want to have a DEPEX then you are really a DXE_DRIVER (UEFI + PI). I guess you could take a UEFI_DRIVER rename it a DXE_DRIVER and add my example Depex and it would work the same way as a UEFI_DRIVER. You could then add your extra Depex. 

Thanks,

Andrew Fish

> Thanks,
> Michael
> 
> On Thu, May 18, 2017 at 8:16 AM, Andrew Fish <afish@apple.com <mailto:afish@apple.com>> wrote:
> 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/Dx
> eMain/DxeMain.c#L480 
> <https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/D
> xeMain/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 <afish@apple.com <mailto:afish@apple.com>> wrote:
>> 
>>> 
>>> On May 17, 2017, at 10:42 PM, Michael Zimmermann <sigmaepsilon92@gmail.com <mailto:sigmaepsilon92@gmail.com>> 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 <afish@apple.com <mailto:afish@apple.com>> wrote:
>>>> 
>>>>> On May 17, 2017, at 10:00 PM, Kinney, Michael D <michael.d.kinney@intel.com <mailto:michael.d.kinney@intel.com>> 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:edk2-devel-bounces@lists.01.org 
>>>>>> <mailto:edk2-devel-bounces@lists.01.org>] On Behalf Of Michael 
>>>>>> Zimmermann
>>>>>> Sent: Wednesday, May 17, 2017 9:43 PM
>>>>>> To: edk2-devel-01 <edk2-devel@lists.01.org 
>>>>>> <mailto:edk2-devel@lists.01.org>>; Zeng, Star 
>>>>>> <star.zeng@intel.com <mailto:star.zeng@intel.com>>; Dong, Eric 
>>>>>> <eric.dong@intel.com <mailto:eric.dong@intel.com>>
>>>>>> 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
>>>>>> edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org> 
>>>>>> https://lists.01.org/mailman/listinfo/edk2-devel 
>>>>>> <https://lists.01.org/mailman/listinfo/edk2-devel>
>>>>> _______________________________________________
>>>>> edk2-devel mailing list
>>>>> edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org> 
>>>>> https://lists.01.org/mailman/listinfo/edk2-devel 
>>>>> <https://lists.01.org/mailman/listinfo/edk2-devel>
>>>> 
>>> _______________________________________________
>>> edk2-devel mailing list
>>> edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org> 
>>> https://lists.01.org/mailman/listinfo/edk2-devel 
>>> <https://lists.01.org/mailman/listinfo/edk2-devel>
>> 
>> _______________________________________________
>> edk2-devel mailing list
>> edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org> 
>> https://lists.01.org/mailman/listinfo/edk2-devel 
>> <https://lists.01.org/mailman/listinfo/edk2-devel>
> 

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: UEFI_DRIVER dependencies

[Andrew Fish]

> On May 17, 2017, at 11:44 PM, peter.kirmeier@ts.fujitsu.com wrote:
> 
> Hello,
> 
> just a short question here: Isn't the Supported() method of the Driver Binding Protocol the place where one have to check the availabilities and dependencies?
> As long the dependencies are not fulfilled the respective error code is returned until some other driver's Start() installed the required protocols and the own Support() method can then return success (and actually get Start()ed) ?
> 

Peter,

You are correct. I think Michael's UEFI Drivers do more than an EFI Driver Model driver, and that is the issue. As Mike pointed out for EFI Driver Model drivers the load sequence does not matter as the 1st connect happens after all the initial driver dispatch has completed. If a new FV is discovered the BDS would need to try and do more connects. 

In a pure EFI Driver Model world the Start() function would optionally grab a protocol GET_PROTOCOL. I guess you could even gate the Start function on the existence of the protocol. 

The thing about the EFI Driver Model is it requires a protocol on handle to exist to do the 1st connect. Thus the parent handle is always produced by the DXE Driver. I have to admit I've written a UEF_DRIVER that installs a protocol, and then produces an EFI Driver Model driver (DriverBinding) that will later get connected on those handles. 

Thanks,

Andrew Fish

> Best Regards,
>  Peter
> 
> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Andrew Fish
> Sent: Thursday, May 18, 2017 8:33 AM
> To: Michael Zimmermann
> Cc: Mike Kinney; edk2-devel-01; Dong, Eric; Zeng, Star
> Subject: Re: [edk2] UEFI_DRIVER dependencies
> 
> 
>> On May 17, 2017, at 11:25 PM, Michael Zimmermann <sigmaepsilon92@gmail.com> wrote:
>> 
>> Andrew, doesn't that only address the case where an UEFI_DRIVER has dependencies on certain dxe drivers?(which, as you said will always be available).
>> It's still unclear to me how an UEFI_DRIVER can depend on another UEFI_DRIVER this way without relying on the fdf-order or using the device binding mechanism.
>> 
>> My usecase is that I want to install a protocol from within a uefi driver which then can be used by other uefi drivers. It's a pure protocol and thus doesn't use the binding mechanism to bind to a device.
>> 
> 
> Micheal,
> 
> To get a little pedantic a UEFI driver could run on a system that did not support PI and thus no dispatcher. The early Itanium systems worked this way for example. 
> 
> So if you are really a UEFI driver then you have to gBS->RegisterProtocolNotify() to deal with sequence of protocols that don't follow the EFI Driver Model. 
> 
> If you want to have a DEPEX then you are really a DXE_DRIVER (UEFI + PI). I guess you could take a UEFI_DRIVER rename it a DXE_DRIVER and add my example Depex and it would work the same way as a UEFI_DRIVER. You could then add your extra Depex. 
> 
> Thanks,
> 
> Andrew Fish
> 
>> Thanks,
>> Michael
>> 
>> On Thu, May 18, 2017 at 8:16 AM, Andrew Fish <afish@apple.com <mailto:afish@apple.com>> wrote:
>> 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/Dx
>> eMain/DxeMain.c#L480 
>> <https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/D
>> xeMain/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 <afish@apple.com <mailto:afish@apple.com>> wrote:
>>> 
>>>> 
>>>> On May 17, 2017, at 10:42 PM, Michael Zimmermann <sigmaepsilon92@gmail.com <mailto:sigmaepsilon92@gmail.com>> 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 <afish@apple.com <mailto:afish@apple.com>> wrote:
>>>>> 
>>>>>> On May 17, 2017, at 10:00 PM, Kinney, Michael D <michael.d.kinney@intel.com <mailto:michael.d.kinney@intel.com>> 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:edk2-devel-bounces@lists.01.org 
>>>>>>> <mailto:edk2-devel-bounces@lists.01.org>] On Behalf Of Michael 
>>>>>>> Zimmermann
>>>>>>> Sent: Wednesday, May 17, 2017 9:43 PM
>>>>>>> To: edk2-devel-01 <edk2-devel@lists.01.org 
>>>>>>> <mailto:edk2-devel@lists.01.org>>; Zeng, Star 
>>>>>>> <star.zeng@intel.com <mailto:star.zeng@intel.com>>; Dong, Eric 
>>>>>>> <eric.dong@intel.com <mailto:eric.dong@intel.com>>
>>>>>>> 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
>>>>>>> edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org> 
>>>>>>> https://lists.01.org/mailman/listinfo/edk2-devel 
>>>>>>> <https://lists.01.org/mailman/listinfo/edk2-devel>
>>>>>> _______________________________________________
>>>>>> edk2-devel mailing list
>>>>>> edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org> 
>>>>>> https://lists.01.org/mailman/listinfo/edk2-devel 
>>>>>> <https://lists.01.org/mailman/listinfo/edk2-devel>
>>>>> 
>>>> _______________________________________________
>>>> edk2-devel mailing list
>>>> edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org> 
>>>> https://lists.01.org/mailman/listinfo/edk2-devel 
>>>> <https://lists.01.org/mailman/listinfo/edk2-devel>
>>> 
>>> _______________________________________________
>>> edk2-devel mailing list
>>> edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org> 
>>> https://lists.01.org/mailman/listinfo/edk2-devel 
>>> <https://lists.01.org/mailman/listinfo/edk2-devel>
>> 
> 
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

Re: UEFI_DRIVER dependencies

[Laszlo Ersek]

On 05/18/17 08:25, Michael Zimmermann wrote:
> Andrew, doesn't that only address the case where an UEFI_DRIVER has
> dependencies on certain dxe drivers?(which, as you said will always be
> available).
> It's still unclear to me how an UEFI_DRIVER can depend on another
> UEFI_DRIVER this way without relying on the fdf-order or using the device
> binding mechanism.
> 
> My usecase is that I want to install a protocol from within a uefi driver
> which then can be used by other uefi drivers. It's a pure protocol and thus
> doesn't use the binding mechanism to bind to a device.

I don't see why this should be a problem.

Your first driver should be a DXE driver (a platform driver) that
allocates a handle in its entry point function, installing the protocol
instance in question on it. Optionally, consider installing a device
path proto instalce on it as well, most likely with a single VenHw()
node (into which you can put any kind of administrative data you like,
just make sure you grab a fresh vendor GUID with uuidgen).

In turn, your second driver can be a UEFI driver that conforms to the
UEFI driver model. In the Supported() member of the driver binding
protocol, check for the presence of your custom protocol on the handle.
In ths Start() member, open the protocol "by driver".

In this case, the first driver exposes the protocol immediately at
dispatch, and the second driver consumes the protocol when its
Supported() and Start() members are called from within BDS.

We use the above method in practice for virtio-mmio, on ARM / AARCH64:

- ArmVirtPkg/VirtioFdtDxe is a platform driver that produces instances
  of the VIRTIO_DEVICE_PROTOCOL, using VirtioMmioDeviceLib. It is a DXE
  driver.
- In turn, all of the virtio device drivers consume
  VIRTIO_DEVICE_PROTOCOL.

Virtio-pci looks different. For that, we have VirtioPciDeviceDxe (for
legacy virtio) and Virtio10Dxe (for modern-only virtio). Both are UEFI
drivers themselves (operating on PCI IO protocol instances) and both
produce one VIRTIO_DEVICE_PROTOCOL instance per one PCI B/D/F bound. The
virtio device drivers are none the wiser about the actual virtio transport.


If your first driver *must* be a UEFI driver as well (for whatever
reason) that *also* conforms to the UEFI driver model (for whatever
reason), then in that driver, do two things in the enty point function:

(1) install the driver binding protocol instance that you produce
anyway, for UEFI driver model conformance,

(2) *also* do what I described above, for the DXE driver's entry point
function.

This way, when BDS calls into your second UEFI driver, for binding a
handle, the second driver will find the (singleton) protocol instance in
the protocol database, installed by the first driver's entry point
function at dispatch, *even if* the first UEFI driver hasn't bound any
handles yet.

Thanks
Laszlo