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.
Cheers,Tom
On Tue, Aug 4, 2020 at 1:42 PM udai sharma wrote:
Noted.



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.

Cheers,Tom

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" .











[Defines]



INF_VERSION = 0x00010005



BASE_NAME = TestDxe



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



MODULE_TYPE = UEFI_DRIVER



VERSION_STRING = 1.0



ENTRY_POINT = InitializeTest



UNLOAD_IMAGE = TestUnload







....







EFI_STATUS



EFIAPI



InitializeTest(



IN EFI_HANDLE ImageHandle,



IN EFI_SYSTEM_TABLE *SystemTable



)



{



EFI_STATUS Status;



EFI_HANDLE Existing_ImageHandle=0x0;



UINT8 UnLoad = 0;



EFI_LOADED_IMAGE_PROTOCOL *LoadedImage;







.......







// Open Loaded Image protocol



Status = gBS->OpenProtocol (



ImageHandle,



&gEfiLoadedImageProtocolGuid,



(VOID **)&LoadedImage,



ImageHandle,



NULL,



EFI_OPEN_PROTOCOL_GET_PROTOCOL



);



ASSERT_EFI_ERROR (Status);







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?







Thanks.























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.



Cheers,



Tom



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



+Andrew:















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



hang.







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



advice.







> 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.















Thanks







Laszlo