The DEC file says: ## Indicates if Variable driver will enable emulated variable NV mode.<BR><BR> # If this PCD is configured to dynamic, its value should be set before Variable driver starts to

InitEmuNonVolatileVariableStore or InitRealNonVolatileVariableStore will be used to initial non-volatile variable according to value of PcdEmuVariableNvModeEnable. How do I know which one I should

That sounds like an x86 exception vector number. 6 is an Invalid Opcode, and in EFI that usually means the code ran off into the weeds and started executing garbage. So stack corruption, or bad

Hi Team, I am seeing this error on my serial console coming from Oprom boot driver. I am unable to find/debug from where it is getting originated and what could be root cause for it. ERROR: Type:2;

Contact your card / adapter vendor, is the best guess I have... Laszlo

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