Hi Andrew, Laszlo,
The output from the 'devices' shell command is:
7B D - - 1 0 0 PciRoot(0x2)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(121212121212,0x1)
And the output from 'disconnect' and 'reconnect' shell command is:
Shell> disconnect 7b
Disconnect - (7B,7A9E39E4,7A9E393C) Result Success.
Shell> reconnect 7b
Disconnect - (7B,7A9D3AA8,7AAA5BD0) Result Success.
MnpDriverBindingSupported:0x7F338518 YES
What this is showing me is that on 'reconnect', the MNP driver does find a SNP
protocol handle implemented by device handle 0x7B. Unfortunately my system
crashes at this point indicating that my driver is not unloading/loading
properly, I will have to work on that.
I am trying to avoid turning this email chain into a UEFI tutorial but I did
not quiet understand what you are trying to convey.
My driver is implementing UEFI driver model and at some point in time
"Supported" function is called with a PCIe device handle. Driver figures out
which device it supports and that causes the "Start" function to be called with
that handle. In "Start" function I initialize the PCIe device and the driver
data structures.
As part of "Start" function driver registers a protocol that it is producing.
Now, how does the UEFI "ConnectController" manage to connect the MNP driver to
my driver ?
The "ConnectController" is for connecting devices to drivers. How are the
service drivers connected to devices providing the services ?
Thanx.
> Date: Thu, 7 Aug 2014 11:29:41 +0200
> From: ler...@redhat.com
> To: edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] UEFI Shell Command "ifconfig" Error
>
> 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
------------------------------------------------------------------------------
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
