[U-Boot] [PATCH 02/11] efi_loader: Initial HII protocols

[AKASHI, Takahiro <takahiro.akashi@linaro.org>]

On Fri, Oct 05, 2018 at 03:06:52PM +0200, Alexander Graf wrote:
> On 10/05/2018 11:49 AM, Leif Lindholm wrote:
> >On Fri, Oct 05, 2018 at 05:52:09PM +0900, AKASHI, Takahiro wrote:
> >>>>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?)
> >>One more question:
> >>Does u-boot support any kind of "UEFI driver"?
> >>If yes, is there any good example?
> >>If no, do you expect that it should be supported?
> >I don't think full-on option ROMs with configuration menus are
> >something we care about for EBBR-style implementations.
> >What could be useful is things like shim - a simple driver installing
> >a protocol that lets other applications running at boot-time access
> >it. But I think that is already (mostly?) supported.
> 
> That works, iPXE also works. But neither use HII from what I'm aware of.

After all, do both of you say that we neither have to have
Config Routing nor Config Access Protocol for now?

> >If someone at a later date decides that they want to support option
> >ROMs, basically using U-Boot for an SBBR implementation, that will
> >come with additional work required for the menu support. And should be
> >possible to configure out at build time for users who don't want it.
> 
> Yeah, IMHO for HII we can treat it as a Shell.efi only wart we have to live
> with, but implement as little as we can get away with.

Do you have any specific idea about what is really missing
in Leif's/Rob's HII patch?
(My original question.)

-Takahiro Akashi

> 
> Alex
>