OptionROM driver update failing in UEFI 2.4 but works on UEFI 2.3.1

Tomas Pilar <tomas@...>

(cc edk2-discuss for people with the same issue)

Glad to hear you've solved your problem!


On Thu, Aug 13, 2020 at 5:09 AM udai sharma <udai16787@...> wrote:
Hi Tomas,
Sorry for the delay in reply. I got caught up in some other things.

UnloadImage using the efiLoadedImageProtocol handle and adding UNLOAD_ENTRY to inf has fixed the issue.

Thanks for your help.

On Tue, 04 Aug 2020 18:38:16 +0530 Tomas Pilar wrote
>So, once you have a driver that you can repeatedly unload and reload with behaviour as expected
(controllers unbind and then rebind every time you reload the driver), this should be true of
both versions of your driver now. Then the mechanism to replace a running driver with a newer version
is simple:
Every version of the driver should have the same modification to the EntryPoint() as follows. When the
driver loads, it will search the platform to see if other versions, or instances of the same driver are
in the platform. This can be done by comparing the ComponentName.DriverName string, or you can come up
with a proprietary protocol that you always install on the driver handle of your driver that contains
the version and you search for the instances of that protocol. This search happens before you do
anything else in the EntryPoint() and you should now have a list of your drivers in the platform as
well as their versions.
For each driver in the list, we compare the version and if the driver is older than us, we open the
LoadedImage protocol installed on the handle of the driver and we call its Unload() function. This
removes the older driver from the system. We don't do anything else, all the uninstallation is done by
the older driver itself in it's Unload() function that we just called through the LoadedImage protocol.
If we encounter a driver that is newer than us, we simply abort everything and return from the
EntryPoint() without doing anything else, because there is already a newer driver.
This assumes that you have one driver driving multiple devices, but even if you drive a single device
the above logic can be appropriately modified. The beauty lies of course in the fact that both version
of the driver contain the same entry code, so it does not depend on which loads earlier and which loads
later. In one case the older driver refuses to load and in the other case, the newer driver will kick
off the older driver and then it doesn't have to do anything different to a normal load.
Let me know if that makes sense.
On Tue, Aug 4, 2020 at 1:42 PM udai sharma wrote:

But this arises the need that HOW do I perform driver update during driver install phase?

On Tue, 04 Aug 2020 17:54:23 +0530 Tomas Pilar wrote

>Oh nonono,

You don't want to mess around with the LoadedImage at all. That is all populated and installed by the

platform when your driver is loaded. You absolutely don't want to touch it yourself.

You just want to make sure you have ENTRY_POINT and UNLOAD_IMAGE set in your [Defines] section and you

are good to go.


On Tue, Aug 4, 2020 at 1:13 PM udai sharma wrote:

Hi Tomas,

I do have unload function added to .inf and also added to "LoadedImage->Unload" .


INF_VERSION = 0x00010005


FILE_GUID = A1f436EA-A127-4EF8-957C-8048606FF670



ENTRY_POINT = InitializeTest






IN EFI_HANDLE ImageHandle,





EFI_HANDLE Existing_ImageHandle=0x0;

UINT8 UnLoad = 0;



// Open Loaded Image protocol

Status = gBS->OpenProtocol (



(VOID **)&LoadedImage,






gTestDriverBinding.ImageHandle = ImageHandle;

gTestDriverBinding.DriverBindingHandle = ImageHandle;

// Set the entry point to unload this driver.

LoadedImage->Unload = TestUnload;

return Status;


Now I am wondering whether the procedure to unload or uninstall the old driver and replace with better

one is correct or not.

Any suggestions?


On Thu, 30 Jul 2020 21:12:56 +0530 Tomas Pilar wrote

>I wouldn't be surprised if this was caused by improper memory management on unload (I actually wrote

this kind of Highlander Protocol for the sfc driver).  These are the things that I would check:

0. If a newer driver exists in the system, the loading driver should just exit without doing

anything.1. If the current driver finds an older driver in the system, it should only call LoadedImage-

>Unload() on the image handle, nothing more.2. The old driver should perform protocol uninstallation in

its Unload() function - it should clean up after itself perfectly. (This is where most of the problems

will likely lie)3. The new driver can proceed with loading as normal.

This can and should be tested by taking each driver and repeatedly loading and unloading it (the same

driver) in shell - you will likely catch a few bugs this way. Then you can add tests for two different

versions interacting with each other.



On Thu, Jul 30, 2020 at 1:23 PM Laszlo Ersek wrote:


On 07/27/20 11:57, UdayS via groups.io wrote:

> Hi All,

> SW Revision updates to my Option Rom/Driver is handled properly during the EntryPoint i.e., using

component name to get the revision info and if existing version is older than current, then

UninstallMultipleProtocolInterfaces and unloadImage.

> This seem to work in UEFI 2.3.1 but when I test the same SW in UEFI 2.4 based system, it goes for a


> I have been banging my around this for last couple for days and now I am in need of some expert


> All suggestions are welcome..

Andrew, do you recall changes related to driver dispatch between 2.3.1

and 2.4? Not necessarily in the spec, but maybe in edk2.