Re: Assert in ShellPkg with latest tianocore edk2 source on the Reference Platform

[Laszlo Ersek <lersek@redhat.com>]

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 <daniil.egranov@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.

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