Re: Self-replicating image

["Kinney, Michael D" <michael.d.kinney@intel.com>]

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-
> bounces@lists.01.org] On Behalf Of Andrew Fish via
> edk2-devel
> Sent: Friday, February 8, 2019 9:16 AM
> To: Tomas Pilar (tpilar) <tpilar@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)
> <tpilar@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