Hi Andrew, Thanks for the details. Couple of years back I had this discussion (not sure here or in USWG) however I couldn’t find any possible solution for my use case, that is the reason I followed the approach I have mentioned in the earlier e-mail. My use case is a system has two storage controllers (both with same PCI devID), one having a couple of boot devices attached with it and the other having 100s of data disks attached with that. I don’t want the UEFI driver supporting the second controller, so I erased the driver from flash but the system BIOS dispatches the second controller to the driver loaded from first controller (mostly on different driver instance) and the driver start managing both the controllers and results in unnecessary boot time increase. I was not able to find a solution with Driver family override protocol, Could you please let me know if you have another thought.
If both the controllers has OptionROM flashed on it then driver family override protocol will be helpful to decide the priority among them but couldn’t see how to use it in the case I mentioned above. Thanks Sathya PS: My E-mail ID changed from [email protected] to [email protected]. Please update your address book. -----Original Message----- From: Andrew Fish [mailto:[email protected]] Sent: Friday, December 05, 2014 12:35 PM To: [email protected] Subject: Re: [edk2] DevicePath for the Boot Services Driver flashed on the Controller Flash. > On Dec 5, 2014, at 11:20 AM, Sathya Prakash <[email protected]> > wrote: > > Andrew, > Thanks for the suggestion. > > In my boot services driver, I made a restriction of one-to-one > association between controller and driver, to accomplish that, if the > driver is loaded from non media devicepath, then I check RomSize to > determine whether driver is loaded from the card which got dispatched > to the driver, if RomSize is 0 then I assume the card doesn’t have a > driver flashed in it and return failure for binding.support. > If the driver is loaded from media (for the case of no driver flashed > in the card but the user loads it from shell for some test purpose) > then I always allow the first controller dispatched to it, so that > multiple loads from shell can manage multiple controllers. > It is bad for your driver to do this. In UEFI the policy of what driver to load is well defined, and controlled by the platform. In the legacy BIOS world we got lots of feedback from option ROM vendors that they had to add a lot of workarounds for specific BIOS vendors, and some OEMs. Some bigger OEMs required the option ROM vendor to make custom ROMs. When we talked to the BIOS venders and OEMs we found out that they had to add workarounds for specific option ROMs that “did strange stuff”. Given this circular complexity we decided the right answer for EFI was to push the policy into the platform and make the ROM as simple as possible. The definition of ConnectController() in the UEFI spec defines the precedence rules for which driver will get started for a controller. UEFI 2.4 6.3 ConnectController() 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. So I would expect the generic case when you load from ROM the Bus Specific Driver override would give the driver from the ROM precedence. When you load from the shell, the shell command is using the context override so you can force it to do what ever you want. If you really really need to do something in the driver you should use the EFI_DRIVER_FAMILY_OVERRIDE_PROTOCOL. Thanks, Andrew Fish > Recently I see that got broke with certain system BIOS and when I root > cause why always the first controller is managed by the driver, I > found out about the devicepath change. > > Thanks > Sathya > > From: Andrew Fish [mailto:[email protected]] > Sent: Friday, December 05, 2014 10:10 AM > To: [email protected] > Subject: Re: [edk2] DevicePath for the Boot Services Driver flashed on > the Controller Flash. > > > On Dec 5, 2014, at 7:18 AM, Sathya Prakash > <[email protected]> > wrote: > > I have a boot services driver programmed on the flash of our add-on > controller, when the BSD gets executed from flash, I am trying to > identify form where it is loaded (from flash/shell) and for that I > have used the below condition and if it is met, > > Why do you need to know? > > > I assume it is loaded from Shell, if not I assume it loaded from > Flash. Is there anything wrong in that, in certain system BIOS > implementation even for drivers loaded from flash, the devicepath is > set as FILEPATH. Any help on this? > > > The edk2 PCI Bus driver does this. > > > https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdeModulePkg/Bus/Pci/Pc > iBus > Dxe/PciOptionRomSupport.c > > // > // Create Pci Option Rom Image device path header > // > EfiOpRomImageNode.Header.Type = MEDIA_DEVICE_PATH; > EfiOpRomImageNode.Header.SubType = MEDIA_RELATIVE_OFFSET_RANGE_DP; > SetDevicePathNodeLength (&EfiOpRomImageNode.Header, sizeof > (EfiOpRomImageNode)); > EfiOpRomImageNode.StartingOffset = (UINTN) RomBarOffset - (UINTN) > RomBar; > EfiOpRomImageNode.EndingOffset = (UINTN) RomBarOffset + ImageSize - > 1 - (UINTN) RomBar; > > PciOptionRomImageDevicePath = AppendDevicePathNode > (PciDevice->DevicePath, &EfiOpRomImageNode.Header); > ASSERT (PciOptionRomImageDevicePath != NULL); > > // > // load image and start image > // > BufferSize = 0; > Buffer = NULL; > ImageHandle = NULL; > > Status = gBS->LoadImage ( > FALSE, > gPciBusDriverBinding.DriverBindingHandle, > PciOptionRomImageDevicePath, > Buffer, > BufferSize, > &ImageHandle > ); > > FreePool (PciOptionRomImageDevicePath); > > If it is loaded from the ROM there is going to be a node in the device > path (likely 2nd to last) that contains PCI_DEVICE_PATH. You could > always look for that. > > > In the Example below PciDevice->DevicePath is going to be the same > device path that has the PCI IO protocol sitting on it. You should be > able to dump it from the shell. > > > Thanks, > > > Andrew Fish > > > > > DevicePathType(LoadedImage->FilePath) == MEDIA_FILEPATH_DP > > > Thanks > Sathya > > ---------------------------------------------------------------------- > ---- > ---- > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from > Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & > more Get technology previously reserved for billion-dollar > corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg. > clkt > rk > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/edk2-devel > > ---------------------------------------------------------------------- > -------- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT > Server from Actuate! Instantly Supercharge Your Business Reports and > Dashboards with Interactivity, Sharing, Native Excel Exports, App > Integration & more Get technology previously reserved for > billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg. > clktrk _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
