Hi Tom, I am using OVMF. I will try to enable some debug info from DxeCapsuleLib. Thanks, Sandeep

Hi Sandeep, Remind me, are you using a real platform to do these tests or are you using OVMF? If you are using real hardware, the platform needs to properly support capsules, which is quite rare

Hi Tom, Sorry for the delayed response. I was offloaded to some other work. Thanks for the pointer. There was some issue in FMP code in UEFI driver. After fixing this issue, booting is fine and

Why do you use UEFI variables for storing data related to a user-space component? If the use case has nothing to do with UEFI (or firmware in general), then UEFI variables look like a bad

(cc edk2-discuss for people with the same issue) Glad to hear you've solved your problem! Cheers, Tom

Good days to everybody, I'm working on a user-space driver that uses UEFI for storing some driver specific variables. Due to the fact that this driver runs on Real-Time platform +1ms delays are

There is a functionality in AMD hardware debug tools, HDT, with which you can set a breakpoint at the SMM entry point, the very first piece of code. I believe Intel's debug tools has the same

Both AMD and Intel's Architectures Software Developer's Manual have the chapter to describe how to enter the SMM. Yes, SMM is transparent for OS, so OS developers hate it. OS developers create SCI

Hi Liming, I have SuperMicro X8 and X10 UEFI systems with me. X10 AMI motherboard version: EFI spec revision 2.4 EFI revision 5.11 X8 AMI motherboard version: EFI spec revision 2.31 EFI revision

As I know, the SMM flow as below: 1. Hardware trigger SMM signal (by IO trap, USB, PowerButton, and so on, detail in PI Spec) 2. CPU Save context and jump to the _SmiEntryPoint(SmiEntry.nasm) 3.

Hello, i would like to write code, right after an SMI occurs. I have searched the functions such as SmiRendezvous,SmiManage etc, and finally went to UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.nasm

You can register your unload function in the .inf file for your driver like this: [Defines] ... UNLOAD_IMAGE = MyUnloadFunction

The difference between the 5.11 AMI bios and 4.654 AMI bios will be much, much bigger than just the difference between the spec revisions from 2.31 to 2.4. The spec revision is just the set of APIs

You can register your unload function in the .inf file for your driver like this: [Defines] ... UNLOAD_IMAGE = MyUnloadFunction

I review Edk2 DxeMain history. gBS->UnloadImage() behavior has no change in UEFI2.3 and UEFI2.4. Which UEFI system are you using? Thanks Liming Sent: 2020年8月4日 2:44 To: udai sharma

Hi Andrew, Laszlo, Tomas, Thanks for your comments. I wrote a simple Test optiom Driver [Attached init.c] to verify the unload part, with minimum protocol install for a UEFI PCI BUS driver. From

So gBS->UnloadImage() is returning EFI_UNSUPPORTED. Per the UEFI Spec that implies that driver did not register an unload function. Unload functions are not required. Thanks, Andrew Fish

Not sure what should be mising at this point; the DEC default for PcdPciBusHotplugDeviceSupport is TRUE. Using OVMF, virtual PCI and PCIe devices can be hot-plugged. (Not sure about NVME, but

Hi All, Does anyone know whether the development status of Pcie Hotplug support using PcdPciBusHotplugDevice is completed (especially with respect to NVME drives)? Has anyone successfully enabled

Thanks Laszlo, clear now :)