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

["Pedro Falcato" <pedro.falcato@gmail.com>]

[-- 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 --]