From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.101.70]) by ml01.01.org (Postfix) with ESMTP id BBDF51A1E1B for ; Wed, 5 Oct 2016 13:53:23 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 518F329; Wed, 5 Oct 2016 13:53:23 -0700 (PDT) Received: from [192.168.236.128] (u202163.usa.arm.com [10.118.32.36]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 090ED3F218; Wed, 5 Oct 2016 13:53:22 -0700 (PDT) To: Andrew Fish References: <93F01BC9-4B02-467E-B900-65C6775BB0F3@apple.com> Cc: "Carsey, Jaben" , edk2-devel-01 , Leif Lindholm From: Daniil Egranov Message-ID: <6ac805ec-66c2-a291-7852-3429efa018cd@arm.com> Date: Wed, 5 Oct 2016 15:53:22 -0500 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: <93F01BC9-4B02-467E-B900-65C6775BB0F3@apple.com> 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 20:53:23 -0000 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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. > > >> The following dependency in UefiShellLib.inf fixes ASSERT problem: >> >> [Depex] >> gEfiUnicodeCollation2ProtocolGuid >> >> >> Thanks, >> >> Daniil >> >> >> On 10/05/2016 11:02 AM, Shah, Tapan wrote: >>> It's possible. But I think gEfiUnicodeCollation2ProtocolGuid protocol is necessary for even other Shell libraries other than UefiShellLib in order to have Shell parser and other command line processing to work properly. That's why I added ASSERT if UefiShellLib fails to locate the protocol. >>> Reference platform should have EnglishDxe module to have this protocol installed properly. >>> >>> MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf >>> >>> -----Original Message----- >>> From: Carsey, Jaben [mailto:jaben.carsey@intel.com] >>> Sent: Wednesday, October 05, 2016 10:41 AM >>> To: Supreeth Venkatesh ; edk2-devel-01 ; Shah, Tapan >>> Cc: Leif Lindholm ; Carsey, Jaben >>> Subject: RE: Assert in ShellPkg with latest tianocore edk2 source on the Reference Platform >>> >>> Tapan, >>> >>> Could this be a side effect of your patch? Should we allow the UefiShellLib to continue without this protocol and then return an error only when the OpenFile is called? >>> >>> Also, it looks like we never properly initialize mUnicodeCollationProtocol. We check for NULL in Constructor, but nothing else... >>> >>> -Jaben >>> >>>> -----Original Message----- >>>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of >>>> Supreeth Venkatesh >>>> Sent: Tuesday, October 04, 2016 3:51 PM >>>> To: edk2-devel-01 >>>> Cc: Leif Lindholm >>>> Subject: [edk2] Assert in ShellPkg with latest tianocore edk2 source >>>> on the Reference Platform >>>> Importance: High >>>> >>>> All, >>>> >>>> Recently, I updated to latest edk2 master (yesterday's) and I am >>>> actually encountering assert in >>>> ShellPkg/Library/UefiShellLib/UefiShellLib.c >>>> >>>> if (mUnicodeCollationProtocol == NULL) { >>>> Status = gBS->LocateProtocol (&gEfiUnicodeCollation2ProtocolGuid, >>>> NULL, (VOID**)&mUnicodeCollationProtocol); >>>> ASSERT_EFI_ERROR (Status); >>>> } >>>> >>>> It was working few weeks back and has now stopped working. >>>> It's probably because the platform is unable to locate this protocol >>>> "UnicodeCollationProtocol". >>>> Is Anyone else facing the same issue? >>>> Does the new ShellPkg requires additional packages/infs to be included >>>> in the platform description file to work with latest changes to get >>>> past this error? >>>> >>>> Thanks, >>>> Supreeth >>>> IMPORTANT NOTICE: The contents of this email and any attachments are >>>> confidential and may also be privileged. If you are not the intended >>>> recipient, please notify the sender immediately and do not disclose >>>> the contents to any other person, use it for any purpose, or store or >>>> copy the information in any medium. Thank you. >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> 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