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?

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