From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from server202.webhostingpad.com (server202mail.webhostingpad.com [50.31.162.9]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 79D348210F for ; Wed, 8 Feb 2017 16:41:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cmlab.biz; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=p9jDBNXurC/i7GB/6JgModFDTGFU/Nac44sa1qbUbQA=; b=DbgJJEZ9zG2U+W7VoKBtGT361a vefzOOC9U+CZBu1NANyQOtP7ojAkUPAHfbmpVzub1tyzWL6m3vt6NQ/ELrv4jlt1/gjv5yJP+rLpn /v/GchHj28R/93uiUKi9WiyDJGEWl50343EofBlfgfip5+rR9KPjw2BQLP8sOPBw9gRE=; Received: from [71.216.152.198] (port=60130 helo=[192.168.50.197]) by server202.webhostingpad.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.87) (envelope-from ) id 1cbcnY-003Vxh-J0; Wed, 08 Feb 2017 18:41:20 -0600 To: Laszlo Ersek , "edk2-devel@ml01.01.org" References: <4a3de604-5e60-7ed2-e520-29ab6b551c33@cmlab.biz> <09c11a95-99e2-eb82-304b-c294b4785841@redhat.com> From: "David A. Van Arnem" Message-ID: <990d42be-7d48-7993-e655-0f1718af0dc1@cmlab.biz> Date: Wed, 8 Feb 2017 17:41:19 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <09c11a95-99e2-eb82-304b-c294b4785841@redhat.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server202.webhostingpad.com X-AntiAbuse: Original Domain - ml01.01.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - cmlab.biz X-Get-Message-Sender-Via: server202.webhostingpad.com: authenticated_id: dvanarnem@cmlab.biz X-Authenticated-Sender: server202.webhostingpad.com: dvanarnem@cmlab.biz X-Source: X-Source-Args: X-Source-Dir: X-Content-Filtered-By: Mailman/MimeDel 2.1.21 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:41:21 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 pu= t >> a print statement in each of my Supported(), Start(), and Stop() >> functions for the driver binding protocol. Currently I am building th= e >> 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 te= st >> both the Supported() and Start() functions, so I would expect to see t= he >> 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 no= t, >> 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! >> >=20 > 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. >=20 > But, I think Print() can be made work too. The only Print() function > that should matter is in "MdePkg/Library/UefiLib/UefiLibPrint.c". It us= es >=20 > gST->ConOut >=20 > 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.) >=20 > 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. >=20 > 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: >=20 > # 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. >=20 > I recommend always reading the INF file comments, they are very-very > useful most of the time. >=20 > 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). Suc= h > 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 tex= t > on it. >=20 > So I recommend: > - flip your module type to UEFI_DRIVER, > - once the driver is loaded, try a recursive CONNECT from the shell. >=20 > 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 >=20 --=20 Regards, David Van Arnem Development Engineer IV Computer Measurement Laboratory, LLC