Print from DXE_DRIVER

Print from DXE_DRIVER

[David A. Van Arnem]

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!

-- 
Regards,
David Van Arnem
Development Engineer IV
Computer Measurement Laboratory, LLC

Re: Print from DXE_DRIVER

[Laszlo Ersek]

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,
Laszlo

Re: Print from DXE_DRIVER

[David A. Van Arnem]

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?

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

Re: Print from DXE_DRIVER

[Andrew Fish]

> 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

Re: Print from DXE_DRIVER

[Andrew Fish]

> On Feb 8, 2017, at 2:10 PM, David A. Van Arnem <dvanarnem@cmlab.biz> 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.

Prints are not allowed in drivers as they are likely to break the UI. 

>  Thus I have put
> a print statement in each of my Supported(),

Don't do that Supported gets called a lot. Well it is OK if you conditionally print. 

> 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.  

You should be able to use shell commands to see if you driver is connected. 

> 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?

Print() is part of the UefiLib. The PrintLib vends sprintf kinds of things. 

>  If not,
> would changing it to a UEFI_DRIVER help?  Any other recommendations?
> 

If you are publishing driver binding protocol you should be UEFI_DRIVER, if possible. 

> If there is an example in edk2 that does this that you could point me
> to, that would be sufficient as well.  Thanks!
> 

If  you want to write directly to the UEFI Console you can try this. Place it in the entry point of your driver in case you have some bug that is preventing your from registering the Driver Binding Protocol. 

gST->ConOut->OutputString (gST->ConOut, L"Hello World\n\r");

Make sure you use  L"" vs "" as Print takes a CHAR16 and %s also default to CHAR16 (not ASCII)



Thanks,

Andrew Fish


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

Re: Print from DXE_DRIVER

[David A. Van Arnem]

On 02/08/2017 05:43 PM, Andrew Fish wrote:
> 
>> On Feb 8, 2017, at 2:10 PM, David A. Van Arnem <dvanarnem@cmlab.biz> wrote:
>>

<snip>

>> 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.  
> 
> You should be able to use shell commands to see if you driver is connected. 

dh output does show my <drivername>.efi at the end which I think
indicates it is connected.

> 
>> 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?
> 
> Print() is part of the UefiLib. The PrintLib vends sprintf kinds of things. 
> 
>>  If not,
>> would changing it to a UEFI_DRIVER help?  Any other recommendations?
>>
> 
> If you are publishing driver binding protocol you should be UEFI_DRIVER, if possible. 
> 
>> If there is an example in edk2 that does this that you could point me
>> to, that would be sufficient as well.  Thanks!
>>
> 
> If  you want to write directly to the UEFI Console you can try this. Place it in the entry point of your driver in case you have some bug that is preventing your from registering the Driver Binding Protocol. 
> 
> gST->ConOut->OutputString (gST->ConOut, L"Hello World\n\r");
> 
> Make sure you use  L"" vs "" as Print takes a CHAR16 and %s also default to CHAR16 (not ASCII)

I will try that, thank you!

Regards,
David

> 
> 
> 
> Thanks,
> 
> Andrew Fish
> 
> 
>> -- 
>> 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
> 
> _______________________________________________
> 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

Re: Print from DXE_DRIVER

[Andrew Fish]

> On Feb 8, 2017, at 4:49 PM, David A. Van Arnem <dvanarnem@cmlab.biz> wrote:
> 
> 
> 
> On 02/08/2017 05:43 PM, Andrew Fish wrote:
>> 
>>> On Feb 8, 2017, at 2:10 PM, David A. Van Arnem <dvanarnem@cmlab.biz <mailto:dvanarnem@cmlab.biz>> wrote:
>>> 
> 
> <snip>
> 
>>> 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.  
>> 
>> You should be able to use shell commands to see if you driver is connected. 
> 
> dh output does show my <drivername>.efi at the end which I think
> indicates it is connected.
> 

dh is just showing handles and protocols not what happened with Driver Binding. So likely you are seeing that your driver got loaded. 

Run `drivers` or `devtree` to see the results of the connect.

>> 
>>> 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?
>> 
>> Print() is part of the UefiLib. The PrintLib vends sprintf kinds of things. 
>> 
>>> If not,
>>> would changing it to a UEFI_DRIVER help?  Any other recommendations?
>>> 
>> 
>> If you are publishing driver binding protocol you should be UEFI_DRIVER, if possible. 
>> 
>>> If there is an example in edk2 that does this that you could point me
>>> to, that would be sufficient as well.  Thanks!
>>> 
>> 
>> If  you want to write directly to the UEFI Console you can try this. Place it in the entry point of your driver in case you have some bug that is preventing your from registering the Driver Binding Protocol. 
>> 
>> gST->ConOut->OutputString (gST->ConOut, L"Hello World\n\r");
>> 
>> Make sure you use  L"" vs "" as Print takes a CHAR16 and %s also default to CHAR16 (not ASCII)
> 

Here is a write up on how Print is different than printf.

https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Library/PrintLib.h#L26 <https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Library/PrintLib.h#L26>

Thanks,

Andrew Fish

> I will try that, thank you!
> 
> Regards,
> David
> 
>> 
>> 
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>> 
>>> -- 
>>> 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
>> 
>> _______________________________________________
>> 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

Re: Print from DXE_DRIVER

[Gao, Liming]

You can use DebugLib, and link MdePkg\Library\UefiDebugLibConOut\UefiDebugLibConOut.inf to print error message to Console. 

DEBUG ((DEBUG_INFO, "Hello Workd\n"));

Thanks
Liming
-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Andrew Fish
Sent: Thursday, February 9, 2017 9:05 AM
To: David A. Van Arnem <dvanarnem@cmlab.biz>
Cc: edk2-devel@ml01.01.org
Subject: Re: [edk2] Print from DXE_DRIVER


> On Feb 8, 2017, at 4:49 PM, David A. Van Arnem <dvanarnem@cmlab.biz> wrote:
> 
> 
> 
> On 02/08/2017 05:43 PM, Andrew Fish wrote:
>> 
>>> On Feb 8, 2017, at 2:10 PM, David A. Van Arnem <dvanarnem@cmlab.biz <mailto:dvanarnem@cmlab.biz>> wrote:
>>> 
> 
> <snip>
> 
>>> 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.  
>> 
>> You should be able to use shell commands to see if you driver is connected. 
> 
> dh output does show my <drivername>.efi at the end which I think
> indicates it is connected.
> 

dh is just showing handles and protocols not what happened with Driver Binding. So likely you are seeing that your driver got loaded. 

Run `drivers` or `devtree` to see the results of the connect.

>> 
>>> 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?
>> 
>> Print() is part of the UefiLib. The PrintLib vends sprintf kinds of things. 
>> 
>>> If not,
>>> would changing it to a UEFI_DRIVER help?  Any other recommendations?
>>> 
>> 
>> If you are publishing driver binding protocol you should be UEFI_DRIVER, if possible. 
>> 
>>> If there is an example in edk2 that does this that you could point me
>>> to, that would be sufficient as well.  Thanks!
>>> 
>> 
>> If  you want to write directly to the UEFI Console you can try this. Place it in the entry point of your driver in case you have some bug that is preventing your from registering the Driver Binding Protocol. 
>> 
>> gST->ConOut->OutputString (gST->ConOut, L"Hello World\n\r");
>> 
>> Make sure you use  L"" vs "" as Print takes a CHAR16 and %s also default to CHAR16 (not ASCII)
> 

Here is a write up on how Print is different than printf.

https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Library/PrintLib.h#L26 <https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Library/PrintLib.h#L26>

Thanks,

Andrew Fish

> I will try that, thank you!
> 
> Regards,
> David
> 
>> 
>> 
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>> 
>>> -- 
>>> 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
>> 
>> _______________________________________________
>> 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

Re: Print from DXE_DRIVER

[Rebecca Cran]

> On Feb 8, 2017, at 5:43 PM, Andrew Fish <afish@apple.com> wrote:
> 
> If  you want to write directly to the UEFI Console you can try this. Place it in the entry point of your driver in case you have some bug that is preventing your from registering the Driver Binding Protocol. 
> 
> gST->ConOut->OutputString (gST->ConOut, L"Hello World\n\r");

Note that on some systems, at some times gST->ConOut may be NULL, so it might be worth checking before calling it (unless you know otherwise on your dev system).

-- 
Rebecca

Re: Print from DXE_DRIVER

[Tim Lewis]

Also, on many systems, the output will be invisible, since boot screen output is a platform policy. In general, using DEBUG() is better, since it can either be redirected to StdErr() or through the serial port.

Tim

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Rebecca Cran
Sent: Wednesday, February 08, 2017 6:56 PM
To: Andrew Fish <afish@apple.com>
Cc: edk2-devel@ml01.01.org; David A. Van Arnem <dvanarnem@cmlab.biz>
Subject: Re: [edk2] Print from DXE_DRIVER


> On Feb 8, 2017, at 5:43 PM, Andrew Fish <afish@apple.com> wrote:
> 
> If  you want to write directly to the UEFI Console you can try this. Place it in the entry point of your driver in case you have some bug that is preventing your from registering the Driver Binding Protocol. 
> 
> gST->ConOut->OutputString (gST->ConOut, L"Hello World\n\r");

Note that on some systems, at some times gST->ConOut may be NULL, so it might be worth checking before calling it (unless you know otherwise on your dev system).

-- 
Rebecca
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: Print from DXE_DRIVER

[David A. Van Arnem]

On 02/08/2017 07:59 PM, Tim Lewis wrote:
> Also, on many systems, the output will be invisible, since boot screen output is a platform policy. In general, using DEBUG() is better, since it can either be redirected to StdErr() or through the serial port.
> 
> Tim

Thanks all, I do have some experience with using DEBUG() so I will take
that approach (and as Andrew said, that way the DEBUG() output can be
conditionally filtered based on priority so once I verify through that
and shell commands I can turn them off easily).

David
> 
> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Rebecca Cran
> Sent: Wednesday, February 08, 2017 6:56 PM
> To: Andrew Fish <afish@apple.com>
> Cc: edk2-devel@ml01.01.org; David A. Van Arnem <dvanarnem@cmlab.biz>
> Subject: Re: [edk2] Print from DXE_DRIVER
> 
> 
>> On Feb 8, 2017, at 5:43 PM, Andrew Fish <afish@apple.com> wrote:
>>
>> If  you want to write directly to the UEFI Console you can try this. Place it in the entry point of your driver in case you have some bug that is preventing your from registering the Driver Binding Protocol. 
>>
>> gST->ConOut->OutputString (gST->ConOut, L"Hello World\n\r");
> 
> Note that on some systems, at some times gST->ConOut may be NULL, so it might be worth checking before calling it (unless you know otherwise on your dev system).
> 

-- 
Regards,
David Van Arnem
Development Engineer IV
Computer Measurement Laboratory, LLC