Thanks for the replies Mike and Andrew. I was on vacation so couldn't respond earlier.
I am trying to explain my requirement more in detail here Let me assume we have two controllers C1 and C2. In Controller C1 there is a particular version of firmware and a particular version of UEFI Boot Service Driver is flashed. In C2 there is only a firmware (this version is very old and couldn't be properly supported by BSD flashed in C1). So when the BSD loaded from C1 it should not try to manage C2. In essence I want to make sure the following 1. If a driver is loaded from flash part of controller X then it should manage only controller X. 2. If a driver is loaded from shell (for debug purpose) it should manage only one controller (the first controller dispatched to it). I am trying to find out a way to achieve 1 & 2. Thanks Sathya From: Andrew Fish [mailto:af...@apple.com] Sent: Wednesday, December 19, 2012 6:37 PM To: edk2-devel@lists.sourceforge.net Subject: Re: [edk2] How to impose 1 to 1 mapping between driver and controller Mike, Maybe I don't understand Sathya's question. I thought we was trying to prevent any UEFI driver from binding with c2. The Bus Specific Driver Override rules, just bumps the priority of the search, but the search still happens. So a driver would match. 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. Sathy, What do you want to happen on c2? Andrew Fish On Dec 19, 2012, at 4:34 PM, "Kinney, Michael D" <michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>> wrote: Sathya, By default for PCI Adapters, the driver from the option ROM associated with a PCI Controller will be tried first using the Bus Specific Driver Override rule. The details on all the rules that determine the order that Driver Binding Supported() is tried on a specific controller are described in the UEFI Specification in the description of the UEFI Boot Service ConnectController(). Your use case is also covered in an example in the UEFI Driver Writer's Guide in section 3.14.2. It is available from the following page: http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Driver_Developer Best regards, Mike From: Andrew Fish [mailto:af...@apple.com<http://apple.com>] Sent: Wednesday, December 19, 2012 4:03 PM To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net> Subject: Re: [edk2] How to impose 1 to 1 mapping between driver and controller The EFI_PCI_IO_PROTOCOL contains a pointer to the RomImage that was filled in by the PCI bus driver. There is also an attribute bit that lets you know if the ROM cam from the system or the PCI Card. So your could check the EFI_PCI_IO_PROTOCOL.RomImage to make sure you are running on the card the ROM came from. Andrew Fish On Dec 19, 2012, at 3:32 PM, "Prakash, Sathya" <sathya.prak...@lsi.com<mailto:sathya.prak...@lsi.com>> wrote: Folks, Let us assume a case where there are two I/O controllers present in the system with only one controller (c1) having a UEFI Boot Service Driver programmed in its flash part and the other one (c2) doesn't have the BSD in flash. Both are having same PCI IDs. I want to ensure in my driver binding's supported or start routines to make sure the driver manages only the controller from where it loads and not the other controller. Can it is doable? Thanks Sathya ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d_______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d_______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------ Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612
_______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
