On 08/07/14 03:22, Andrew Fish wrote:
>
> On Aug 6, 2014, at 6:04 PM, Chris Cuthbert <nd6...@hotmail.com
> <mailto:nd6...@hotmail.com>> wrote:
>
>> Hi Laszlo,
>> The ethernet device has a pci-pci bridge between itself and the root
>> bridge. Hence the weird looking device path.
>>
>
> The PCI nodes are Dev/Func as the bus #’s can change from boot to boot.
>
>> I poked around some more and saw that MNP DXE driver could not open
>> SNP protocol on any of the handles passed to it and hence it does not
>> bind. It seems odd that "dh" command sees the SNP but MNP does not.
>>
>
> dh is a handle dump. So it shows all the handles. Not really the
> relationship between the handles. devtree and drivers shows more about
> that.
I didn't know about devtree. It's very useful, thanks!
>> How does UEFI handle the dependency between drivers ?
>
> So EFI Driver Model drivers use the driver binding protocol. These
> drivers just register the driver binding protocol in their entry point.
> The platform connects drivers based on policy. The platform will use
> gBS->ConnectController()
>
> This is under ConnectController() in the Boot Services chapter of UEFI
> 2.4 spec:
>
> This functions uses five precedence rules when deciding the order that
> drivers are tested against controllers. These five rules from highest
> precedence to lowest precedence are as follows:
> 1. Context Override : DriverImageHandle is an ordered list of handles
> that support the EFI_DRIVER_BINDING_PROTOCOL. The highest priority image
> handle is the first element of the list, and the lowest priority image
> handle is the last element of the list. The list is terminated with a
> NULL image handle.
> 2. Platform Driver Override : If an
> EFI_PLATFORM_DRIVER_OVERRIDE_PROTOCOL instance is present in the system,
> then the GetDriver() service of this protocol is used to retrieve an
> ordered list of image handles for ControllerHandle. From this list, the
> image handles found in rule (1) above are removed. The first image
> handle returned from GetDriver() has the highest precedence, and the
> last image handle returned from GetDriver() has the lowest precedence.
> The ordered list is terminated when GetDriver() returns EFI_NOT_FOUND.
> It is legal for no image handles to be returned by GetDriver(). There
> can be at most a single instance in the system of the
> EFI_PLATFORM_DRIVER_OVERRIDE_PROTOCOL. If there is more than one, then
> the system behavior is not deterministic.
> 3. Driver Family Override 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_FAMILY_OVERRIDE_PROTOCOL. From this list, the image handles
> found in rules (1), and (2) above are removed. The remaining image
> handles are sorted from highest to lowest based on the value returned
> from the GetVersion() function of the
> EFI_DRIVER_FAMILY_OVERRIDE_PROTOCOL associated with each image handle.
> 4. Bus Specific Driver Override : If there is an instance of the
> EFI_BUS_SPECIFIC_DRIVER_OVERRIDE_PROTOCOL attached to ControllerHandle,
> then the GetDriver() service of this protocol is used to retrieve an
> ordered list of image handle for ControllerHandle. From this list, the
> image handles found in rules (1), (2), and (3) above are removed. The
> first image handle returned from GetDriver() has the highest precedence,
> and the last image handle returned from GetDriver() has the lowest
> precedence. The ordered list is terminated when GetDriver() returns
> EFI_NOT_FOUND. It is legal for no image handles to be returned by
> GetDriver().
> 5. 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.
> Services — Boot Services
> 
>
>> What if MNP driver binding protocol runs first and does not find SNP
>> because the SNP driver binding protocol has no run yet ?
>>
>
> You can mess around with the disconnect/connect shell commands, as they
> use 1) above and should let you debug what is going on.
Thank you Andrew for explaining it, I secretly wished you'd chime in :)
(
So yes, the one thing I could think of too was that Chris's BDS code was maybe
not calling ConnectController().
Chris, in OVMF it looks like (soon calling into IntelFrameworkModulePkg):
PlatformBdsPolicyBehavior() [OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c]
BdsLibConnectAll()
[IntelFrameworkModulePkg/Library/GenericBdsLib/BdsConnect.c]
BdsLibConnectAllDriversToAllControllers()
BdsLibConnectAllEfi()
gBS->ConnectController(..., recursive=true)
CoreConnectController() [MdeModulePkg/Core/Dxe/Hand/DriverSupport.c] implements
gBS->ConnectController().
There are important loops in the last three functions.
In ARM BDS there's a similar function: BdsConnectAllDrivers()
[ArmPkg/Library/BdsLib/BdsHelper.c].
As Andrew said, you should experiment with the connect shell command,
especially the -r (recursive) option.
)
Thanks,
Laszlo
------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
