[U-Boot] [PATCH 02/11] efi_loader: Initial HII protocols
AKASHI, Takahiro
takahiro.akashi at linaro.org
Wed Oct 3 07:39:09 UTC 2018
Alex,
On Sun, Sep 23, 2018 at 12:11:08PM +0200, Alexander Graf wrote:
>
>
> On 22.09.18 12:34, Heinrich Schuchardt wrote:
> > On 10/10/2017 02:22 PM, Rob Clark wrote:
> >> From: Leif Lindholm <leif.lindholm at linaro.org>
> >>
> >> Enough implementation of the following protocols to run Shell.efi and
> >> SCT.efi:
> >>
> >> EfiHiiConfigRoutingProtocolGuid
> >> EfiHiiDatabaseProtocol
> >> EfiHiiStringProtocol
> >
> > The i386 Shell.efi also tries to open these before failing:
> >
> > EfiHiiFontProtocol
> > EfiHiiImageProtocol
>
> That sounds like a bug. The UEFI spec only mandates the following in
> section 2.6.2:
>
> 2. If a platform includes a configuration infrastructure, then the
> EFI_HII_DATABASE_PROTOCOL, EFI_HII_STRING_PROTOCOL,
> EFI_HII_CONFIG_ROUTING_PROTOCOL, and EFI_HII_CONFIG_ACCESS_PROTOCOL are
> required.
Do you think efi implementation on u-boot also wants those protocols?
(Apparently, config access protocol can be optional for shell unless
we want driver configuration?)
Among others, UEFI spec defines lots of "packages" for HII database:
string, guid, font, image, device path, keyboard layout and etc.
Do you expect all of them be supported from the beginning?
If not, what criteria do you think is reasonable so that you feel
comfortable in accepting an initial commit of HII database support?
Thanks,
-Takahiro Akashi
> If you support bitmapped fonts, you must support
> EFI_HII_FONT_PROTOCOL.
> Well, in my book the whole fact that the UEFI shell requires HII sounds
> like a bad design decision, but it should at least not require the font
> protocol :).
>
> Also, I have built my own x86_64 shell.efi from latest edk2 git manually
> and that works fine (even in sandbox). Maybe that is only the minimal
> shell though? Their build system is still a bit of a mystery to me :).
>
>
> Alex
More information about the U-Boot
mailing list