Hello Laszlo, Thank you sincerely! It works just as you said! Snippet: https://gist.github.com/jc-lab/e9c019b8f5c220d06fe312c9bf3af350 Thanks Jospeh.

Hello Laszlo, It has not been checked in detail, but my predictions are this. 1. When a driver is loaded, it calls "InstallMultipleProtocolInterfaces" within that driver. 2. In this process,

I don't understand "installing the driver". Also, what is "notify" in this context? Do you mean the RegisterProtocolNotify() boot service? In what context are you trying to use it? The BDS phase is

Hello Laszlo, Thanks for your answer. I looked at this a bit more today. The cause is not that there is no driver, but it seems that Notify does not work properly for the protocol after installing

Dropping <joseph@...> from the address list, because the RH SMTP server keeps telling me that the domain for that email address (i.e., "zeronsoftn.com") is unidentifiable. Comments

Hello, Some computers (what I checked was an LG laptop) do not recognize the NVMe SSD as a block device in the EFI program. Of course, the OS on the NVMe SSD is bootable. But when I boot with

Hi Laszlo Ersek, Thanks for the style comments, I appreciate it, I will do these changes. And, for the questions, I agree, for the first question, that seems to be a platform driver bug and, for the

Style comment: you should remove "gPciIo", and use the auto-generated "gEfiPciIoProtocolGuid" variable instead. Why not read it with a single EfiPciIoWidthUint16 operation? Also, for the offset,

Hello, I am learning about PCI and trying to write an application that lists PCI controllers in UEFI environment, using EFI_PCI_IO_PROTOCOL and EDK2. I want to list some information from

Hi, I was trying to build the UEFI-SCT for EDK2 on my windows box running cygwin. I follow edk2-test/uefi-sct/HowToBuild/How to build SCT.txt for build instruction. It says X64 is unsupported

Right, my apologies. I'm not sure why I wrote CloseProtocol(). Perhaps a typo, or maybe I lost track of where I was in the PDF with "evince". That seems to be the case, yes. Agreed. Laszlo

Thank you! I see that text in the documentation for the deprecated call UninstallProtocolInterface(), which explains why I hadn't previously noticed it. Based on what the EDK2 implementation

The CloseProtocol() specification has parts as follows (relevant passage is the last one below): The caller is responsible for ensuring that there are no references to a protocol interface

Hi Laszlo, I was almost exclusively checking edk2 headers but should have checked with the specs. Thank you for clarifying it for me. Best, Satoshi

This reminds me of a very longstanding question I've had around OpenProtocol(): is there any defined way for something that is an ordinary consumer (rather than a driver or child controller) to obtain

Hi, gBS->OpenProtocol() calls that pass the EFI_OPEN_PROTOCOL_GET_PROTOCOL argument for the "Attributes" parameter *need not* be mirrored with gBS->CloseProtocol() calls. Please refer to the UEFI

Hi, we do have a updated fork here: github.com/9elements/edk2 This should be more stable than the current one - also we have at least build testing for the UEFIPayload branch. Best, Chris --

If you were to choose to adopt iPXE's simple conceptual model then this would not be necessary. The boot firmware doesn't need to know or care that ports are participating in a bond: it just needs to

Hi, If HPET works but 8254 does not work, further investigation could be on 8254 settings made by Coreboot. Thanks, - ben

Hi, Yes, timer could be a cause for this hang. Old Payload has the option of USE_HPET_TIMER - you could try setting this to TRUE to use HPET instead of 8254 Thanks, - ben