From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 4C4841A1E31 for ; Wed, 5 Oct 2016 14:04:36 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CFEF0635D7; Wed, 5 Oct 2016 21:04:35 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-104.phx2.redhat.com [10.3.116.104]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u95L4YxE031242; Wed, 5 Oct 2016 17:04:34 -0400 To: Daniil Egranov , Andrew Fish References: <93F01BC9-4B02-467E-B900-65C6775BB0F3@apple.com> <6ac805ec-66c2-a291-7852-3429efa018cd@arm.com> Cc: "Carsey, Jaben" , edk2-devel-01 , Leif Lindholm From: Laszlo Ersek Message-ID: Date: Wed, 5 Oct 2016 23:04:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <6ac805ec-66c2-a291-7852-3429efa018cd@arm.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Wed, 05 Oct 2016 21:04:35 +0000 (UTC) Subject: Re: Assert in ShellPkg with latest tianocore edk2 source on the Reference Platform 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: Wed, 05 Oct 2016 21:04:36 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 10/05/16 22:53, Daniil Egranov wrote: > > > On 10/05/2016 02:48 PM, Andrew Fish wrote: >>> On Oct 5, 2016, at 12:24 PM, Daniil Egranov >>> wrote: >>> >>> I have the same ASSERT issue on Juno platform even the EnglishDxe.inf >>> is included to the platform build. If UefiShellLib has such >>> dependency on the protocol then according to EDKII Module Writer's >>> Guide you need to specify the dependency on protocol in the module >>> .inf to ensure the drivers proper load sequence. >>> >>> 8.6 Dependency Expressions >>> A dependency expression specifies the protocols that the DXE driver >>> requires to >>> execute. In EDK II, it is specified in the [Depex] section of INF file. >>> >> The Dependency Expression is for DXE Drivers that are dispatched by >> the DXE Core. A UEFI Driver from an option ROM or an Application does >> not get dispatched by the dispatch and the Depex will not help. The >> Depex ends up being a section in the FV and it has nothing to do with >> the PE/COFF image of the an application or option ROM. >> >> IMHO the shell should try as hard as possible to function and should >> not ASSERT if some newer Protocol is missing. >> >> Thanks, >> >> Andre wFish > I had to put a context of the ASSERT message in the original message to > make it more clear: > > add-symbol-file > /home/user1/workspace/juno_16.09/uefi/edk2/Build/ArmJuno/DEBUG_GCC49/AARCH64/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe/DEBUG/ArmJunoDxe.dll > 0xF8AB9000 > Loading driver at 0x000F8AB8000 EntryPoint=0x000F8AB9048 ArmJunoDxe.efi > > ASSERT_EFI_ERROR (Status = Not Found) > ASSERT [ArmJunoDxe] > /home/danegr01/workspace/juno_16.09/uefi/edk2/ShellPkg/Library/UefiShellLib/UefiShellLib.c(305): > !EFI_ERROR (Status) > > If driver includes a module which has dependency on one of the > protocols, should the driver know about this dependency? Probably not. > It should be inherited from the module. Adding [Depex] to UefiShellLib > corrected dispatching ArmJunoDxe and EnglishDxe by the Dxe Core. You are right; Tim confirmed UefiShellLib is valid to use in DXE_RUNTIME_DRIVER and DXE_DRIVER modules, and ArmJunoDxe is a DXE_DRIVER. This additional information also explains why you see the change as a regression, but have had a working shell all this time -- due to the missing depex, ArmJunoDxe got dispatched earlier and experienced the regression, but the shell app itself (being a UEFI application) found the collation protocol (provided by EnglishDxe) just fine. So, your suggestion about the depex solves the problem for drivers, on platforms that provide the collation protocol, but it doesn't solve the (separate) problem of the shell app proper, on platforms that don't provide the collation protocol at all. Thanks Laszlo