From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 3CEEE82113 for ; Wed, 8 Feb 2017 16:49:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1486601383; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=CrOTe85icVF6Nu4yWRyKklWx9QTPNxUGrfwaOj/9iEI=; b=b9qqsoohq9msniNkF7rP+ZHv7/x7MskGdTqvbgHyY6aXCZ5V951GXIVMgCBhp2FZ e+hYnxVFliP/PeUx7rRLsm+sRqYQ62kN11auQYgg9iVdwl2hUjRCMLMAqeasRGWM olzbx+DNp3JZffof+ga/uxPjmcIa1iA+taq+0f1iDbHtJs9bq81YPnJzUily/X+l vE8tZ/oV7BBtPKPe5V3G4Y2VW+otnZ9QD6mzPvhTNzw4srOVyIFxlN4tuIldrVkR 17Xxqdsrln0Dd+6VyANARtf+MRSsGLZKgPt/GCKsnOhIkGhNMzZE0E8W6d5ctS33 g2qM1O5XoDXwSHKQhY4AVw==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 5D.9C.19279.7ACBB985; Wed, 8 Feb 2017 16:49:43 -0800 (PST) X-AuditID: 11973e11-2d8ea9a000004b4f-d1-589bbca7820b Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by relay5.apple.com (Apple SCV relay) with SMTP id 85.50.05881.7ACBB985; Wed, 8 Feb 2017 16:49:43 -0800 (PST) MIME-version: 1.0 Received: from [17.114.152.165] (unknown [17.114.152.165]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.1.2.0 64bit (built Dec 14 2016)) with ESMTPSA id <0OL300MNR0XJ7810@nwk-mmpp-sz12.apple.com>; Wed, 08 Feb 2017 16:49:43 -0800 (PST) Sender: afish@apple.com From: Andrew Fish In-reply-to: <990d42be-7d48-7993-e655-0f1718af0dc1@cmlab.biz> Date: Wed, 08 Feb 2017 16:49:43 -0800 Cc: Laszlo Ersek , "edk2-devel@ml01.01.org" Message-id: References: <4a3de604-5e60-7ed2-e520-29ab6b551c33@cmlab.biz> <09c11a95-99e2-eb82-304b-c294b4785841@redhat.com> <990d42be-7d48-7993-e655-0f1718af0dc1@cmlab.biz> To: "David A. Van Arnem" X-Mailer: Apple Mail (2.3226) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUi2FAYobt8z+wIg1vt1haL1khZrNvzjd1i 2bEdLA7MHie+BnhMuvCY2eP9vqtsAcxRXDYpqTmZZalF+nYJXBnvmpeyFTzWrDh9ay5rA+NF xS5GTg4JAROJnaumMIPYQgJ7GSV2XyiEiU/595q1i5ELKH6IUeLr7V9sIAleAUGJH5PvsXQx cnAwC8hLHDwvCxJmFtCS+P6olQViTg+TxMWLjCC2sIC4xLszm5ghbE2JtQfuMoHYbALKEivm f2AHsTkFbCW+tjazgoxkEVCVaL2cCTEyUmLfxOvsEFttJHZ9Xs4Occ5iRolrL1eBJUQE9CSW LHnLDNIrISArMfuXF0iNhMABNommd3eZJjAKz0Jy9SyEq2chuXoBI/MqRqHcxMwc3cw8I73E goKcVL3k/NxNjKAgn24nuIPx+CqrQ4wCHIxKPLwXrGdHCLEmlhVX5h5ilOZgURLnFTaZGSEk kJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBsfWLfdxDvd/73tQkhbslurzeO78xaZsVx/5Dyh/U IiROap/J3L73fSjP6XNLreWk1thO+f7Otn97iHFSbWbR38+GK65PS029ZxjTdZbPeH5h34GP M3Y9nP23d/tvhbrVZ/6fSefaLrjdKs9GOiZD8+nz6zeVVnC07QnZ9aD59pf+dTL9dR9Y/imx FGckGmoxFxUnAgDJVMMOUwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42IRbCg+o7t8z+wIg7nHTSwWrZGyWLfnG7vF smM7WByYPU58DfCYdOExs8f7fVfZApijuGxSUnMyy1KL9O0SuDLeNS9lK3isWXH61lzWBsaL il2MnBwSAiYSU/69ZoWwxSQu3FvP1sXIxSEkcIhR4uvtX2wgCV4BQYkfk++xdDFycDALyEsc PC8LEmYW0JL4/qiVBcQWEuhhkrh4kRHEFhYQl3h3ZhMzhK0psfbAXSYQm01AWWLF/A/sIDan gK3E19ZmVpCRLAKqEq2XMyFGRkrsm3idHWKrjcSuz8vZIc5ZzChx7eUqsISIgJ7EkiVvmUF6 JQRkJWb/8prAKDgLyaGzEA6dheTQBYzMqxgFilJzEitN9RILCnJS9ZLzczcxgsO1MGIH4/9l VocYBTgYlXh4L1jPjhBiTSwrrswFhgQHs5IIb+kmoBBvSmJlVWpRfnxRaU5q8SHGZKDzJzJL iSbnA2MpryTe0MTEwMTY2MzY2NzEnDRhJXFez/0zIoQE0hNLUrNTUwtSi2C2MHFwSjUwRlsV KsXui7qt9bjjsIiBVfDq5d+9BPyOlfK6M1WzWiheF/xoIXrWqOGu4EcH+4rAvlOdnrYnF3t2 1c++HObMVtlxyymA/19xvyZ3pZeRV1uN+Jn6zpKP/7O2NajreaU7ChzabXvg57aJejP+hNuq Nf37duehSc6JNsUjaxLuZDr8/T/LMVyJpTgj0VCLuag4EQDYy10NmwIAAA== Subject: Re: Print from DXE_DRIVER X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 00:49:44 -0000 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII > On Feb 8, 2017, at 4:41 PM, David A. Van Arnem 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 .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