[U-Boot] [PATCH 02/11] efi_loader: Initial HII protocols
Alexander Graf
agraf at suse.de
Thu Oct 12 09:59:35 UTC 2017
On 10/12/2017 11:55 AM, Rob Clark wrote:
> On Thu, Oct 12, 2017 at 3:13 AM, Alexander Graf <agraf at suse.de> wrote:
>>
>> On 12.10.17 00:02, Rob Clark wrote:
>>> On Wed, Oct 11, 2017 at 10:30 AM, Alexander Graf <agraf at suse.de> wrote:
>>>>
>>>> On 10.10.17 14:22, 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
>>>>>
>>>>> 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 <leif.lindholm at linaro.org>
>>>>> Signed-off-by: Rob Clark <robdclark at gmail.com>
>>>>> ---
>>>>> 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 <efi.h>
>>>>> +#include <charset.h>
>>>>>
>>>>> #ifdef CONFIG_EFI_LOADER
>>>>> #include <asm/setjmp.h>
>>>>> @@ -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 shifted_alt_gr_unicode;
>>>>> + uint16_t modifier;
>>>>> + uint16_t affected_attribute;
>>>>> +};
>>>>> +
>>>>> +struct efi_hii_keyboard_layout {
>>>>> + uint16_t layout_length;
>>>>> + efi_guid_t guid;
>>>>> + uint32_t layout_descriptor_string_offset;
>>>>> + uint8_t descriptor_count;
>>>>> + struct efi_key_descriptor descriptors[];
>>>>> +};
>>>>> +
>>>>> +struct efi_hii_package_list_header {
>>>>> + efi_guid_t package_list_guid;
>>>>> + uint32_t package_length;
>>>>> +} __packed;
>>>>> +
>>>>> +struct efi_hii_package_header {
>>>>> + uint32_t length : 24;
>>>>> + uint32_t type : 8;
>>>>> +} __packed;
>>>> Bitfields are terribly evil - they're probably one of the worst defined
>>>> things in C. A different compiler may even give you different ordering
>>>> here. I've certainly seen bitfields explode in weird ways on
>>>> cross-endian conversions.
>>> edk2 defines it in the same way. And this is UEFI we are talking
>>> about here, big endian is strictly out of scope.
>> I don't see why big endian is strictly out of scope. I don't want to
>> ignore it light heartedly. All we'd need to do is byte swap every
>> input/output there is today.
> See section 1.9.1:
>
> "
> Supported processors are “little endian” machines. This distinction
> means that the low-
> order byte of a multibyte data item in memory is at the lowest
> address, while the high-
> order byte is at the highest address. Some supported 64-bit processors may be
> configured for both “little endian” and “big endian” operation. All
> implementations
> designed to conform to this specification use “little endian” operation.
> "
>
> even power9 got sane and is finally is switching to LE ;-)
You know as well as me that specs are changeable :). I think UEFI will
always stay LE, but that doesn't mean that it always has to also be
executed in an LE environment. We've done funny stunts with grub before
where we ran LE grub on a BE OpenFirmware implementation.
Really, I just always cringe when I see bitfields.
Alex
More information about the U-Boot
mailing list