From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=17.151.62.67; helo=nwk-aaemail-lapp02.apple.com; envelope-from=afish@apple.com; receiver=edk2-devel@lists.01.org Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.67]) (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 F27EA2111B78D for ; Wed, 5 Sep 2018 11:03:52 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.22/8.16.0.22) with SMTP id w85HukaH018506; Wed, 5 Sep 2018 11:03:49 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : from : message-id : subject : date : in-reply-to : cc : to : references; s=20180706; bh=oqWUZjARLk8Jdz239KR0+eD8SyWKFTZHSEQX/qi2JnY=; b=J4NFTMRGreWeCoRoWwHCtxYbRDbDXh+d5Qi7oKKBbHzIFjPbMCdxOE4nIaW+/H1wgPoe C4D6Xh67+sPZXBfTx1m3COp3xo2h0kOqGKmL36vsEy8yrbpbS5T11bFScTA9ER6X0qD2 tAqi2Wjrr241F0gKYquvQdtkLJ1MTTAJPmZ9ui+LlVdxTC2irIyC7zkVQln+BJDnJURL pK52NQ4e3INaUh7Tsc8yRIo6cbjR5Z8FdAcgS8eXh8Aahv5PjqvgGqffeAyIv5xBuphe TTfoL9tnwmof5F/vAg+lVnEQHb05dS5JMhYiZHnqLyXJbVpdivnBel4lG1l+GRaqrHN7 EQ== Received: from mr2-mtap-s03.rno.apple.com (mr2-mtap-s03.rno.apple.com [17.179.226.135]) by nwk-aaemail-lapp02.apple.com with ESMTP id 2m7qbppu06-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 05 Sep 2018 11:03:48 -0700 MIME-version: 1.0 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by mr2-mtap-s03.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PEL008HWGUAFX60@mr2-mtap-s03.rno.apple.com>; Wed, 05 Sep 2018 11:03:47 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PEL00300GDTLL00@nwk-mmpp-sz12.apple.com>; Wed, 05 Sep 2018 11:03:46 -0700 (PDT) X-Va-A: X-Va-T-CD: 81ca60fce39c2560b6c4a7e5841f9b8f X-Va-E-CD: 5cce92e979dc82d2dd4d76128a280c0f X-Va-R-CD: 0972fc81b48dbbdab5e0f3435d1cb1dc X-Va-CD: 0 X-Va-ID: bb59c405-722d-4625-ab8a-417cef80ab41 X-V-A: X-V-T-CD: 81ca60fce39c2560b6c4a7e5841f9b8f X-V-E-CD: 5cce92e979dc82d2dd4d76128a280c0f X-V-R-CD: 0972fc81b48dbbdab5e0f3435d1cb1dc X-V-CD: 0 X-V-ID: 2b1eb28b-310a-4726-9a99-7748c43f0bcc Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PEL00500GIN3400@nwk-mmpp-sz12.apple.com>; Wed, 05 Sep 2018 11:03:45 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-09-05_10:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp17.corp.apple.com-10000_instance1 Received: from [17.235.53.229] (unknown [17.235.53.229]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PEL00019GU4X290@nwk-mmpp-sz12.apple.com>; Wed, 05 Sep 2018 11:03:42 -0700 (PDT) Sender: afish@apple.com From: Andrew Fish Message-id: Date: Wed, 05 Sep 2018 11:03:55 -0700 In-reply-to: <9FF5C684-0DA6-45B0-93D8-F6358ACF1C7A@intel.com> Cc: Leif Lindholm , "edk2-devel@lists.01.org" , "Ni, Ruiyu" , Alexander Graf , Heinrich Schuchardt , AKASHI Takahiro , Mike Kinney , Laszlo Ersek To: "Carsey, Jaben" References: <20180905172546.hxc2vqn6pgmr2zqs@bivouac.eciton.net> <9FF5C684-0DA6-45B0-93D8-F6358ACF1C7A@intel.com> X-Mailer: Apple Mail (2.3445.6.18) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-05_10:, , signatures=0 X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: portability of ShellPkg X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 18:03:53 -0000 Content-Type: text/plain; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT > On Sep 5, 2018, at 10:30 AM, Carsey, Jaben wrote: > > How does removing a lib from the components section affect the shell binary output? > > Is the asset at compile time? Jaben, The issue is likely with the HOB lib constructor in the Shell iASSERTing. Leif's example platform supports UEFI, but not PI so it is not expected that HOBs exist. The library has an explicit assumption that HOBs exist, and that is not the case in Leif's platform. https://github.com/tianocore/edk2/blob/master/MdePkg/Library/DxeHobLib/HobLib.c#L54 VOID *mHobList = NULL; /** Returns the pointer to the HOB list. This function returns the pointer to first HOB in the list. For PEI phase, the PEI service GetHobList() can be used to retrieve the pointer to the HOB list. For the DXE phase, the HOB list pointer can be retrieved through the EFI System Table by looking up theHOB list GUID in the System Configuration Table. Since the System Configuration Table does not exist that the time the DXE Core is launched, the DXE Core uses a global variable from the DXE Core Entry Point Library to manage the pointer to the HOB list. If the pointer to the HOB list is NULL, then ASSERT(). This function also caches the pointer to the HOB list retrieved. @return The pointer to the HOB list. **/ VOID * EFIAPI GetHobList ( VOID ) { EFI_STATUS Status; if (mHobList == NULL) { Status = EfiGetSystemConfigurationTable (&gEfiHobListGuid, &mHobList); ASSERT_EFI_ERROR (Status); ASSERT (mHobList != NULL); } return mHobList; } /** The constructor function caches the pointer to HOB list by calling GetHobList() and will always return EFI_SUCCESS. @param ImageHandle The firmware allocated handle for the EFI image. @param SystemTable A pointer to the EFI System Table. @retval EFI_SUCCESS The constructor successfully gets HobList. **/ EFI_STATUS EFIAPI HobLibConstructor ( IN EFI_HANDLE ImageHandle, IN EFI_SYSTEM_TABLE *SystemTable ) { GetHobList (); return EFI_SUCCESS; } /** Returns the next instance of a HOB type from the starting HOB. This function searches the first instance of a HOB type from the starting HOB pointer. If there does not exist such HOB type from the starting HOB pointer, it will return NULL. In contrast with macro GET_NEXT_HOB(), this function does not skip the starting HOB pointer unconditionally: it returns HobStart back if HobStart itself meets the requirement; caller is required to use GET_NEXT_HOB() if it wishes to skip current HobStart. If HobStart is NULL, then ASSERT(). @param Type The HOB type to return. @param HobStart The starting HOB pointer to search from. @return The next instance of a HOB type from the starting HOB. **/ VOID * EFIAPI GetNextHob ( IN UINT16 Type, IN CONST VOID *HobStart ) { EFI_PEI_HOB_POINTERS Hob; ASSERT (HobStart != NULL); Hob.Raw = (UINT8 *) HobStart; // // Parse the HOB list until end of list or matching type is found. // while (!END_OF_HOB_LIST (Hob)) { if (Hob.Header->HobType == Type) { return Hob.Raw; } Hob.Raw = GET_NEXT_HOB (Hob); } return NULL; } Thanks, Andrew Fish > > Jaben > >> On Sep 5, 2018, at 10:26 AM, Leif Lindholm wrote: >> >> Hi all, >> >> (This is partly a summary of discussions that have been held on IRC >> and offline, with Alex Graf and Mike Kinney.) >> >> The UEFI Shell, as produced by the contents of ShellPkg, is needed for >> running the UEFI SCT. This has never been problematic before - but now >> we are starting to run SCT on the U-Boot implementation of the UEFI >> interfaces, certain implicit assumptions may need to be made explicit, >> and perhaps reevaluated. >> >> My feeling is the following: >> - The MinUefiShell variant should be sufficient to run SCT. >> - The UEFI Shell as provided by ShellPkg (any flavour) should run on >> any valid UEFI implementation. Where underlying functionality is >> missing for certain commands, those commands should be >> degraded/disabled to let remaining commands function. >> >> Ideally, I would like to see a Readme.md in ShellPkg, basically >> providing a mission statement. I could write one, but I expect the >> people who actually maintain it would be better suited :) >> >> We currently have an issue with running the shell on U-Boot because >> even MinUefiShell pulls in UefiShellDebug1CommandsLib.inf. This >> appears to be inadvertent, since it is also included a few lines >> further down inside an !ifndef $(NO_SHELL_PROFILES) guard. >> So I would propose the following patch (and can send it out properly >> if the maintainers agree): >> >> diff --git a/ShellPkg/ShellPkg.dsc b/ShellPkg/ShellPkg.dsc >> index 59dd07e0ae..c852abd3f7 100644 >> --- a/ShellPkg/ShellPkg.dsc >> +++ b/ShellPkg/ShellPkg.dsc >> @@ -101,7 +101,6 @@ [Components] >> ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.inf >> ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.inf >> ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1CommandsLib.inf >> - ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf >> ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.inf >> ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.inf >> >> The reason this causes a problem is because this module has a >> dependency on HobLib, which ASSERTS if it does not find any HOBs lying >> around. Since HOBs are a PI concept rather than a UEFI concept, >> ideally we would not terminate the shell if they are missing. However, >> since the HobLib is generic to EDK2, we also shouldn't just go >> stripping ASSERTs out of it. The above patch gives us a way of >> unblocking the SCT on U-Boot UEFI while we consider what to do about >> the bigger question. >> >> Thoughts? >> >> / >> Leif