1. The PCIR data structure contain 2 byte pointer to device id table and
the device id table is a list containing device ids which your ROM can
support.device id is a 2 byte field that's why each entry in device id
table is 2 byte wide
2 UEFI driver model, when your driver is called in "driver binding
supported" context, you can return TRUE based on device id check ( from
passed controller handle and supported controller device id),
Neeraj
On Wed, Jul 8, 2015 at 9:13 AM, Andrew Fish <af...@apple.com> wrote:
>
> > On Jul 8, 2015, at 7:42 AM, Anindya Rai <rai.anin...@gmail.com> wrote:
> >
> > Hi
> >
> > I am developing a UEFI Option ROM. I want to use the same binary with
> different devices (different device ID). When I checked the PCI data
> structure, there is a field for 'device list pointer' which can be used to
> give a list of supported device ID.
> > I think this field cannot be used for UEFI Option ROM as this field is
> only 2 bytes in size whereas the size of a pointer in UEFI environment is
> more than that.
> >
> > I also checked the EFIROM utility but couldn't find anything where we
> can mention a list of supported device IDs.
> > Is there a way to achieve this?
> >
>
> It is explained in the UEFI spec under the UEFI Driver Model chapter. It
> is mostly done via the EFI_DRIVER_BINDING_PROTOCOL.
>
> Also the text under the ConnectController() Boot Service explains the
> precedence rules for connecting a driver:
> 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.
>
> Thanks,
>
> Andrew Fish
>
>
>
> > --
> > Thanks and Regards:
> > Anindya Rai
> >
> >
> ------------------------------------------------------------------------------
> > Don't Limit Your Business. Reach for the Cloud.
> > GigeNET's Cloud Solutions provide you with the tools and support that
> > you need to offload your IT needs and focus on growing your business.
> > Configured For All Businesses. Start Your Cloud Today.
> >
> https://www.gigenetcloud.com/_______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
>
> ------------------------------------------------------------------------------
> Don't Limit Your Business. Reach for the Cloud.
> GigeNET's Cloud Solutions provide you with the tools and support that
> you need to offload your IT needs and focus on growing your business.
> Configured For All Businesses. Start Your Cloud Today.
> https://www.gigenetcloud.com/
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
--
Thanks
Neeraj
------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
