Hi,
We also implement capsules to update optionROMs that use an
embedded driver in the capsule. The main reason for us is space -
crypto library is too large to fit into our flash so we don't
provide fully functional FMP in the optionROM driver, only a stub
FMP that is enough to populate the ESRT.
The spec requires that the embedded driver is loaded by the
platform. I would also _expect_ that the platform will try to bind
the driver against all devices in the platform using the
DriverBinding protocol - this is quite a necessary step for using
a driver!
I wouldn't expect the platform to unbind the old driver from the
device for me, in fact it should not assume it knows the right
thing to do here. I implemented this unbinding internally: when my
embedded driver loads, it will unbind all (my) existing drivers
during the EntryPoint execution. That leaves the controllers free
to be bound against using the embedded driver.
In fact, if your IHV is writing drivers that are supposed to work
in general on other platforms as well, they better not rely on
this kind of special behaviour!
Caveats:
This does potentially cause a problem if existing drivers are very old and buggy and crash the platform during unbinding. It will also leave the controller without a proper driver following the update. This is okay since we expect the platform to reboot following an FMP update.
Cheers,
Tom
P.S. If you put me in contact with your IHV I can explain how I implemented the unbinding on our end.
Hi,
I have searched EDK2 devel discussion and Mantis but I couldn't find answer.
Recently we found some PCI card vendor release capsule to update device firmware.
Background:
The PCI card has option ROM which provide FMP service.
The capsule has a firmware payload and device driver which also provide FMP.
Problem:
The vendor put option ROM device driver into capsule, the only differences is it is newer version.
The FMP in old PCI option ROM is not functional.
Thus they put a new device driver in capsule, and expect UEFI to disconnect the old option ROM driver, and connect the new one from capsule.
This is different to current EDK2 implementation. UEFI spec 2.8 CH 23.3.3 define process to handle capsule and embedded driver, it will call embedded driver's entry point, but won't connect anything.
Our PCI card vendor is asking to disconnect old option ROM driver, and connect new driver from capsule.
It makes sense for device vendor to simply provide a device driver in capsule.
Any advice? Do you think it make sense to disconnect PCI option ROM driver and reconnect capsule driver?
Thanks,
Derek