> On Oct 5, 2016, at 1:53 PM, Daniil Egranov <daniil.egra...@arm.com> wrote: > > > > On 10/05/2016 02:48 PM, Andrew Fish wrote: >>> On Oct 5, 2016, at 12:24 PM, Daniil Egranov <daniil.egra...@arm.com> 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. >
Daniil, Sorry, I was assuming the UefiShellLib only supported UEFI Applications. Thats what I get for not looking at the code :(, my bad. https://github.com/tianocore/edk2/blob/master/ShellPkg/Library/UefiShellLib/UefiShellLib.inf#L23 <https://github.com/tianocore/edk2/blob/master/ShellPkg/Library/UefiShellLib/UefiShellLib.inf#L23> LIBRARY_CLASS = ShellLib|UEFI_APPLICATION UEFI_DRIVER DXE_RUNTIME_DRIVER DXE_DRIVER Given the library supports DXE_RUNTIME_DRIVER and DXE_DRIVER I think you are right it should publish a Depex if it has a hard dependency. I'm guessing that your DXE Driver is dispatching prior UEFI Driver that publishes the protocol. Thanks, Andrew Fish >> >> >>> 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.car...@intel.com] >>>> Sent: Wednesday, October 05, 2016 10:41 AM >>>> To: Supreeth Venkatesh <supreeth.venkat...@arm.com>; edk2-devel-01 >>>> <edk2-devel@lists.01.org>; Shah, Tapan <tapands...@hpe.com> >>>> Cc: Leif Lindholm <leif.lindh...@arm.com>; Carsey, Jaben >>>> <jaben.car...@intel.com> >>>> 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-boun...@lists.01.org] On Behalf Of >>>>> Supreeth Venkatesh >>>>> Sent: Tuesday, October 04, 2016 3:51 PM >>>>> To: edk2-devel-01 <edk2-devel@lists.01.org> >>>>> Cc: Leif Lindholm <leif.lindh...@arm.com> >>>>> 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 > > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org> > https://lists.01.org/mailman/listinfo/edk2-devel > <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
