On Wed, Sep 05, 2018 at 05:30:23PM +0000, Carsey, Jaben wrote:
> How does removing a lib from the components section affect the shell binary
> output?
Maybe it doesn't and I'm barking up the wrong tree? Unfortunately,
the only thing that means is we don't have a trivial workaround.
/
Leif
> Is the asset at compile time?
>
> Jaben
>
> > On Sep 5, 2018, at 10:26 AM, Leif Lindholm <leif.lindh...@linaro.org> 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
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
