[edk2] How to use same UEFI Option ROM binary for devices with different device ID?

Discussion:

Anindya Rai

2015-07-08 14:42:33 UTC

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?

--
Thanks and Regards:
Anindya Rai

Andrew Fish

2015-07-08 16:13:35 UTC

Permalink

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

--
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
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Neeraj Ladkani

2015-07-08 17:11:32 UTC

Permalink

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

Post by Anindya Rai

Post by Anindya Rai
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.

Post by Anindya Rai
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.

Post by Anindya Rai
I also checked the EFIROM utility but couldn't find anything where we

can mention a list of supported device IDs.

Post by Anindya Rai
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
This functions uses five precedence rules when deciding the order that
drivers are tested against controllers. These five rules from highest
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

Post by Anindya Rai
--
Anindya Rai

------------------------------------------------------------------------------

Post by 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/_______________________________________________

Post by Anindya Rai
edk2-devel mailing list
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
https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
Thanks
Neeraj