Re: Print from DXE_DRIVER

[Andrew Fish <afish@apple.com>]

> On Feb 8, 2017, at 4:41 PM, David A. Van Arnem <dvanarnem@cmlab.biz> wrote:
> 
> 
> 
> On 02/08/2017 05:15 PM, Laszlo Ersek wrote:
>> On 02/08/17 23:10, David A. Van Arnem wrote:
>>> Hello,
>>> 
>>> I am working on a DXE_DRIVER for a custom device.  I like to use Print()
>>> statements to trace code execution during development.  Thus I have put
>>> a print statement in each of my Supported(), Start(), and Stop()
>>> functions for the driver binding protocol.  Currently I am building the
>>> driver as part of the UefiCpuPkg, with no changes to the current
>>> UefiCpuPkg.dsc except for adding my driver under [Components].  I have
>>> also added the PrintLib and UefiLib to the [LibraryClasses] section in
>>> my driver's INF file, and included the necessary headers.
>>> 
>>> When I load the driver from the shell (load <drivername>.efi), I get a
>>> message indicating it loaded successfully, but no output from the
>>> Print() messages.  The documentation for the shell says load should test
>>> both the Supported() and Start() functions, so I would expect to see the
>>> output, but I am not sure I am using the correct library instances to
>>> accomplish this.  Is it possible to use Print() from a DXE_DRIVER, and
>>> which library instance should I use in the UefiCpuPkg.dsc file?  If not,
>>> would changing it to a UEFI_DRIVER help?  Any other recommendations?
>>> 
>>> If there is an example in edk2 that does this that you could point me
>>> to, that would be sufficient as well.  Thanks!
>>> 
>> 
>> I never tried to use Print() from drivers, only applications
>> (UEFI_APPLICATION modules). In drivers I always use DEBUG, which, based
>> on the DebugLib instance in use, can be routed to some debug port,
>> serial port, etc.
>> 
>> But, I think Print() can be made work too. The only Print() function
>> that should matter is in "MdePkg/Library/UefiLib/UefiLibPrint.c". It uses
>> 
>>  gST->ConOut
>> 
>> as output console. Since this comes from the UEFI system table, it's
>> clear that you shouldn't be writing a DXE_DRIVER, since those can run
>> much earlier than the UEFI architectural protocols become available.
>> DXE_DRIVER modules are practically platform drivers; they are not
>> governed by the UEFI spec by the PI spec, but the system table is
>> defined in the UEFI spec. (The above sounds a bit hand-wavy, but it
>> should work for this discussion.)
>> 
>> Another sign that you should be writing on a UEFI_DRIVER module is that
>> the Start(), Stop(), and Supported() member functions belong to the
>> driver binding protocol, which exists for UEFI drivers that conform to
>> the UEFI driver model. IOW, you're not only working on a UEFI_DRIVER
>> already, but one that falls into a specific class of UEFI_DRIVERs.
>> 
>> The third sign that your module type should be UEFI_DRIVER is the intro
>> text in "MdePkg/Library/UefiLib/UefiLib.inf", to which library Print()
>> belongs. Rewrapped here for readability:
>> 
>> #  The UEFI Library provides functions and macros that simplify the
>> #  development of UEFI Drivers and UEFI Applications.  These functions
>> #  and macros help manage EFI events, build simple locks utilizing EFI
>> #  Task Priority Levels (TPLs), install EFI Driver Model related
>> #  protocols, manage Unicode string tables for UEFI Drivers, and print
>> #  messages on the console output and standard error devices.
>> 
>> I recommend always reading the INF file comments, they are very-very
>> useful most of the time.
>> 
>> Finally, just loading a UEFI_DRIVER into memory and running it will do
>> nothing for binding devices (as long as the driver conforms to the UEFI
>> driver model, which I assume your driver does, based on the above). Such
>> drivers only install their driver binding protocol instance(s) in their
>> entry points, and then exit. Those Supported(), Start(), and Stop()
>> functions have to be called by something. They are called by the
>> gBS->ConnectController() boot service, which in turn is exposed in the
>> shell with the CONNECT command. Please see the documentation / help text
>> on it.
>> 
>> So I recommend:
>> - flip your module type to UEFI_DRIVER,
>> - once the driver is loaded, try a recursive CONNECT from the shell.
>> 
>> Hope this helps,
> 
> Definitely!  I appreciate your detailed explanation, that should be
> plenty to get me in the right direction.  UEFI_DRIVER is definitely the
> module type I should be using based on your info.
> 
> One follow-up question: the LOAD command in the UEFI Shell 2.2 spec says
> LOAD without -nc tries to connect the driver to a proper device; is this
> different from ConnectController() that the CONNECT command uses?
> 

David,

Yes everything is calling gBS->ConnectConroller() under the hood. 

Thanks,

Andrew Fish

> Regards,
> David
> 
>> Laszlo
>> _______________________________________________
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
>> 
> 
> -- 
> Regards,
> David Van Arnem
> Development Engineer IV
> Computer Measurement Laboratory, LLC
> 
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel