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

2018-10-09 Thread AKASHI, Takahiro 
Heinrich,

On Tue, Oct 09, 2018 at 07:19:58PM +0200, Heinrich Schuchardt wrote:
> On 10/09/2018 09:24 AM, AKASHI, Takahiro wrote:
> > Do you have any specific idea about what is really missing
> > in Leif's/Rob's HII patch?
> > (My original question.)
> > 
> > -Takahiro Akashi
> 
> Please, see https://patchwork.ozlabs.org/patch/823807/

Thanks, I didn't notice this thread.

> Open topics were:
> - usage of bitfields
> - incorrect determination of string lengths
> - too deep nesting of of loops and ifs

Okay, those seem to be easily fixable at a glance.

> - incomplete implementation of the protocols

That is a matter I'm concerned about.
There's no consensus yet about what should be in an "initial" port.

BTW, you said there were some missing protocols to run i386 version
of Shell: EFI HII font protocol and EFI HII Image protocol.
Do you still believe so even after Alex's comment?

Thanks,
-Takahiro Akashi

> As other protocols are based on the HII database protocol we should
> start with this protocol in a separate patch. We should have a unit test
> in lib/efi_selftest/ for all methods of the protocol.
> 
> Best regards
> 
> Heinrich
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

2018-10-09 Thread Heinrich Schuchardt 
On 10/09/2018 09:24 AM, AKASHI, Takahiro wrote:
> Do you have any specific idea about what is really missing
> in Leif's/Rob's HII patch?
> (My original question.)
> 
> -Takahiro Akashi

Please, see https://patchwork.ozlabs.org/patch/823807/

Open topics were:
- usage of bitfields
- incorrect determination of string lengths
- too deep nesting of of loops and ifs
- incomplete implementation of the protocols

As other protocols are based on the HII database protocol we should
start with this protocol in a separate patch. We should have a unit test
in lib/efi_selftest/ for all methods of the protocol.

Best regards

Heinrich
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

2018-10-09 Thread AKASHI, Takahiro 
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
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

2018-10-05 Thread Heinrich Schuchardt 
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"?

I am currently working on patches to fix StartImage(), Exit(), and
UnloadImage() that will enable installing EFI drivers.

Currently the image handle is destroyed when a driver calls Exit().

Regards

Heinrich

>> 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.
> 
> 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.
> 
> /
> Leif
> 

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

2018-10-05 Thread Alexander Graf 

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.


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.



Alex

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

2018-10-05 Thread Leif Lindholm 
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.

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.

/
Leif
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

2018-10-05 Thread AKASHI, Takahiro 
On Wed, 3 Oct 2018 at 16:37, AKASHI, Takahiro
 wrote:
>
> 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 
> > >>
> > >> 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?)

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?

Thanks,
-Takahiro Akashi

> 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
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

2018-10-03 Thread AKASHI, Takahiro 
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 
> >>
> >> 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
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

2018-09-23 Thread Alexander Graf 


On 22.09.18 12:34, Heinrich Schuchardt wrote:
> On 10/10/2017 02:22 PM, Rob Clark wrote:
>> From: Leif Lindholm 
>>
>> 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. 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
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

2018-09-22 Thread Heinrich Schuchardt 
On 10/10/2017 02:22 PM, Rob Clark wrote:
> From: Leif Lindholm 
> 
> 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

Best regards

Heinrich Schuchardt

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

2017-10-12 Thread Alexander Graf 

On 10/12/2017 11:55 AM, Rob Clark wrote:

On Thu, Oct 12, 2017 at 3:13 AM, Alexander Graf  wrote:


On 12.10.17 00:02, Rob Clark wrote:

On Wed, Oct 11, 2017 at 10:30 AM, Alexander Graf  wrote:


On 10.10.17 14:22, Rob Clark wrote:

From: Leif Lindholm 

Enough implementation of the following protocols to run Shell.efi and
SCT.efi:

   EfiHiiConfigRoutingProtocolGuid
   EfiHiiDatabaseProtocol
   EfiHiiStringProtocol

We'll fill in the rest once SCT is running properly so we can validate
the implementation against the conformance test suite.

Initial skeleton written by Leif, and then implementation by myself.

Cc: Leif Lindholm 
Signed-off-by: Rob Clark 
---
  include/efi_api.h | 261 ++
  include/efi_loader.h  |   6 +
  lib/efi_loader/Makefile   |   2 +-
  lib/efi_loader/efi_boottime.c |   9 +
  lib/efi_loader/efi_hii.c  | 507 ++
  5 files changed, 784 insertions(+), 1 deletion(-)
  create mode 100644 lib/efi_loader/efi_hii.c

diff --git a/include/efi_api.h b/include/efi_api.h
index ffdba7fe1a..164147dc87 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -16,6 +16,7 @@
  #define _EFI_API_H

  #include 
+#include 

  #ifdef CONFIG_EFI_LOADER
  #include 
@@ -536,6 +537,266 @@ struct efi_device_path_utilities_protocol {
   uint16_t node_length);
  };

+#define EFI_HII_CONFIG_ROUTING_PROTOCOL_GUID \
+ EFI_GUID(0x587e72d7, 0xcc50, 0x4f79, \
+  0x82, 0x09, 0xca, 0x29, 0x1f, 0xc1, 0xa1, 0x0f)
+
+typedef uint16_t efi_string_id_t;
+
+struct efi_hii_config_routing_protocol {
+ efi_status_t(EFIAPI *extract_config)(
+ const struct efi_hii_config_routing_protocol *this,
+ const efi_string_t request,
+ efi_string_t *progress,
+ efi_string_t *results);
+ efi_status_t(EFIAPI *export_config)(
+ const struct efi_hii_config_routing_protocol *this,
+ efi_string_t *results);
+ efi_status_t(EFIAPI *route_config)(
+ const struct efi_hii_config_routing_protocol *this,
+ const efi_string_t configuration,
+ efi_string_t *progress);
+ efi_status_t(EFIAPI *block_to_config)(
+ const struct efi_hii_config_routing_protocol *this,
+ const efi_string_t config_request,
+ const uint8_t *block,
+ const efi_uintn_t block_size,
+ efi_string_t *config,
+ efi_string_t *progress);
+ efi_status_t(EFIAPI *config_to_block)(
+ const struct efi_hii_config_routing_protocol *this,
+ const efi_string_t config_resp,
+ const uint8_t *block,
+ const efi_uintn_t *block_size,
+ efi_string_t *progress);
+ efi_status_t(EFIAPI *get_alt_config)(
+ const struct efi_hii_config_routing_protocol *this,
+ const efi_string_t config_resp,
+ const efi_guid_t *guid,
+ const efi_string_t name,
+ const struct efi_device_path *device_path,
+ const efi_string_t alt_cfg_id,
+ efi_string_t *alt_cfg_resp);
+};
+
+#define EFI_HII_DATABASE_PROTOCOL_GUID\
+ EFI_GUID(0xef9fc172, 0xa1b2, 0x4693, \
+  0xb3, 0x27, 0x6d, 0x32, 0xfc, 0x41, 0x60, 0x42)
+
+typedef enum {
+ EFI_KEY_LCTRL, EFI_KEY_A0, EFI_KEY_LALT, EFI_KEY_SPACE_BAR,
+ EFI_KEY_A2, EFI_KEY_A3, EFI_KEY_A4, EFI_KEY_RCTRL, EFI_KEY_LEFT_ARROW,
+ EFI_KEY_DOWN_ARROW, EFI_KEY_RIGHT_ARROW, EFI_KEY_ZERO,
+ EFI_KEY_PERIOD, EFI_KEY_ENTER, EFI_KEY_LSHIFT, EFI_KEY_B0,
+ EFI_KEY_B1, EFI_KEY_B2, EFI_KEY_B3, EFI_KEY_B4, EFI_KEY_B5, EFI_KEY_B6,
+ EFI_KEY_B7, EFI_KEY_B8, EFI_KEY_B9, EFI_KEY_B10, EFI_KEY_RSHIFT,
+ EFI_KEY_UP_ARROW, EFI_KEY_ONE, EFI_KEY_TWO, EFI_KEY_THREE,
+ EFI_KEY_CAPS_LOCK, EFI_KEY_C1, EFI_KEY_C2, EFI_KEY_C3, EFI_KEY_C4,
+ EFI_KEY_C5, EFI_KEY_C6, EFI_KEY_C7, EFI_KEY_C8, EFI_KEY_C9,
+ EFI_KEY_C10, EFI_KEY_C11, EFI_KEY_C12, EFI_KEY_FOUR, EFI_KEY_FIVE,
+ EFI_KEY_SIX, EFI_KEY_PLUS, EFI_KEY_TAB, EFI_KEY_D1, EFI_KEY_D2,
+ EFI_KEY_D3, EFI_KEY_D4, EFI_KEY_D5, EFI_KEY_D6, EFI_KEY_D7, EFI_KEY_D8,
+ EFI_KEY_D9, EFI_KEY_D10, EFI_KEY_D11, EFI_KEY_D12, EFI_KEY_D13,
+ EFI_KEY_DEL, EFI_KEY_END, EFI_KEY_PG_DN, EFI_KEY_SEVEN, EFI_KEY_EIGHT,
+ EFI_KEY_NINE, EFI_KEY_E0, EFI_KEY_E1, EFI_KEY_E2, EFI_KEY_E3,
+ EFI_KEY_E4, EFI_KEY_E5, EFI_KEY_E6, EFI_KEY_E7, EFI_KEY_E8, EFI_KEY_E9,
+ EFI_KEY_E10, EFI_KEY_E11, EFI_KEY_E12, EFI_KEY_BACK_SPACE,
+ EFI_KEY_INS, EFI_KEY_HOME, EFI_KEY_PG_UP, EFI_KEY_NLCK, EFI_KEY_SLASH,
+ EFI_KEY_ASTERISK, EFI_KEY_MINUS, EFI_KEY_ESC, EFI_KEY_F1, EFI_KEY_F2,
+ EFI_KEY_F3, EFI_KEY_F4, EFI_KEY_F5, EFI_KEY_F6, EFI_KEY_F7, EFI_KEY_F8,
+ EFI_KEY_F9, EFI_KEY_F10, EFI_KEY_F11, EFI_KEY_F12, EFI_KEY_PRINT,
+ EFI_KEY_SLCK, EFI_KEY_PAUSE,
+} efi_key;
+

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

2017-10-12 Thread Rob Clark 
On Thu, Oct 12, 2017 at 3:13 AM, Alexander Graf  wrote:
>
>
> On 12.10.17 00:02, Rob Clark wrote:
>> On Wed, Oct 11, 2017 at 10:30 AM, Alexander Graf  wrote:
>>>
>>>
>>> On 10.10.17 14:22, Rob Clark wrote:
 From: Leif Lindholm 

 Enough implementation of the following protocols to run Shell.efi and
 SCT.efi:

   EfiHiiConfigRoutingProtocolGuid
   EfiHiiDatabaseProtocol
   EfiHiiStringProtocol

 We'll fill in the rest once SCT is running properly so we can validate
 the implementation against the conformance test suite.

 Initial skeleton written by Leif, and then implementation by myself.

 Cc: Leif Lindholm 
 Signed-off-by: Rob Clark 
 ---
  include/efi_api.h | 261 ++
  include/efi_loader.h  |   6 +
  lib/efi_loader/Makefile   |   2 +-
  lib/efi_loader/efi_boottime.c |   9 +
  lib/efi_loader/efi_hii.c  | 507 
 ++
  5 files changed, 784 insertions(+), 1 deletion(-)
  create mode 100644 lib/efi_loader/efi_hii.c

 diff --git a/include/efi_api.h b/include/efi_api.h
 index ffdba7fe1a..164147dc87 100644
 --- a/include/efi_api.h
 +++ b/include/efi_api.h
 @@ -16,6 +16,7 @@
  #define _EFI_API_H

  #include 
 +#include 

  #ifdef CONFIG_EFI_LOADER
  #include 
 @@ -536,6 +537,266 @@ struct efi_device_path_utilities_protocol {
   uint16_t node_length);
  };

 +#define EFI_HII_CONFIG_ROUTING_PROTOCOL_GUID \
 + EFI_GUID(0x587e72d7, 0xcc50, 0x4f79, \
 +  0x82, 0x09, 0xca, 0x29, 0x1f, 0xc1, 0xa1, 0x0f)
 +
 +typedef uint16_t efi_string_id_t;
 +
 +struct efi_hii_config_routing_protocol {
 + efi_status_t(EFIAPI *extract_config)(
 + const struct efi_hii_config_routing_protocol *this,
 + const efi_string_t request,
 + efi_string_t *progress,
 + efi_string_t *results);
 + efi_status_t(EFIAPI *export_config)(
 + const struct efi_hii_config_routing_protocol *this,
 + efi_string_t *results);
 + efi_status_t(EFIAPI *route_config)(
 + const struct efi_hii_config_routing_protocol *this,
 + const efi_string_t configuration,
 + efi_string_t *progress);
 + efi_status_t(EFIAPI *block_to_config)(
 + const struct efi_hii_config_routing_protocol *this,
 + const efi_string_t config_request,
 + const uint8_t *block,
 + const efi_uintn_t block_size,
 + efi_string_t *config,
 + efi_string_t *progress);
 + efi_status_t(EFIAPI *config_to_block)(
 + const struct efi_hii_config_routing_protocol *this,
 + const efi_string_t config_resp,
 + const uint8_t *block,
 + const efi_uintn_t *block_size,
 + efi_string_t *progress);
 + efi_status_t(EFIAPI *get_alt_config)(
 + const struct efi_hii_config_routing_protocol *this,
 + const efi_string_t config_resp,
 + const efi_guid_t *guid,
 + const efi_string_t name,
 + const struct efi_device_path *device_path,
 + const efi_string_t alt_cfg_id,
 + efi_string_t *alt_cfg_resp);
 +};
 +
 +#define EFI_HII_DATABASE_PROTOCOL_GUID\
 + EFI_GUID(0xef9fc172, 0xa1b2, 0x4693, \
 +  0xb3, 0x27, 0x6d, 0x32, 0xfc, 0x41, 0x60, 0x42)
 +
 +typedef enum {
 + EFI_KEY_LCTRL, EFI_KEY_A0, EFI_KEY_LALT, EFI_KEY_SPACE_BAR,
 + EFI_KEY_A2, EFI_KEY_A3, EFI_KEY_A4, EFI_KEY_RCTRL, 
 EFI_KEY_LEFT_ARROW,
 + EFI_KEY_DOWN_ARROW, EFI_KEY_RIGHT_ARROW, EFI_KEY_ZERO,
 + EFI_KEY_PERIOD, EFI_KEY_ENTER, EFI_KEY_LSHIFT, EFI_KEY_B0,
 + EFI_KEY_B1, EFI_KEY_B2, EFI_KEY_B3, EFI_KEY_B4, EFI_KEY_B5, 
 EFI_KEY_B6,
 + EFI_KEY_B7, EFI_KEY_B8, EFI_KEY_B9, EFI_KEY_B10, EFI_KEY_RSHIFT,
 + EFI_KEY_UP_ARROW, EFI_KEY_ONE, EFI_KEY_TWO, EFI_KEY_THREE,
 + EFI_KEY_CAPS_LOCK, EFI_KEY_C1, EFI_KEY_C2, EFI_KEY_C3, EFI_KEY_C4,
 + EFI_KEY_C5, EFI_KEY_C6, EFI_KEY_C7, EFI_KEY_C8, EFI_KEY_C9,
 + EFI_KEY_C10, EFI_KEY_C11, EFI_KEY_C12, EFI_KEY_FOUR, EFI_KEY_FIVE,
 + EFI_KEY_SIX, EFI_KEY_PLUS, EFI_KEY_TAB, EFI_KEY_D1, EFI_KEY_D2,
 + EFI_KEY_D3, EFI_KEY_D4, EFI_KEY_D5, EFI_KEY_D6, EFI_KEY_D7, 
 EFI_KEY_D8,
 + EFI_KEY_D9, EFI_KEY_D10, EFI_KEY_D11, EFI_KEY_D12, EFI_KEY_D13,
 + EFI_KEY_DEL, EFI_KEY_END, EFI_KEY_PG_DN, EFI_KEY_SEVEN, 
 EFI_KEY_EIGHT,
 + EFI_KEY_NINE, EFI_KEY_E0, EFI_KEY_E1, EFI_KEY_E2, EFI_KEY_E3,

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

2017-10-12 Thread Alexander Graf 


On 12.10.17 00:02, Rob Clark wrote:
> On Wed, Oct 11, 2017 at 10:30 AM, Alexander Graf  wrote:
>>
>>
>> On 10.10.17 14:22, Rob Clark wrote:
>>> From: Leif Lindholm 
>>>
>>> Enough implementation of the following protocols to run Shell.efi and
>>> SCT.efi:
>>>
>>>   EfiHiiConfigRoutingProtocolGuid
>>>   EfiHiiDatabaseProtocol
>>>   EfiHiiStringProtocol
>>>
>>> We'll fill in the rest once SCT is running properly so we can validate
>>> the implementation against the conformance test suite.
>>>
>>> Initial skeleton written by Leif, and then implementation by myself.
>>>
>>> Cc: Leif Lindholm 
>>> Signed-off-by: Rob Clark 
>>> ---
>>>  include/efi_api.h | 261 ++
>>>  include/efi_loader.h  |   6 +
>>>  lib/efi_loader/Makefile   |   2 +-
>>>  lib/efi_loader/efi_boottime.c |   9 +
>>>  lib/efi_loader/efi_hii.c  | 507 
>>> ++
>>>  5 files changed, 784 insertions(+), 1 deletion(-)
>>>  create mode 100644 lib/efi_loader/efi_hii.c
>>>
>>> diff --git a/include/efi_api.h b/include/efi_api.h
>>> index ffdba7fe1a..164147dc87 100644
>>> --- a/include/efi_api.h
>>> +++ b/include/efi_api.h
>>> @@ -16,6 +16,7 @@
>>>  #define _EFI_API_H
>>>
>>>  #include 
>>> +#include 
>>>
>>>  #ifdef CONFIG_EFI_LOADER
>>>  #include 
>>> @@ -536,6 +537,266 @@ struct efi_device_path_utilities_protocol {
>>>   uint16_t node_length);
>>>  };
>>>
>>> +#define EFI_HII_CONFIG_ROUTING_PROTOCOL_GUID \
>>> + EFI_GUID(0x587e72d7, 0xcc50, 0x4f79, \
>>> +  0x82, 0x09, 0xca, 0x29, 0x1f, 0xc1, 0xa1, 0x0f)
>>> +
>>> +typedef uint16_t efi_string_id_t;
>>> +
>>> +struct efi_hii_config_routing_protocol {
>>> + efi_status_t(EFIAPI *extract_config)(
>>> + const struct efi_hii_config_routing_protocol *this,
>>> + const efi_string_t request,
>>> + efi_string_t *progress,
>>> + efi_string_t *results);
>>> + efi_status_t(EFIAPI *export_config)(
>>> + const struct efi_hii_config_routing_protocol *this,
>>> + efi_string_t *results);
>>> + efi_status_t(EFIAPI *route_config)(
>>> + const struct efi_hii_config_routing_protocol *this,
>>> + const efi_string_t configuration,
>>> + efi_string_t *progress);
>>> + efi_status_t(EFIAPI *block_to_config)(
>>> + const struct efi_hii_config_routing_protocol *this,
>>> + const efi_string_t config_request,
>>> + const uint8_t *block,
>>> + const efi_uintn_t block_size,
>>> + efi_string_t *config,
>>> + efi_string_t *progress);
>>> + efi_status_t(EFIAPI *config_to_block)(
>>> + const struct efi_hii_config_routing_protocol *this,
>>> + const efi_string_t config_resp,
>>> + const uint8_t *block,
>>> + const efi_uintn_t *block_size,
>>> + efi_string_t *progress);
>>> + efi_status_t(EFIAPI *get_alt_config)(
>>> + const struct efi_hii_config_routing_protocol *this,
>>> + const efi_string_t config_resp,
>>> + const efi_guid_t *guid,
>>> + const efi_string_t name,
>>> + const struct efi_device_path *device_path,
>>> + const efi_string_t alt_cfg_id,
>>> + efi_string_t *alt_cfg_resp);
>>> +};
>>> +
>>> +#define EFI_HII_DATABASE_PROTOCOL_GUID\
>>> + EFI_GUID(0xef9fc172, 0xa1b2, 0x4693, \
>>> +  0xb3, 0x27, 0x6d, 0x32, 0xfc, 0x41, 0x60, 0x42)
>>> +
>>> +typedef enum {
>>> + EFI_KEY_LCTRL, EFI_KEY_A0, EFI_KEY_LALT, EFI_KEY_SPACE_BAR,
>>> + EFI_KEY_A2, EFI_KEY_A3, EFI_KEY_A4, EFI_KEY_RCTRL, EFI_KEY_LEFT_ARROW,
>>> + EFI_KEY_DOWN_ARROW, EFI_KEY_RIGHT_ARROW, EFI_KEY_ZERO,
>>> + EFI_KEY_PERIOD, EFI_KEY_ENTER, EFI_KEY_LSHIFT, EFI_KEY_B0,
>>> + EFI_KEY_B1, EFI_KEY_B2, EFI_KEY_B3, EFI_KEY_B4, EFI_KEY_B5, 
>>> EFI_KEY_B6,
>>> + EFI_KEY_B7, EFI_KEY_B8, EFI_KEY_B9, EFI_KEY_B10, EFI_KEY_RSHIFT,
>>> + EFI_KEY_UP_ARROW, EFI_KEY_ONE, EFI_KEY_TWO, EFI_KEY_THREE,
>>> + EFI_KEY_CAPS_LOCK, EFI_KEY_C1, EFI_KEY_C2, EFI_KEY_C3, EFI_KEY_C4,
>>> + EFI_KEY_C5, EFI_KEY_C6, EFI_KEY_C7, EFI_KEY_C8, EFI_KEY_C9,
>>> + EFI_KEY_C10, EFI_KEY_C11, EFI_KEY_C12, EFI_KEY_FOUR, EFI_KEY_FIVE,
>>> + EFI_KEY_SIX, EFI_KEY_PLUS, EFI_KEY_TAB, EFI_KEY_D1, EFI_KEY_D2,
>>> + EFI_KEY_D3, EFI_KEY_D4, EFI_KEY_D5, EFI_KEY_D6, EFI_KEY_D7, 
>>> EFI_KEY_D8,
>>> + EFI_KEY_D9, EFI_KEY_D10, EFI_KEY_D11, EFI_KEY_D12, EFI_KEY_D13,
>>> + EFI_KEY_DEL, EFI_KEY_END, EFI_KEY_PG_DN, EFI_KEY_SEVEN, EFI_KEY_EIGHT,
>>> + EFI_KEY_NINE, EFI_KEY_E0, EFI_KEY_E1, EFI_KEY_E2, EFI_KEY_E3,
>>> + EFI_KEY_E4, EFI_KEY_E5, EFI_KEY_E6, EFI_KEY_E7, EFI_KEY_E8, 
>>> EFI_KEY_E9,
>>> + EFI_KEY_E10, EFI_KEY_E11, EFI_KEY_E12, EFI_KEY_BACK_SPACE,
>>> + EFI_KEY_INS, EFI_KEY_HOME,

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

2017-10-11 Thread Rob Clark 
On Wed, Oct 11, 2017 at 10:30 AM, Alexander Graf  wrote:
>
>
> On 10.10.17 14:22, Rob Clark wrote:
>> From: Leif Lindholm 
>>
>> Enough implementation of the following protocols to run Shell.efi and
>> SCT.efi:
>>
>>   EfiHiiConfigRoutingProtocolGuid
>>   EfiHiiDatabaseProtocol
>>   EfiHiiStringProtocol
>>
>> We'll fill in the rest once SCT is running properly so we can validate
>> the implementation against the conformance test suite.
>>
>> Initial skeleton written by Leif, and then implementation by myself.
>>
>> Cc: Leif Lindholm 
>> Signed-off-by: Rob Clark 
>> ---
>>  include/efi_api.h | 261 ++
>>  include/efi_loader.h  |   6 +
>>  lib/efi_loader/Makefile   |   2 +-
>>  lib/efi_loader/efi_boottime.c |   9 +
>>  lib/efi_loader/efi_hii.c  | 507 
>> ++
>>  5 files changed, 784 insertions(+), 1 deletion(-)
>>  create mode 100644 lib/efi_loader/efi_hii.c
>>
>> diff --git a/include/efi_api.h b/include/efi_api.h
>> index ffdba7fe1a..164147dc87 100644
>> --- a/include/efi_api.h
>> +++ b/include/efi_api.h
>> @@ -16,6 +16,7 @@
>>  #define _EFI_API_H
>>
>>  #include 
>> +#include 
>>
>>  #ifdef CONFIG_EFI_LOADER
>>  #include 
>> @@ -536,6 +537,266 @@ struct efi_device_path_utilities_protocol {
>>   uint16_t node_length);
>>  };
>>
>> +#define EFI_HII_CONFIG_ROUTING_PROTOCOL_GUID \
>> + EFI_GUID(0x587e72d7, 0xcc50, 0x4f79, \
>> +  0x82, 0x09, 0xca, 0x29, 0x1f, 0xc1, 0xa1, 0x0f)
>> +
>> +typedef uint16_t efi_string_id_t;
>> +
>> +struct efi_hii_config_routing_protocol {
>> + efi_status_t(EFIAPI *extract_config)(
>> + const struct efi_hii_config_routing_protocol *this,
>> + const efi_string_t request,
>> + efi_string_t *progress,
>> + efi_string_t *results);
>> + efi_status_t(EFIAPI *export_config)(
>> + const struct efi_hii_config_routing_protocol *this,
>> + efi_string_t *results);
>> + efi_status_t(EFIAPI *route_config)(
>> + const struct efi_hii_config_routing_protocol *this,
>> + const efi_string_t configuration,
>> + efi_string_t *progress);
>> + efi_status_t(EFIAPI *block_to_config)(
>> + const struct efi_hii_config_routing_protocol *this,
>> + const efi_string_t config_request,
>> + const uint8_t *block,
>> + const efi_uintn_t block_size,
>> + efi_string_t *config,
>> + efi_string_t *progress);
>> + efi_status_t(EFIAPI *config_to_block)(
>> + const struct efi_hii_config_routing_protocol *this,
>> + const efi_string_t config_resp,
>> + const uint8_t *block,
>> + const efi_uintn_t *block_size,
>> + efi_string_t *progress);
>> + efi_status_t(EFIAPI *get_alt_config)(
>> + const struct efi_hii_config_routing_protocol *this,
>> + const efi_string_t config_resp,
>> + const efi_guid_t *guid,
>> + const efi_string_t name,
>> + const struct efi_device_path *device_path,
>> + const efi_string_t alt_cfg_id,
>> + efi_string_t *alt_cfg_resp);
>> +};
>> +
>> +#define EFI_HII_DATABASE_PROTOCOL_GUID\
>> + EFI_GUID(0xef9fc172, 0xa1b2, 0x4693, \
>> +  0xb3, 0x27, 0x6d, 0x32, 0xfc, 0x41, 0x60, 0x42)
>> +
>> +typedef enum {
>> + EFI_KEY_LCTRL, EFI_KEY_A0, EFI_KEY_LALT, EFI_KEY_SPACE_BAR,
>> + EFI_KEY_A2, EFI_KEY_A3, EFI_KEY_A4, EFI_KEY_RCTRL, EFI_KEY_LEFT_ARROW,
>> + EFI_KEY_DOWN_ARROW, EFI_KEY_RIGHT_ARROW, EFI_KEY_ZERO,
>> + EFI_KEY_PERIOD, EFI_KEY_ENTER, EFI_KEY_LSHIFT, EFI_KEY_B0,
>> + EFI_KEY_B1, EFI_KEY_B2, EFI_KEY_B3, EFI_KEY_B4, EFI_KEY_B5, EFI_KEY_B6,
>> + EFI_KEY_B7, EFI_KEY_B8, EFI_KEY_B9, EFI_KEY_B10, EFI_KEY_RSHIFT,
>> + EFI_KEY_UP_ARROW, EFI_KEY_ONE, EFI_KEY_TWO, EFI_KEY_THREE,
>> + EFI_KEY_CAPS_LOCK, EFI_KEY_C1, EFI_KEY_C2, EFI_KEY_C3, EFI_KEY_C4,
>> + EFI_KEY_C5, EFI_KEY_C6, EFI_KEY_C7, EFI_KEY_C8, EFI_KEY_C9,
>> + EFI_KEY_C10, EFI_KEY_C11, EFI_KEY_C12, EFI_KEY_FOUR, EFI_KEY_FIVE,
>> + EFI_KEY_SIX, EFI_KEY_PLUS, EFI_KEY_TAB, EFI_KEY_D1, EFI_KEY_D2,
>> + EFI_KEY_D3, EFI_KEY_D4, EFI_KEY_D5, EFI_KEY_D6, EFI_KEY_D7, EFI_KEY_D8,
>> + EFI_KEY_D9, EFI_KEY_D10, EFI_KEY_D11, EFI_KEY_D12, EFI_KEY_D13,
>> + EFI_KEY_DEL, EFI_KEY_END, EFI_KEY_PG_DN, EFI_KEY_SEVEN, EFI_KEY_EIGHT,
>> + EFI_KEY_NINE, EFI_KEY_E0, EFI_KEY_E1, EFI_KEY_E2, EFI_KEY_E3,
>> + EFI_KEY_E4, EFI_KEY_E5, EFI_KEY_E6, EFI_KEY_E7, EFI_KEY_E8, EFI_KEY_E9,
>> + EFI_KEY_E10, EFI_KEY_E11, EFI_KEY_E12, EFI_KEY_BACK_SPACE,
>> + EFI_KEY_INS, EFI_KEY_HOME, EFI_KEY_PG_UP, EFI_KEY_NLCK, EFI_KEY_SLASH,
>> + EFI_KEY_ASTERISK, EFI_KEY_MINUS, EFI_KEY_ESC, EFI_KEY_F1, EFI_KEY_F2,
>> + EFI_KEY_F3, EFI_KEY_F4, EFI_KEY_F5,

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

2017-10-11 Thread Alexander Graf 


On 10.10.17 14:22, Rob Clark wrote:
> From: Leif Lindholm 
> 
> Enough implementation of the following protocols to run Shell.efi and
> SCT.efi:
> 
>   EfiHiiConfigRoutingProtocolGuid
>   EfiHiiDatabaseProtocol
>   EfiHiiStringProtocol
> 
> We'll fill in the rest once SCT is running properly so we can validate
> the implementation against the conformance test suite.
> 
> Initial skeleton written by Leif, and then implementation by myself.
> 
> Cc: Leif Lindholm 
> Signed-off-by: Rob Clark 
> ---
>  include/efi_api.h | 261 ++
>  include/efi_loader.h  |   6 +
>  lib/efi_loader/Makefile   |   2 +-
>  lib/efi_loader/efi_boottime.c |   9 +
>  lib/efi_loader/efi_hii.c  | 507 
> ++
>  5 files changed, 784 insertions(+), 1 deletion(-)
>  create mode 100644 lib/efi_loader/efi_hii.c
> 
> diff --git a/include/efi_api.h b/include/efi_api.h
> index ffdba7fe1a..164147dc87 100644
> --- a/include/efi_api.h
> +++ b/include/efi_api.h
> @@ -16,6 +16,7 @@
>  #define _EFI_API_H
>  
>  #include 
> +#include 
>  
>  #ifdef CONFIG_EFI_LOADER
>  #include 
> @@ -536,6 +537,266 @@ struct efi_device_path_utilities_protocol {
>   uint16_t node_length);
>  };
>  
> +#define EFI_HII_CONFIG_ROUTING_PROTOCOL_GUID \
> + EFI_GUID(0x587e72d7, 0xcc50, 0x4f79, \
> +  0x82, 0x09, 0xca, 0x29, 0x1f, 0xc1, 0xa1, 0x0f)
> +
> +typedef uint16_t efi_string_id_t;
> +
> +struct efi_hii_config_routing_protocol {
> + efi_status_t(EFIAPI *extract_config)(
> + const struct efi_hii_config_routing_protocol *this,
> + const efi_string_t request,
> + efi_string_t *progress,
> + efi_string_t *results);
> + efi_status_t(EFIAPI *export_config)(
> + const struct efi_hii_config_routing_protocol *this,
> + efi_string_t *results);
> + efi_status_t(EFIAPI *route_config)(
> + const struct efi_hii_config_routing_protocol *this,
> + const efi_string_t configuration,
> + efi_string_t *progress);
> + efi_status_t(EFIAPI *block_to_config)(
> + const struct efi_hii_config_routing_protocol *this,
> + const efi_string_t config_request,
> + const uint8_t *block,
> + const efi_uintn_t block_size,
> + efi_string_t *config,
> + efi_string_t *progress);
> + efi_status_t(EFIAPI *config_to_block)(
> + const struct efi_hii_config_routing_protocol *this,
> + const efi_string_t config_resp,
> + const uint8_t *block,
> + const efi_uintn_t *block_size,
> + efi_string_t *progress);
> + efi_status_t(EFIAPI *get_alt_config)(
> + const struct efi_hii_config_routing_protocol *this,
> + const efi_string_t config_resp,
> + const efi_guid_t *guid,
> + const efi_string_t name,
> + const struct efi_device_path *device_path,
> + const efi_string_t alt_cfg_id,
> + efi_string_t *alt_cfg_resp);
> +};
> +
> +#define EFI_HII_DATABASE_PROTOCOL_GUID\
> + EFI_GUID(0xef9fc172, 0xa1b2, 0x4693, \
> +  0xb3, 0x27, 0x6d, 0x32, 0xfc, 0x41, 0x60, 0x42)
> +
> +typedef enum {
> + EFI_KEY_LCTRL, EFI_KEY_A0, EFI_KEY_LALT, EFI_KEY_SPACE_BAR,
> + EFI_KEY_A2, EFI_KEY_A3, EFI_KEY_A4, EFI_KEY_RCTRL, EFI_KEY_LEFT_ARROW,
> + EFI_KEY_DOWN_ARROW, EFI_KEY_RIGHT_ARROW, EFI_KEY_ZERO,
> + EFI_KEY_PERIOD, EFI_KEY_ENTER, EFI_KEY_LSHIFT, EFI_KEY_B0,
> + EFI_KEY_B1, EFI_KEY_B2, EFI_KEY_B3, EFI_KEY_B4, EFI_KEY_B5, EFI_KEY_B6,
> + EFI_KEY_B7, EFI_KEY_B8, EFI_KEY_B9, EFI_KEY_B10, EFI_KEY_RSHIFT,
> + EFI_KEY_UP_ARROW, EFI_KEY_ONE, EFI_KEY_TWO, EFI_KEY_THREE,
> + EFI_KEY_CAPS_LOCK, EFI_KEY_C1, EFI_KEY_C2, EFI_KEY_C3, EFI_KEY_C4,
> + EFI_KEY_C5, EFI_KEY_C6, EFI_KEY_C7, EFI_KEY_C8, EFI_KEY_C9,
> + EFI_KEY_C10, EFI_KEY_C11, EFI_KEY_C12, EFI_KEY_FOUR, EFI_KEY_FIVE,
> + EFI_KEY_SIX, EFI_KEY_PLUS, EFI_KEY_TAB, EFI_KEY_D1, EFI_KEY_D2,
> + EFI_KEY_D3, EFI_KEY_D4, EFI_KEY_D5, EFI_KEY_D6, EFI_KEY_D7, EFI_KEY_D8,
> + EFI_KEY_D9, EFI_KEY_D10, EFI_KEY_D11, EFI_KEY_D12, EFI_KEY_D13,
> + EFI_KEY_DEL, EFI_KEY_END, EFI_KEY_PG_DN, EFI_KEY_SEVEN, EFI_KEY_EIGHT,
> + EFI_KEY_NINE, EFI_KEY_E0, EFI_KEY_E1, EFI_KEY_E2, EFI_KEY_E3,
> + EFI_KEY_E4, EFI_KEY_E5, EFI_KEY_E6, EFI_KEY_E7, EFI_KEY_E8, EFI_KEY_E9,
> + EFI_KEY_E10, EFI_KEY_E11, EFI_KEY_E12, EFI_KEY_BACK_SPACE,
> + EFI_KEY_INS, EFI_KEY_HOME, EFI_KEY_PG_UP, EFI_KEY_NLCK, EFI_KEY_SLASH,
> + EFI_KEY_ASTERISK, EFI_KEY_MINUS, EFI_KEY_ESC, EFI_KEY_F1, EFI_KEY_F2,
> + EFI_KEY_F3, EFI_KEY_F4, EFI_KEY_F5, EFI_KEY_F6, EFI_KEY_F7, EFI_KEY_F8,
> + EFI_KEY_F9, EFI_KEY_F10, EFI_KEY_F11, EFI_KEY_F12, EFI_KEY_PRINT,
> + EFI_KEY_SLCK, EFI_KEY_PAUSE,
> +} efi_key;
> +
> +struct

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

2017-10-10 Thread Rob Clark 
From: Leif Lindholm 

Enough implementation of the following protocols to run Shell.efi and
SCT.efi:

  EfiHiiConfigRoutingProtocolGuid
  EfiHiiDatabaseProtocol
  EfiHiiStringProtocol

We'll fill in the rest once SCT is running properly so we can validate
the implementation against the conformance test suite.

Initial skeleton written by Leif, and then implementation by myself.

Cc: Leif Lindholm 
Signed-off-by: Rob Clark 
---
 include/efi_api.h | 261 ++
 include/efi_loader.h  |   6 +
 lib/efi_loader/Makefile   |   2 +-
 lib/efi_loader/efi_boottime.c |   9 +
 lib/efi_loader/efi_hii.c  | 507 ++
 5 files changed, 784 insertions(+), 1 deletion(-)
 create mode 100644 lib/efi_loader/efi_hii.c

diff --git a/include/efi_api.h b/include/efi_api.h
index ffdba7fe1a..164147dc87 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -16,6 +16,7 @@
 #define _EFI_API_H
 
 #include 
+#include 
 
 #ifdef CONFIG_EFI_LOADER
 #include 
@@ -536,6 +537,266 @@ struct efi_device_path_utilities_protocol {
uint16_t node_length);
 };
 
+#define EFI_HII_CONFIG_ROUTING_PROTOCOL_GUID \
+   EFI_GUID(0x587e72d7, 0xcc50, 0x4f79, \
+0x82, 0x09, 0xca, 0x29, 0x1f, 0xc1, 0xa1, 0x0f)
+
+typedef uint16_t efi_string_id_t;
+
+struct efi_hii_config_routing_protocol {
+   efi_status_t(EFIAPI *extract_config)(
+   const struct efi_hii_config_routing_protocol *this,
+   const efi_string_t request,
+   efi_string_t *progress,
+   efi_string_t *results);
+   efi_status_t(EFIAPI *export_config)(
+   const struct efi_hii_config_routing_protocol *this,
+   efi_string_t *results);
+   efi_status_t(EFIAPI *route_config)(
+   const struct efi_hii_config_routing_protocol *this,
+   const efi_string_t configuration,
+   efi_string_t *progress);
+   efi_status_t(EFIAPI *block_to_config)(
+   const struct efi_hii_config_routing_protocol *this,
+   const efi_string_t config_request,
+   const uint8_t *block,
+   const efi_uintn_t block_size,
+   efi_string_t *config,
+   efi_string_t *progress);
+   efi_status_t(EFIAPI *config_to_block)(
+   const struct efi_hii_config_routing_protocol *this,
+   const efi_string_t config_resp,
+   const uint8_t *block,
+   const efi_uintn_t *block_size,
+   efi_string_t *progress);
+   efi_status_t(EFIAPI *get_alt_config)(
+   const struct efi_hii_config_routing_protocol *this,
+   const efi_string_t config_resp,
+   const efi_guid_t *guid,
+   const efi_string_t name,
+   const struct efi_device_path *device_path,
+   const efi_string_t alt_cfg_id,
+   efi_string_t *alt_cfg_resp);
+};
+
+#define EFI_HII_DATABASE_PROTOCOL_GUID  \
+   EFI_GUID(0xef9fc172, 0xa1b2, 0x4693, \
+0xb3, 0x27, 0x6d, 0x32, 0xfc, 0x41, 0x60, 0x42)
+
+typedef enum {
+   EFI_KEY_LCTRL, EFI_KEY_A0, EFI_KEY_LALT, EFI_KEY_SPACE_BAR,
+   EFI_KEY_A2, EFI_KEY_A3, EFI_KEY_A4, EFI_KEY_RCTRL, EFI_KEY_LEFT_ARROW,
+   EFI_KEY_DOWN_ARROW, EFI_KEY_RIGHT_ARROW, EFI_KEY_ZERO,
+   EFI_KEY_PERIOD, EFI_KEY_ENTER, EFI_KEY_LSHIFT, EFI_KEY_B0,
+   EFI_KEY_B1, EFI_KEY_B2, EFI_KEY_B3, EFI_KEY_B4, EFI_KEY_B5, EFI_KEY_B6,
+   EFI_KEY_B7, EFI_KEY_B8, EFI_KEY_B9, EFI_KEY_B10, EFI_KEY_RSHIFT,
+   EFI_KEY_UP_ARROW, EFI_KEY_ONE, EFI_KEY_TWO, EFI_KEY_THREE,
+   EFI_KEY_CAPS_LOCK, EFI_KEY_C1, EFI_KEY_C2, EFI_KEY_C3, EFI_KEY_C4,
+   EFI_KEY_C5, EFI_KEY_C6, EFI_KEY_C7, EFI_KEY_C8, EFI_KEY_C9,
+   EFI_KEY_C10, EFI_KEY_C11, EFI_KEY_C12, EFI_KEY_FOUR, EFI_KEY_FIVE,
+   EFI_KEY_SIX, EFI_KEY_PLUS, EFI_KEY_TAB, EFI_KEY_D1, EFI_KEY_D2,
+   EFI_KEY_D3, EFI_KEY_D4, EFI_KEY_D5, EFI_KEY_D6, EFI_KEY_D7, EFI_KEY_D8,
+   EFI_KEY_D9, EFI_KEY_D10, EFI_KEY_D11, EFI_KEY_D12, EFI_KEY_D13,
+   EFI_KEY_DEL, EFI_KEY_END, EFI_KEY_PG_DN, EFI_KEY_SEVEN, EFI_KEY_EIGHT,
+   EFI_KEY_NINE, EFI_KEY_E0, EFI_KEY_E1, EFI_KEY_E2, EFI_KEY_E3,
+   EFI_KEY_E4, EFI_KEY_E5, EFI_KEY_E6, EFI_KEY_E7, EFI_KEY_E8, EFI_KEY_E9,
+   EFI_KEY_E10, EFI_KEY_E11, EFI_KEY_E12, EFI_KEY_BACK_SPACE,
+   EFI_KEY_INS, EFI_KEY_HOME, EFI_KEY_PG_UP, EFI_KEY_NLCK, EFI_KEY_SLASH,
+   EFI_KEY_ASTERISK, EFI_KEY_MINUS, EFI_KEY_ESC, EFI_KEY_F1, EFI_KEY_F2,
+   EFI_KEY_F3, EFI_KEY_F4, EFI_KEY_F5, EFI_KEY_F6, EFI_KEY_F7, EFI_KEY_F8,
+   EFI_KEY_F9, EFI_KEY_F10, EFI_KEY_F11, EFI_KEY_F12, EFI_KEY_PRINT,
+   EFI_KEY_SLCK, EFI_KEY_PAUSE,
+} efi_key;
+
+struct efi_key_descriptor {
+   efi_key key;
+   uint16_t unicode;
+   uint16_t shifted_unicode;
+   uint16_t alt_gr_unicode;
+   uint16_t