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.
On 08/08/2019 09:27, Lin, Derek (HPS SW) wrote:
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
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#45264): https://edk2.groups.io/g/devel/message/45264
Mute This Topic: https://groups.io/mt/32796488/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
