Hi Thomas, I have been looking into this topic of multiple controllers this week. I have some prototype code that I think resolves the issues but needs a bit more work on some corner cases.
I am using the PCI Option ROM use case to evaluate the changes. PCI Option ROM can use Bus Specific Driver Override Protocol so the driver from the option ROM manages the PCI controller the option ROM is attached. PCI Option ROMs can also use the Driver Family Override Protocol so one of the PCI Option ROMs can manage a group of PCI controllers. It is also possible for an FMP driver for integrated devices to manage multiple integrated devices if there is more than one of the same device with FW storage. The multiple controller use case is not limited to busses like PCI. The current version of the FmpDeviceLib is optimized for an FMP instance that manages a single FW storage device. If an FmpDeviceLib is intended to manage multiple FW storage devices, then a few extra services in the FmpDeviceLib are required. The concept is to extend the FmpDeviceLib with a couple extra APIs that add support for Stop()/Unload() operations and to to set the context for the current FmpDeviceLib actions. Have you entered a BZ for this issue yet? I can start adding details in the BZ and post some proposed changes soon. Best regards, Mike > -----Original Message----- > From: edk2-devel [mailto:edk2-devel- > boun...@lists.01.org] On Behalf Of Andrew Fish via > edk2-devel > Sent: Friday, February 8, 2019 9:16 AM > To: Tomas Pilar (tpilar) <tpi...@solarflare.com> > Cc: edk2-devel@lists.01.org > Subject: Re: [edk2] Self-replicating image > > > > > On Feb 8, 2019, at 6:42 AM, Tomas Pilar (tpilar) > <tpi...@solarflare.com> wrote: > > > > Hi, > > > > I am currently pondering the most elegant way to > implement capsule update for our devices that would > work in the presence of multiple devices in the host. > > > > Capsule allows embedding a driver that is executed > prior to the update, which is very handy. Crypto > library is quite large and would not fit into an > OptionROM, so being able to supply FMP driver in the > capsule is great. > > > > However, if only one instance of the driver loads, > the FMP upstream is currently written to support only > one device per instance. So I wonder if there is a > easy, neat way for my image to replicate on > DriverBinding so that I end up with one instance per > device. > > > > > Tom, > > The usually model in EFI is to have one driver handle > multiple things. > > > It looks like I should be able to do it with gBS- > >LoadImage() and passing information about currently > loaded image though I might have to CopyMem() the image > itself to new location. > > > > gBS->LoadImage() will load and relocate the image to a > malloced address of the correct memory type for the > image. The inputs are just the source of the image, so > no need to CopyMem() anything. gBS->StartImage() calls > the entry point. > > Thanks, > > Andrew Fish > > > Thoughts? > > > > Cheers, > > Tom > > _______________________________________________ > > edk2-devel mailing list > > edk2-devel@lists.01.org > > https://lists.01.org/mailman/listinfo/edk2-devel > > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
