How to add a DXE driver to an OVMF image?

How to add a DXE driver to an OVMF image?

[d.meneses]

[-- Attachment #1: Type: text/plain, Size: 1696 bytes --]

As detailed on this post on Super User ( https://superuser.com/q/1749795/1742482 ) , I am trying to *add a DXE driver to an OVMF image* I'm building with edk2. Nobody was able to help me there so I turn here for your help.

I haven't found any proper documentation on exactly what I'm trying to achieve so I am probably missing something.

So far what I have done is:

* create the simplest DXE driver I managed

In folder *MdeModulePkg/Application/Hello* , I have:
*Hello.c* :
include

...

while ( 1 )
SystemTable -> ConOut -> OutputString ( SystemTable ->ConOut,
L " It works! \n " );
return EFI_SUCCESS ;

*Hello.inf* :
[ Defines ]
INF_VERSION = 0x00010005
BASE_NAME = Hello
FILE_GUID =...
MODULE_TYPE = DXE_DRIVER
VERSION_STRING = 1.0
ENTRY_POINT = UefiMain

[ Sources ]
Hello.c

[ Packages ]
MdePkg/MdePkg.dec
MdeModulePkg/MdeModulePkg.dec

[ LibraryClasses ]
UefiDriverEntryPoint
UefiLib

[ Depex ]
TRUE

* Set *OvmfPkg/OvmfPkgX64.dsc* as my target platform with *GCC5* as the toolchain
* Add *MdeModulePkg/Application/Hello/Hello.inf* to the end of the component section (I have tried to add it after other certain drivers) in the *.dsc* file.
* 
Add *Mde* *ModulePkg/Application/Hello/Hello.inf* to the end of the *[ FV.DXEFV* *]* section in *OvmfPkgX64.fdf* (I have also tried to add it after other certain drivers)

* 
Run *build*

* 
Run *QEMU* with the resulting *OVMF* image: *qemu-system-x86_64* *-d int -D log.txt -bios OVMF.fd -net none -drive file=fat:rw:bootdrv, format=raw*

* 
*QEMU* hangs with message *"Guest has not initialized display (yet)"*

* 
*log.txt* has one log: *check_exception old: 0xffffffff new 0x6*

[-- Attachment #2: Type: text/html, Size: 27957 bytes --]

Re: [edk2-devel] How to add a DXE driver to an OVMF image?

[Pedro Falcato]

[-- Attachment #1: Type: text/plain, Size: 2813 bytes --]

Hi!

If I recall correctly, UEFI drivers are not guaranteed to have a valid
ConOut and ConIn, and you're not supposed to use those. They are (always?)
valid in UEFI apps.
Can you try to use DebugLib (don't forget to place DebugLib in
LibraryClasses) and DEBUG((DEBUG_INFO, "Blah\n")); ? That should pretty
much work. Note that OVMF will send those debug messages to a special
device, so you can pass "-debugcon file:debug.log -global
isa-debugcon.iobase=0x402" to QEMU to keep them. The rest of your procedure
looks mostly OK as far as I can tell.

Crash theory: ConOut was garbage, so you tried to jump into a random
address. Random address had random data/instructions in there, which caused
you an int 6 -> Invalid opcode.

Thanks,
Pedro

On Wed, Nov 2, 2022 at 2:02 PM d.meneses via groups.io <d.meneses=
softi9.pt@groups.io> wrote:

> As detailed on this post on Super User
> <https://superuser.com/q/1749795/1742482>, I am trying to *add a DXE
> driver to an OVMF image* I'm building with edk2. Nobody was able to help
> me there so I turn here for your help.
>
> I haven't found any proper documentation on exactly what I'm trying to
> achieve so I am probably missing something.
>
> So far what I have done is:
>
>    - create the simplest DXE driver I managed
>
> In folder *MdeModulePkg/Application/Hello*, I have:
> *Hello.c* :
> include
>
> ...
>
> while (1)
>         SystemTable->ConOut->OutputString(SystemTable->ConOut,
>                                           L"It works!\n");
> return EFI_SUCCESS;
>
>
> *Hello.inf* :
> [Defines]
>   INF_VERSION                    = 0x00010005
>   BASE_NAME                      = Hello
>   FILE_GUID                      = ...
>   MODULE_TYPE                    = DXE_DRIVER
>   VERSION_STRING                 = 1.0
>   ENTRY_POINT                    = UefiMain
>
>
> [Sources]
>   Hello.c
>
> [Packages]
>   MdePkg/MdePkg.dec
>   MdeModulePkg/MdeModulePkg.dec
>
> [LibraryClasses]
>   UefiDriverEntryPoint
>   UefiLib
>
> [Depex]
>     TRUE
>
>    - Set *OvmfPkg/OvmfPkgX64.dsc* as my target platform with *GCC5* as
>    the toolchain
>    - Add *MdeModulePkg/Application/Hello/Hello.inf* to the end of the
>    component section (I have tried to add it after other certain drivers) in
>    the *.dsc* file.
>    - Add *Mde**ModulePkg/Application/Hello/Hello.inf* to the end of the
>    *[FV.DXEFV**]* section in *OvmfPkgX64.fdf* (I have also tried to add
>    it after other certain drivers)
>    - Run *build*
>    - Run *QEMU* with the resulting *OVMF* image: *qemu-system-x86_64** -d
>    int -D log.txt  -bios OVMF.fd -net none -drive
>    file=fat:rw:bootdrv,format=raw*
>    - *QEMU* hangs with message *"Guest has not initialized display (yet)"*
>    - *log.txt* has one log: *check_exception old: 0xffffffff new 0x6*
>
>
> 
>
>

-- 
Pedro Falcato

[-- Attachment #2: Type: text/html, Size: 26123 bytes --]

Re: [edk2-devel] How to add a DXE driver to an OVMF image?

[Andrew Fish]

[-- Attachment #1: Type: text/plain, Size: 3521 bytes --]

If you are building with the firmware use the DebugLib in the INF and DEBUG(); macros.

DEBUG((DEBUG_ERROR, “It works\n”));

Also by setting your Depex to TRUE you are basically asking to run before the console is available. If you want to depend on all UEFI Services being present don’t set a dependency expression. The Depex is for ordering the early drivers that don’t follow the UEFI Driver Model. So for example you have to configure your chipset, and SPI driver to get UEFI NVRAM working etc. 

Thanks,

Andrew Fish

> On Nov 2, 2022, at 5:58 PM, Pedro Falcato <pedro.falcato@gmail.com> wrote:
> 
> Hi!
> 
> If I recall correctly, UEFI drivers are not guaranteed to have a valid ConOut and ConIn, and you're not supposed to use those. They are (always?) valid in UEFI apps.
> Can you try to use DebugLib (don't forget to place DebugLib in LibraryClasses) and DEBUG((DEBUG_INFO, "Blah\n")); ? That should pretty much work. Note that OVMF will send those debug messages to a special device, so you can pass "-debugcon file:debug.log -global isa-debugcon.iobase=0x402" to QEMU to keep them. The rest of your procedure looks mostly OK as far as I can tell.
> 
> Crash theory: ConOut was garbage, so you tried to jump into a random address. Random address had random data/instructions in there, which caused you an int 6 -> Invalid opcode.
> 
> Thanks,
> Pedro
> 
> On Wed, Nov 2, 2022 at 2:02 PM d.meneses via groups.io <http://groups.io/> <d.meneses=softi9.pt@groups.io <mailto:softi9.pt@groups.io>> wrote:
>> As detailed on this post on Super User <https://superuser.com/q/1749795/1742482>, I am trying to add a DXE driver to an OVMF image I'm building with edk2. Nobody was able to help me there so I turn here for your help.
>>  
>> I haven't found any proper documentation on exactly what I'm trying to achieve so I am probably missing something.
>>  
>> So far what I have done is:
>> create the simplest DXE driver I managed
>> In folder MdeModulePkg/Application/Hello, I have:
>> Hello.c : 
>> include
>>  
>> ...
>>  
>> while (1)
>>         SystemTable->ConOut->OutputString(SystemTable->ConOut,
>>                                           L"It works!\n");
>> return EFI_SUCCESS;
>> 
>>  
>> Hello.inf : 
>> [Defines]
>>   INF_VERSION                    = 0x00010005
>>   BASE_NAME                      = Hello
>>   FILE_GUID                      = ...
>>   MODULE_TYPE                    = DXE_DRIVER
>>   VERSION_STRING                 = 1.0
>>   ENTRY_POINT                    = UefiMain
>> 
>> 
>> [Sources]
>>   Hello.c
>> 
>> [Packages]
>>   MdePkg/MdePkg.dec
>>   MdeModulePkg/MdeModulePkg.dec
>> 
>> [LibraryClasses]
>>   UefiDriverEntryPoint
>>   UefiLib
>> 
>> [Depex]
>>     TRUE
>> Set OvmfPkg/OvmfPkgX64.dsc as my target platform with GCC5 as the toolchain
>> Add MdeModulePkg/Application/Hello/Hello.inf to the end of the component section (I have tried to add it after other certain drivers) in the .dsc file.
>> Add MdeModulePkg/Application/Hello/Hello.inf to the end of the [FV.DXEFV] section in OvmfPkgX64.fdf (I have also tried to add it after other certain drivers)
>> Run build
>> Run QEMU with the resulting OVMF image: qemu-system-x86_64 -d int -D log.txt  -bios OVMF.fd -net none -drive file=fat:rw:bootdrv,format=raw
>> QEMU hangs with message "Guest has not initialized display (yet)"
>> log.txt has one log: check_exception old: 0xffffffff new 0x6
>>  
>> 
>> 
> 
> 
> -- 
> Pedro Falcato
> 


[-- Attachment #2: Type: text/html, Size: 30481 bytes --]

Re: [edk2-devel] How to add a DXE driver to an OVMF image?

[d.meneses]

[-- Attachment #1: Type: text/plain, Size: 2027 bytes --]

Thank you Andrew for this information.
I set it to *true* cause the builder was asking for a *Depex section*.
Setting it to *false allows QEMU* to boot properly.
Nonetheless, the driver *doesn't seem to be called*... yet.

Concerning Pedro's suggestion (Olá!!!), thank you for pointing me to the DebugLib, I'll look into it.
Nonetheless, I'll need to *use ConInt and ConOut in production*.
I am aware of a DXE program that does it. Maybe I was passed the wrong information and the program is running on another phase...
Anyhow, in theory I'd be able to install the I/O protocols in the DXE phase in order to be able to use them. Right?
The *TerminalDxe.inf* , a *UEFI driver* , states: *Terminal module installs Simple Text Input(ex)/Out protocols for serial devices
*
I think assumed erroneously that the *OvmfX64.fdf* is setting the ordering of the DXE drivers.
After Andrew's answer I realised that may actually be done in the *Depex Section?*
I'll read its specification now in order to better understand how to use it.

Nonetheless, I tried turning it from a *DXE_DRIVER* into a *UEFI_DRIVER* and it's still not natively being listed in EFI Shell's *drivers* command.
I don't see yet how mine differs from *TerminalDxe*. Maybe it's crashing and being unloaded.

Maybe it's simpler than all of this.
My true goal is: my program needs to be shipped with the BIOS image in ROM and run for sure on every boot, with no possibility of being *circumvented*.
I have also read that some DXE drivers are not guaranteed to run if something like fast boot is activated.
Taking that in consideration, what module type should I create to achieve my goal?

Finally, is there any documentation on actual programming using EDK2 ?
Say, which functions can I use to read user input?
Or what dependencies do I have to include as LibraryClasses if I want to use a certain function?
Is reading source code the only way to go ?
I have also used DoxyGen to generate docs, but it's far from ideal.

Cheers,
Diogo

[-- Attachment #2: Type: text/html, Size: 2663 bytes --]

Re: [edk2-devel] How to add a DXE driver to an OVMF image?

[Pedro Falcato]

[-- Attachment #1: Type: text/plain, Size: 5542 bytes --]

Hi,

DEPEX (AIUI, I might be playing loose with language here) is essentially a
bunch of conditions you can package with your .efi that explain how your
.efi depends on protocols.
If you set it to TRUE, it will *always* run. If you set it to FALSE, it
will *never* run (because it will always evaluate to FALSE).

On Thu, Nov 3, 2022 at 3:23 PM d.meneses via groups.io <d.meneses=
softi9.pt@groups.io> wrote:

> Thank you Andrew for this information.
> I set it to *true* cause the builder was asking for a *Depex section*.
> Setting it to *false allows QEMU* to boot properly.
>
By setting DEPEX to False, you're making sure it will *never* run ;)

Do note that UEFI_DRIVER does not require a DEPEX section, only DXE_DRIVERs
do.
Per
https://edk2-docs.gitbook.io/edk-ii-inf-specification/3_edk_ii_inf_file_format/314_-depex-_sections
:
"Drivers with MODULE_TYPE set to SEC, PEI_CORE, DXE_CORE, SMM_CORE,
UEFI_DRIVER and UEFI_APPLICATION cannot have [Depex] sections. Libraries
and modules that are USER_DEFINED may have a [Depex] section. All remaining
drivers, PEIM, DXE_DRIVER, DXE_SAL_DRIVER, DXE_RUNTIME_DRIVER and
DXE_SMM_DRIVER module types must have a [Depex] section."

> Nonetheless, the driver *doesn't seem to be called*... yet.
>
> Concerning Pedro's suggestion (Olá!!!), thank you for pointing me to the
> DebugLib, I'll look into it.
>
Olá! :)

> Nonetheless, I'll need to *use ConInt and ConOut in production*.
>
Are you sure you need ConIn and ConOut in a driver? Maybe you have your
priorities wrong.
IMO it only makes sense on a UEFI app (where you would do app-like things,
like under a normal operating system), and not on a UEFI driver (for which
I find printing to an actual screen or getting input really backwards).

> I am aware of a DXE program that does it. Maybe I was passed the wrong
> information and the program is running on another phase...
> Anyhow, in theory I'd be able to install the I/O protocols in the DXE
> phase in order to be able to use them. Right?
> The *TerminalDxe.inf*, a *UEFI driver*, states:
> *Terminal module installs Simple Text Input(ex)/Out protocols for serial
> devices*
>
I think you could in theory add the Simple Text In/Output protocols to your
depex. But whyyyyy???
This smells like an X Y problem through and through.

>
> I think assumed erroneously that the *OvmfX64.fdf* is setting the
> ordering of the DXE drivers.
> After Andrew's answer I realised that may actually be done in the *Depex
> Section?*
>
AIUI, generally you're not supposed to give a damn about ordering if you're
a well behaved UEFI driver model driver, hence why UEFI_DRIVER doesn't even
support DEPEX.

>
> I'll read its specification now in order to better understand how to use
> it.
>
> Nonetheless, I tried turning it from a *DXE_DRIVER* into a *UEFI_DRIVER*
> and it's still not natively being listed in EFI Shell's *drivers *command.
> I don't see yet how mine differs from *TerminalDxe*. Maybe it's crashing
> and being unloaded.
>
> Maybe it's simpler than all of this.
> My true goal is: my program needs to be shipped with the BIOS image in
> ROM and run for sure on every boot, with no possibility of being
> *circumvented*.
> I have also read that some DXE drivers are not guaranteed to run if
> something like fast boot is activated.
> Taking that in consideration, what module type should I create to achieve
> my goal?
>
Is it a program? Is it a driver? Do you want it to run on DXE or on PEI?

> Finally, is there any documentation on actual programming using EDK2?
>
Yes. See the UEFI spec, UEFI PI spec (if you're programming for PEI).
For more EDK2-ish and less official stuff, see
https://edk2-docs.gitbook.io/edk-ii-module-writer-s-guide/ (and other
similar specs if needed).

> Say, which functions can I use to read user input?
> Or what dependencies do I have to include as LibraryClasses if I want to
> use a certain function?
>
<this is maybe a simplistic view of what to do>
Go to the library you want to pull, see the .inf. It should have a
LIBRARY_CLASS. Add it to your [LibraryClasses] for your module's .inf.
Then in your .dsc add that same library class as
LIBRARYCLASS|<PathToLibraryDotInf>. Note that you may need to add that
library's package to your .inf's [Packages].

Why is this so convoluted? EDK2 is stupidly overridable and generic. For
example, your driver may depend on a OrderedCollectionLib, but the person
building a platform may want you to use
a <random fancy algorithm> instead of MdePkg's
BaseOrderedCollectionRedBlackTreeLib, so they override it in their .dsc.

Note that this is all very complex and described by a spec (
https://edk2-docs.gitbook.io/edk-ii-build-specification/) plus whatever
nuggets of wisdom the Intel EFI OGs put out from time to time :)

I (biasedly) recommend you look into my Ext4Pkg (
https://github.com/tianocore/edk2-platforms/tree/master/Features/Ext4Pkg)
for a good example of a simple DXE driver with some dependencies on other
libraries.
If you want to take a look at a manageable, smaller platform that overrides
a bunch of libraries (and see the e x t e n s i b l e in action!), see our
https://github.com/tianocore/edk2-platforms/tree/master/Platform/Qemu/QemuOpenBoardPkg
(again, very biasedly :P).

Thanks,
Pedro

> Is reading source code the only way to go?
> I have also used DoxyGen to generate docs, but it's far from ideal.
>
> Cheers,
> Diogo
> 
>
>

-- 
Pedro Falcato

[-- Attachment #2: Type: text/html, Size: 10234 bytes --]

Re: [edk2-devel] How to add a DXE driver to an OVMF image?

[d.meneses]

[-- Attachment #1: Type: text/plain, Size: 339 bytes --]

Yes I also believe I'm threading a XY problem.

Let's simplify my learning and set the goal to: add an UEFI application to OVMF so that it runs natively on startup.

Does this make more sense?

I followed the same process and I can use UEFITool to confirm there's an UefiApplication inside the OVMF image.

How can I make it run?

[-- Attachment #2: Type: text/html, Size: 377 bytes --]

Re: [edk2-devel] How to add a DXE driver to an OVMF image?

[Andrew Fish]

[-- Attachment #1: Type: text/plain, Size: 1654 bytes --]



> On Nov 3, 2022, at 12:11 PM, d.meneses via groups.io <d.meneses=softi9.pt@groups.io> wrote:
> 
> Yes I also believe I'm threading a XY problem. 
> 
> Let's simplify my learning and set the goal to: add an UEFI application to OVMF so that it runs natively on startup.
> 
> Does this make more sense?
> 
> I followed the same process and I can use UEFITool to confirm there's an UefiApplication inside the OVMF image.
> 
> How can I make it run?

Do you need to run it from FLASH? Or do you just want to run it? 

What I usually do with QEMU is pass -hda fat:rw:Build/OvmfX64/DEBUG_XCODE5/X64 to mount a directory on my system in QEMU. This should show up in the UEFI Shell as FS0: if you don’t have any other disks. The path is the build output, so you need to match what you built. So DEBUG_GCC??? Vs DEBUG_XCODE, as this path encodes the build target, compiler, etc.

Then when you boot to the UEFI Shell you just need to mount the disk and run your app. 

Fs0:
MyApp.efi

You can also redirect the text output of your app to a file, and since fs0: is just your build directory you can get the output out of the VM. 

>From the UEFI Shell you can `reset -s` to shut down the VM.

If you place a startup.nsh the UEFI Shell command should run those commands when launched. 

It is also possible to make a FAT32 disk image and boot your app directly, just like an OS loader[1]. Just copy your app to /EFI/BOOT/BOOTx64.EFI in the disk image and mount the disk image from the QEMU command line.

[1] https://uefi.org/specs/UEFI/2.10/03_Boot_Manager.html#removable-media-boot-behavior

Thanks,

Andrew Fish


> 


[-- Attachment #2: Type: text/html, Size: 2624 bytes --]

Re: [edk2-devel] How to add a DXE driver to an OVMF image?

[d.meneses]

[-- Attachment #1: Type: text/plain, Size: 287 bytes --]

It needs to run from FLASH and not an EFI partition.
It needs to run at startup before the boot loader and OS.
This is in order to make it non-removable and unskippable, unlike apps in /EFI/BOOT.
I am aware of the other options you've mentioned, I've even done it on a real machine.

[-- Attachment #2: Type: text/html, Size: 301 bytes --]

Re: [edk2-devel] How to add a DXE driver to an OVMF image?

[Pedro Falcato]

[-- Attachment #1: Type: text/plain, Size: 432 bytes --]

On Thu, Nov 3, 2022 at 10:02 PM d.meneses via groups.io <d.meneses=
softi9.pt@groups.io> wrote:

> It needs to run from FLASH and not an EFI partition.
>
Why flash?

> It needs to run at startup before the boot loader and OS.
> This is in order to make it non-removable and unskippable, unlike apps in
> /EFI/BOOT.
> I am aware of the other options you've mentioned, I've even done it on a
> real machine.
> 
>
>

-- 
Pedro Falcato

[-- Attachment #2: Type: text/html, Size: 978 bytes --]

Re: [edk2-devel] How to add a DXE driver to an OVMF image?

[d.meneses]

[-- Attachment #1: Type: text/plain, Size: 359 bytes --]

I might be using the wrong term, I'm still in the beginning of learning this field so I apologise if I am out of my depth.
Maybe I just meant ROM memory... I thought that ROM memory was stored in flash memory.
The program is currently shipped in a manner that changing or formatting the hard drive doesn't impact its functioning.

Cheers,
Diogo Meneses

[-- Attachment #2: Type: text/html, Size: 379 bytes --]

Re: [edk2-devel] How to add a DXE driver to an OVMF image?

[d.meneses]

[-- Attachment #1: Type: text/plain, Size: 518 bytes --]

Using *DebugLib* instead to print a message, I was able to confirm that my driver is now running properly:
*cat debug.log | grep Hello*
This works both when adding it in the OVMF build and also when inserted by UEFITool.

The drivers is not being listed by the EFI Shell *drivers* command.
This is expected to me as Dxe Drivers are unloaded after they return.
Nonetheless, the same is happening when I package it as a *DXE_RUNTIME_DRIVER*.
What is it that I'm missing?

Thank you for your attention,
Diogo

[-- Attachment #2: Type: text/html, Size: 669 bytes --]

Re: [edk2-devel] How to add a DXE driver to an OVMF image?

[Andrew Fish]

[-- Attachment #1: Type: text/plain, Size: 2395 bytes --]



> On Nov 4, 2022, at 6:20 AM, d.meneses via groups.io <d.meneses=softi9.pt@groups.io> wrote:
> 
> Using DebugLib instead to print a message, I was able to confirm that my driver is now running properly:
> cat debug.log | grep Hello
> This works both when adding it in the OVMF build and also when inserted by UEFITool.
> 
> The drivers is not being listed by the EFI Shell drivers command.
> This is expected to me as Dxe Drivers are unloaded after they return.
> Nonetheless, the same is happening when I package it as a DXE_RUNTIME_DRIVER.
> What is it that I'm missing?
> 

The UEFI Shell drivers command is managing UEFI Driver Model Drivers [1]. A UEFI Driver Model Driver has no depex and publishes an EFI Driver Binding protocol [2]. The idea is the BDS (platform) can now have the policy of what driver gets connected to what device. This is all managed by gBS->ConnectController()/gBS->DisconnectController(). 

A DXE Driver just publishes an arbitrary protocol. 

[1] https://uefi.org/specs/UEFI/2.10/11_Protocols_UEFI_Driver_Model.html
[2] https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/DriverBinding.h


PS I seem to remember a question about launching an App….

It is possible to customize a generic UEFIs system boot policy via NVRAM variable. You can read up on that here [3]. 

If you want to change the platform policy in a secure way to do something you likely need to modify the BDS (Boot Device Selection). The design idea around BDS is you could make a system an ATM or a PC just by changing the policy in the BDS, thus the BDS is a place to centralize the platform policy. The easiest way to customize the edk2 BDS is via a custom PlatformBootManagerLib. You can look at the OVMF instance here [4]. You can use this library to add extra policy on top of the NVRAM variables in the UEFI Spec [3]. If you look at the OVMF example this is how the OVMF platform makes the UEFI Shell a default boot option [5].

[3] https://uefi.org/specs/UEFI/2.10/03_Boot_Manager.html#globally-defined-variables
[4] https://github.com/tianocore/edk2/tree/master/OvmfPkg/Library/PlatformBootManagerLib
[5] https://github.com/tianocore/edk2/blob/master/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c#L1717

Sorry if I’m mixing up threads. So much email, and so little time….

> Thank you for your attention,
> Diogo
> 


[-- Attachment #2: Type: text/html, Size: 3685 bytes --]

Re: [edk2-devel] How to add a DXE driver to an OVMF image?

[d.meneses]

[-- Attachment #1: Type: text/plain, Size: 844 bytes --]

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.

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.

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?
- Then I'd learn how to use events and have them start the app

I'm deeply thankful for your time, wish you luck and peace

[-- Attachment #2: Type: text/html, Size: 924 bytes --]

Re: [edk2-devel] How to add a DXE driver to an OVMF image?

[Andrew Fish]

[-- Attachment #1: Type: text/plain, Size: 2244 bytes --]



> 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]
https://uefi.org/specs/UEFI/2.10/07_Services_Boot_Services.html#event-timer-and-task-priority-services
> I'm deeply thankful for your time, wish you luck and peace
> 


[-- Attachment #2.1: Type: text/html, Size: 5822 bytes --]

[-- Attachment #2.2: favicon.ico --]
[-- Type: image/vnd.microsoft.icon, Size: 1406 bytes --]

Re: [edk2-devel] How to add a DXE driver to an OVMF image?

[d.meneses]

[-- Attachment #1: Type: text/plain, Size: 472 bytes --]

> 
> That seems very Rube Goldberg.

Ok it seems again that I've hit a XY problem.

I thought that solution might have been the standard way to do it... if it's not, I don't want to do anything that possibly breaks the spec. That would require a way more thorough understanding of the UEFI model.

My root problem is: have a console application stored in EEPROM, always run.

I'll look into your suggestions today as it seems that might be what I'm looking for.

[-- Attachment #2: Type: text/html, Size: 520 bytes --]