UEFI Drivers that produce the Driver Binding Protocol do not use DEPEX to
determine the order that drivers attempt to manage controllers. A UEFI Driver
installs the Driver Binding Protocol in its entry point. The Driver Binding
Protocol Supported()/Start() are not called from the entry point. Instead they
are called from ConnectController() when BDS attempts to connect console and
boot devices. The precedence rules used by ConnectController() from highest to
lowest precedence are as follows:
1. Context Override
2. Platform Driver Override
3. Driver Family Override
4. Bus Specific Driver Override
5. Driver Binding Search
For the video drivers in OVMF, Context Override does not apply (it is a feature
for development/debug that is used by the EFI/UEFI shell connect command).
Platform Driver Override is possible, but requires an extra platform module.
Driver Family Override is intended to be used when multiple adapters in the
same adapter family are present in a platform, which does apply to the single
video controller for QEMU. Bus Specific Driver Override applies to PCI Option
ROMs associated with a PCI Controller, which usually applies to PCI add-in
devices, not integrated PCI devices like the one for QEMU video. So this
leaves Driver Binding Search as the easies method to control the order that the
Supported()/Start() calls are used for QEMU video drivers.
Driver Binding Search :
===================
The list of available driver image handles can be found by using the
boot service LocateHandle() with a SearchType of ByProtocol for the GUID of the
EFI_DRIVER_BINDING_PROTOCOL. From this list, the image handles found in rules
(1),
(2), (3), and (4) above are removed. The remaining image handles are sorted
from highest to
lowest based on the Version field of the EFI_DRIVER_BINDING_PROTOCOL instance
associated with each image handle.
Driver Binding Version
===================
The version number of the UEFI driver that produced the
EFI_DRIVER_BINDING_PROTOCOL. This field is used by the EFI boot service
ConnectController() to determine the order that driver's Supported() service
will be used when a controller needs to be started. EFI Driver Binding
Protocol instances with higher Version values will be used before ones with
lower Version values. The Version values of 0x0-0x0f and 0xfffffff0-0xffffffff
are reserved for platform/OEM specific drivers. The Version values
of 0x10-0xffffffef are reserved for IHV-developed drivers.
If both video drivers are in a firmware image, then the one you prefer to
connect should have a higher Version field value.
Best regards,
Mike
-----Original Message-----
From: El-Haj-Mahmoud, Samer [mailto:[email protected]]
Sent: Sunday, February 10, 2013 7:20 AM
To: Laszlo Ersek
Cc: [email protected]; David Woodhouse; Andrew
Subject: Re: [edk2] [PATCH] OvmfPkg: Don't build in QemuVideoDxe when we have
CSM
If you carry your UEFI drivers in a Firmware Volume, you can use Depex around
them. The DXE dispatcher will resolve the DepEx and load the UEFI driver
image, just like it does for DXE drivers. The Connect sequence later on in BDS
will cause your loaded drivers to bind to devices (by calling Start() ). Look
at the DSC spec for examples on adding a depex section.
Tag protocols are used to trigger events or depex on their installation. They
usually do not have any member functions or variables in the protocol calling
API; you just need the GUID.
DriverOrder would work, but what if some external entity modify the value (or
even delete the variables)?
Laszlo Ersek <[email protected]> wrote:
Hello Samer,
On 02/10/13 06:27, El-Haj-Mahmoud, Samer wrote:
> You could use DXE dependency expressions (on a tag protocol) around
> the drivers in your firmware volume. This way, you can control which
> driver gets dispatched depending on whether that protocol is
> installed or not. You can then have a configuration option to control
> the installation of that tag protocol.
DepExes did cross my mind (although not with reference to tag protocols
-- I don't know what those are). But aren't DepExes meant for "early DXE
phase drivers" only (ie. MODULE_TYPE=DXE_DRIVER)? I got that impression
from the tutorial (screenshots attached).
The drivers in question are MODULE_TYPE=UEFI_DRIVER; rather than
producing architectural protocols, they are needed to boot the OS.
BdsEntry() [IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c]
BdsLibLoadDrivers() [IntelFrameworkModulePkg/Library/GenericBdsLib/BdsMisc.c]
PlatformBdsPolicyBehavior() [OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c]
- connects various devices
DriverOrder and Driver#### should steer BdsLibLoadDrivers() before the
OVMF specific BDS policy connects / installs a driver (any driver) for
the VGA card. I figured driver load order would influence which of the
two GOPs is installed first.
Thanks!
Laszlo
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
