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...@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 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#95899): https://edk2.groups.io/g/devel/message/95899 Mute This Topic: https://groups.io/mt/94734592/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
