From: "Tomas Pilar (tpilar)" <tpilar@solarflare.com>
To: <devel@edk2.groups.io>, <derek.lin2@hpe.com>
Subject: Re: [edk2-devel] Capsule PCI device firmware update, could capsule embedded driver override PCI option ROM driver?
Date: Fri, 9 Aug 2019 12:13:04 +0100 [thread overview]
Message-ID: <0e90b966-93a9-7bca-5247-5191642a7823@solarflare.com> (raw)
In-Reply-To: <10206.1565252824023648157@groups.io>
[-- Attachment #1: Type: text/plain, Size: 2766 bytes --]
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
>
[-- Attachment #2: Type: text/html, Size: 3668 bytes --]
prev parent reply other threads:[~2019-08-09 11:13 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-08 8:27 Capsule PCI device firmware update, could capsule embedded driver override PCI option ROM driver? Lin, Derek (HPS SW)
2019-08-09 11:13 ` Tomas Pilar (tpilar) [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0e90b966-93a9-7bca-5247-5191642a7823@solarflare.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox