> On Dec 5, 2014, at 1:02 PM, Sathya Prakash <[email protected]> > wrote: > > 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. >
Usually this class of problems is fixed by the platform only connecting devices needed to boot in the BDS. Thanks, Andrew Fish > 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 ------------------------------------------------------------------------------ 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
