Hi Tomas, I have posted a branch in edk2-staging with the proposed design changes to support multiple controller and a functional example in OVMF using multiple E1000 adapters.
https://github.com/tianocore/edk2-staging/tree/Bug_1525_FmpDevicePkg_MultipleControllers QEMU has a few limitations, so some aspects are simulated, but you should be able to use the example as a template to try your use case. The E1000 UEFI PCI device driver that uses FmpDxe as a Library is located at the following location. OvmfPkg/E1000Fmp It uses the E1000 specific FmpDeviceLib instance at: OvmfPkg/Feature/Capsule/Library/FmpDeviceLibE1000 I have added device specific DSC files for each FMP driver that are included from the OVMF DSC file. The one for E1000 is at: OvmfPkg/Feature/Capsule/FmpE1000.dsc QEMU does not support update of the PCI Option ROM mapped to a PCI device. So I simulate the update of a FW storage device using a 32-byte UEFI Variable that is unique for each adapter. Best regards, Mike > -----Original Message----- > From: Tomas Pilar (tpilar) > [mailto:tpi...@solarflare.com] > Sent: Monday, February 11, 2019 2:37 AM > To: Kinney, Michael D <michael.d.kin...@intel.com>; > Andrew Fish <af...@apple.com>; edk2-devel@lists.01.org > Subject: Re: [edk2] Self-replicating image > > Hi Mike, > > Sorry to say I have not yet filed a BZ. Would you like > me to, or are you happy doing it? > > Cheers, > Tom > > On 08/02/2019 17:59, Kinney, Michael D wrote: > > 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
