From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f44.google.com (mail-pj1-f44.google.com [209.85.216.44]) by mx.groups.io with SMTP id smtpd.web10.909.1667494317267003152 for ; Thu, 03 Nov 2022 09:51:57 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20210112 header.b=eZWM72MC; spf=pass (domain: gmail.com, ip: 209.85.216.44, mailfrom: pedro.falcato@gmail.com) Received: by mail-pj1-f44.google.com with SMTP id gw22so2221233pjb.3 for ; Thu, 03 Nov 2022 09:51:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Y7r6cgJ22g51ewbxpFl4l7gqdbl+8R/b2d66r06Q0Og=; b=eZWM72MCOJp9Ysm9JDjeAvVhrln5uApvTMo8JndyjWsEpv0BKLZABapIBO+MZ2GncM gbeWjQ0RHmX6P46Y711Ifu8n+/Nm6Vn6rRJxABfGRA3Z0PQXLiYQCWNz52B/334ktfX1 8Lb9qvdkBS6z7AacMamM1qkrcy2XK7wDFvuoOA8A6Ehpfz/OE/gj6wv03/ayr24KjWxB vVv7oM/6xaTY8EFGA+eqhgrWs844iSFXT8eaoGWIb+SYp2oko8jts7E3lxRoUcunb75q CAOsZk06mHSzndPyVvtmOvM6kRbQR6XoeP0J97akzXG296pK2mJJRrX1nv0dxMPM1ifa GQaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Y7r6cgJ22g51ewbxpFl4l7gqdbl+8R/b2d66r06Q0Og=; b=8NrKGukcQtFWfyyySc+z/34vTXb6n9/yh06JynD0JLtV010iS418bBRhQTLbvs+UEH sZ6ESLbwDH0P9PoV6psHGKU229607YEePVJ7nxwtbmX815XNz9C74mlfMdKQCa2waddN PrxCknl0hQ5bLhfLsKS55/zS2neHK9dQ/D/huekiY6SomVQOHONqzvVZ8hBRA5R7QO3h +BoOfKqCamGJ0IFXcXyw8ExrbKZJAwF/OIFzfSl7TFqMcy8McPwRf++VyVaDShaAAFuQ NtbEMDqffPYgaULra1Bt0cf6ckPCdWDoFI9mgffvOG3GSrvZpPF9xB+w0uqYw34nTbBP QHRw== X-Gm-Message-State: ACrzQf30fGMcDjQp9V+kmWyyZT1CVEg5Q7qFlS1hEMKdtpIHL0LIKvBS 9RY0wAxnJUXVAZFsfyDii6HgKFaKYMziYo1KvUTt7e0pGN0vgg== X-Google-Smtp-Source: AMsMyM5MACrcAEOl/8NGr68vH+w43skH80iPPhpnhYUgef1p8wgUY8JFD6DhVEmkpx9PreKwx80xgYg7ZPGrE9c+wh8= X-Received: by 2002:a17:902:f685:b0:186:fa9c:2fdc with SMTP id l5-20020a170902f68500b00186fa9c2fdcmr31296578plg.25.1667494316410; Thu, 03 Nov 2022 09:51:56 -0700 (PDT) MIME-Version: 1.0 References: <3519C852-1306-4986-92F2-D5B2C4531D00@apple.com> <3713.1667489002694449238@groups.io> In-Reply-To: <3713.1667489002694449238@groups.io> From: "Pedro Falcato" Date: Thu, 3 Nov 2022 16:51:44 +0000 Message-ID: Subject: Re: [edk2-devel] How to add a DXE driver to an OVMF image? To: devel@edk2.groups.io, d.meneses@softi9.pt Cc: Andrew Fish Content-Type: multipart/alternative; boundary="0000000000006509a105ec93c628" --0000000000006509a105ec93c628 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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_for= mat/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=C3=A1!!!), thank you for pointing me to= the > DebugLib, I'll look into it. > Ol=C3=A1! :) > 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|. 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 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/QemuO= penBoardPkg (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 >=20 > > --=20 Pedro Falcato --0000000000006509a105ec93c628 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

DEPEX (= AIUI, I might be playing loose with language here) is essentially a bunch o= f conditions you can package with your .efi that explain how your .efi depe= nds 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=3Dsofti9.pt@groups.io> wrote:

Thank you Andrew for this information. =
I set it to true cause the builder was asking for a Depex sec= tion.
Setting it to false allows QEMU to boot properly.
=

By setting DEPEX to False, you're making sur= e it will *never* run ;)

Do note that UEFI_DRIVER = does not require a DEPEX section, only DXE_DRIVERs do.
&qu= ot;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 remai= ning drivers, PEIM, DXE_DRIVER, DXE_SAL_DRIVER, DXE_RUNTIME_DRIVER and DXE_SMM_DRIVER module types must have a= [Depex] section."= ;

No= netheless, the driver doesn't seem to be called... yet.

C= oncerning Pedro's suggestion (Ol=C3=A1!!!), thank you for pointing me t= o the DebugLib, I'll look into it.=C2=A0

Ol=C3= =A1! :)

Nonet= heless, I'll need to use ConInt and ConOut in production.

Are you sure you need ConIn and ConOut in a driver? Mayb= e you have your priorities wrong.
IMO it only makes sense on a UE= FI app (where you would do app-like things, like under a normal operating s= ystem), and not on a UEFI driver (for which I find printing to an actual sc= reen 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 p= hase...
Anyhow, in theory I'd be able to install the I/O protocols i= n the DXE phase in order to be able to use them. Right?
The TerminalD= xe.inf, a UEFI driver, states: Terminal module installs Simpl= e Text Input(ex)/Out protocols for serial devices

<= div>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 t= hrough and through.


I think assumed erroneously that the OvmfX64.fdf= =C2=A0is setting the ordering of the DXE drivers.
After Andrew's ans= wer I realised that may actually be done in the=C2=A0Depex Section?<= /p>

AIUI, generally you're not supposed to give a damn= about ordering if you're a well behaved UEFI driver model driver, henc= e why UEFI_DRIVER doesn't even support DEPEX.


I'll read its specification no= w in order to better understand how to use it.=C2=A0

Nonetheless, I = tried turning it from a DXE_DRIVER into a UEFI_DRIVER and it&= #39;s still not natively being listed in EFI Shell's=C2=A0drivers=C2= =A0command.
I don't see yet how mine differs from=C2=A0Termin= alDxe. Maybe it's crashing and being unloaded.

Maybe it's simpler than all of this.= =C2=A0
My true goal is:=C2=A0my program= needs to be shipped with the BIOS image in ROM and=C2=A0run for sure=C2=A0= on every boot, with no possibility of being=C2=A0circumvented= .
I have also read that some DXE drivers are not guaranteed to run if so= mething 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=C2=A0documentatio= n=C2=A0on actual=C2=A0programming u= sing EDK2?

Yes. See the UEFI spec, UEFI PI = spec (if you're programming for PEI).
For more EDK2-ish and l= ess official stuff, see https://edk2-docs.gitbook.io/edk-ii-module-writer-s-gui= de/ (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 wa= nt to pull, see the .inf. It should have a LIBRARY_CLASS. Add it to your [L= ibraryClasses] for your module's .inf.
Then in your .dsc add = that same library class as LIBRARYCLASS|<PathToLibraryDotInf>. Note t= hat you may need to add that library's package to your .inf's [Pack= ages].

Why is this so convoluted? EDK2 is stupidly= overridable and generic. For example, your driver may depend on a OrderedC= ollectionLib, but the person building a platform may want you to use
<= div>a <random fancy algorithm> instead of MdePkg's BaseOrderedCol= lectionRedBlackTreeLib, 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 :)

<= div>I (biasedly) recommend you look into my Ext4Pkg (https://gith= ub.com/tianocore/edk2-platforms/tree/master/Features/Ext4Pkg) for a goo= d example of a simple DXE driver with some dependencies on other libraries.=
If you want to take a look at a manageable, smaller platform tha= t 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-platf= orms/tree/master/Platform/Qemu/QemuOpenBoardPkg (again, very biasedly := P).

Thanks,
Pedro

Is=C2=A0reading source code the only way to go?
I have also use= d DoxyGen to generate docs, but it's far from ideal.

Cheers,
= Diogo

=20



--
Pedro Falcato
--0000000000006509a105ec93c628--