On Nov 9, 2022, at 10:29 AM, d.meneses via groups.io <d.meneses=softi9.pt@groups.io> wrote:Thank you Andrew for your reply.
Your explanation about the Driver Binding protocol cleared up some questions of mine.
Regarding the BDS, I recon I have some reading to do before I understand what you said and why it might be relevant to me.
The BDS is what runs after all the discovered drivers have been dispatched. The BDS processes all those UEFI NVRAM variables I references, and sets platform defaults.
For now I am investigating the possibility of having a DxeDriver load an UEFI application and create an event to start it after the DXE Phase is over and the Terminal protocol is available.
That seems very Rube Goldberg. There are no threads in UEFI, just events that run at a higher TPL. It is not legal, per the UEFI specification to run applications at elevate TPL [1]. There is no way for a driver to inject its self into the main thread. So for example your App running at elevate TPL could block the lower priority events needed to read from the disk or manage the network traffic. EFI is a cooperative event model so your code running at a given event level blocks all code at that level or lower from running indefinitely.
I need to:
- learn how to load and start images. To that end I have found a CoreLoadImage and CoreStartImage edk2 functions, buuut
- I haven't figured out how to get the device path to my UEFI app
- I was wondering if I could somehow use my app's GUID to search for it?
If you look at the code I pointed you to in the OVMF BDS Platform lib I think you will find it writes an UEFI Boot Variable that contains a Device Path that has the FILE_GUID as the file name.
If you want to try something quick you could replace the FILE_GUID for the UEFI Shell with the FILE_GUID for your App and it should not launch in place of the UEFI Shell.
- Then I'd learn how to use events and have them start the app
As I mentioned that is going to break stuff.
[1]
I'm deeply thankful for your time, wish you luck and peace