Or you could write a startup.nsh script file that loads all the drivers when entering the shell.
-----Original Message----- From: Andrew Fish [mailto:af...@apple.com] Sent: Wednesday, June 19, 2013 10:40 AM To: Stephen Polkowski Cc: edk2-devel@lists.sourceforge.net Subject: Re: [edk2] DXE Driver confusion On Jun 19, 2013, at 10:34 AM, Stephen Polkowski <step...@centtech.com> wrote: > Thanks Andrew. Can a directory be used as a Firmware Volume? > Not without writing a driver that produces a Firmware Volume protocol on top of a directory. If you look at an example platform in the edk2 you will see there is a .DSC (platform build config file) and a corresponding .FDF (FLASH Device Layout) file that places the DXE drivers in FVs that get placed in the FD. So you could have a build tip that created the FV with the drivers you need and you can copy that FV to the directory and your application loads the FV into a memory buffer and calls gDS->ProcessFirmwareVolume(). Thanks, Andrew Fish > Stephen > > Andrew Fish wrote: >> On Jun 19, 2013, at 10:11 AM, Stephen Polkowski <step...@centtech.com> wrote: >>> Hi Thomas, >>> >>> Thank you for your suggestions. I didn't know about #2. >>> >>> Ideally, I wish that the DXE Dispatcher would just load any needed >>> DXEs from a default location (like \EFI\DXE). Instead, the shell >>> application has to do the work of finding the DXEs and installing them. >>> >> The dispatcher only dispatches from FVs (Firmware Volumes), as it is the >> only way to associated the dependency expression with the executable. Your >> code can register an FV via gDS->ProcessFirmwareVolume (). >> Thanks, >> Andrew Fish >>> Regards, >>> >>> Stephen >>> >>> >>> Thomas Rognon wrote: >>>> I'm not sure I understand your goal 100%. However, here are a few ideas. >>>> >>>> 1) You can have your application load them when it starts using >>>> LoadImage() and StartImage() on each one. >>>> >>>> 2) You could have the boot manager load them for you when the computer >>>> starts by putting them in DriverXXXX variables. Chapter 3 of the UEFI Spec >>>> describes this in detail. If you have a nice boot manager, it might even >>>> provide a menu for adding driver options (just like boot options). >>>> >>>> 3) If you want to centralize deployment of the drivers, you could put them >>>> on the network somewhere and write an application that downloads them and >>>> then use LoadImage() and StartImage() on each one. This is how I do some >>>> of my stuff. >>>> >>>> Thomas Rognon >>>> >>>> >>>> On Wed, Jun 19, 2013 at 10:39 AM, Stephen Polkowski <step...@centtech.com >>>> <mailto:step...@centtech.com>> wrote: >>>> >>>> Hello, >>>> >>>> The edk2 produces several DXE drivers from the various packages. >>>> I understand that these drivers can be loaded by using the shell "load" >>>> command. >>>> >>>> Are there any other methods to load DXE drivers from a shell >>>> application? For example, one could have a DXE directory under \EFI >>>> filesystem where a shell application could check for the DXE and >>>> installs it. >>>> Better yet, it would great if the DXE Dispatcher could automatically >>>> load drivers from this directory when needed. >>>> >>>> A second option would be to embedded a DXE driver binary >>>> into the shell application. The shell application could extract the >>>> DXE and >>>> then install it. >>>> >>>> A third possibility is to link the DXE code directly into >>>> the application. >>>> I haven't seen an example of this in the EDK2, so I assume this isn't >>>> possible or suggested. >>>> >>>> The reason I ask is that I am developing some simple shell >>>> utilities. >>>> These utilities are usually passed around the company as single >>>> executables. >>>> Having to carry around all the necessary DXEs for a shell application >>>> is cumbersome and error prone. >>>> >>>> Are there better methods for using DXEs than ones I've >>>> described? >>>> >>>> Thanks, >>>> >>>> Stephen >>>> >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> This SF.net email is sponsored by Windows: >>>> >>>> Build for Windows Store. >>>> >>>> http://p.sf.net/sfu/windows-dev2dev >>>> _______________________________________________ >>>> edk2-devel mailing list >>>> edk2-devel@lists.sourceforge.net >>>> <mailto:edk2-devel@lists.sourceforge.net> >>>> https://lists.sourceforge.net/lists/listinfo/edk2-devel >>>> >>>> >>> >>> -- >>> Stephen Polkowski >>> Centaur Technology >>> Austin, TX >>> (512) 418-5730 >>> >>> -------------------------------------------------------------------- >>> ---------- This SF.net email is sponsored by Windows: >>> >>> Build for Windows Store. >>> >>> http://p.sf.net/sfu/windows-dev2dev >>> _______________________________________________ >>> edk2-devel mailing list >>> edk2-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/edk2-devel > > > -- > Stephen Polkowski > Centaur Technology > Austin, TX > (512) 418-5730 ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
