From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RESEND PATCH v2 2/6] efi_loader: Initial HII database protocols
Date: Tue, 25 Dec 2018 17:30:25 +0900 [thread overview]
Message-ID: <20181225083024.GC14405@linaro.org> (raw)
In-Reply-To: <84b6f3fd-ed68-a541-7727-69e5392984e6@suse.de>
On Sun, Dec 23, 2018 at 02:46:05AM +0100, Alexander Graf wrote:
>
>
> On 17.12.18 02:16, AKASHI Takahiro wrote:
> > On Sun, Dec 16, 2018 at 09:36:38PM +0100, Heinrich Schuchardt wrote:
> >> On 12/14/18 11:10 AM, AKASHI Takahiro wrote:
> >>> From: Leif Lindholm <leif.lindholm@linaro.org>
> >>>
> >>> This patch provides enough implementation of the following protocols to
> >>> run EDKII's Shell.efi and UEFI SCT:
> >>>
> >>> * EfiHiiDatabaseProtocol
> >>> * EfiHiiStringProtocol
> >>>
> >>> Not implemented are:
> >>> * ExportPackageLists()
> >>> * RegisterPackageNotify()/UnregisterPackageNotify()
> >>> * SetKeyboardLayout() (i.e. *current* keyboard layout)
> >>>
> >>> HII database protocol can handle only:
> >>> * GUID package
> >>> * string package
> >>> * keyboard layout package
> >>> (The other packages, except Device path package, will be necessary
> >>> for interactive and graphical UI.)
> >>>
> >>> We'll fill in the rest once SCT is running properly so we can validate
> >>> the implementation against the conformance test suite.
> >>>
> >>> Cc: Leif Lindholm <leif.lindholm@linaro.org>
> >>> Signed-off-by: Rob Clark <robdclark@gmail.com>
> >>> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> >>> ---
> >>> include/efi_api.h | 242 ++++++++++
> >>> include/efi_loader.h | 4 +
> >>> lib/efi_loader/Makefile | 1 +
> >>> lib/efi_loader/efi_boottime.c | 12 +
> >>> lib/efi_loader/efi_hii.c | 886 ++++++++++++++++++++++++++++++++++
> >>> 5 files changed, 1145 insertions(+)
> >>> create mode 100644 lib/efi_loader/efi_hii.c
> >>>
> >>> diff --git a/include/efi_api.h b/include/efi_api.h
> >>> index aef77b6319de..c9dbd5a6037d 100644
> >>> --- a/include/efi_api.h
> >>> +++ b/include/efi_api.h
> >>> @@ -17,6 +17,7 @@
> >>> #define _EFI_API_H
> >>>
> >>> #include <efi.h>
> >>> +#include <charset.h>
> >>>
> >>> #ifdef CONFIG_EFI_LOADER
> >>> #include <asm/setjmp.h>
> >>> @@ -697,6 +698,247 @@ struct efi_device_path_utilities_protocol {
> >>> uint16_t node_length);
> >>> };
> >>>
> >>> +typedef u16 efi_string_id_t;
> >>> +
> >>> +#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;
> >>
> >> Hello Takahiro,
> >>
> >> with the patch I can start the EFI shell. But I am still trying to check
> >> the different definitions in this file.
> >>
> >> As mentioned in prior mail the size of enum is not defined in the C
> >> spec. So better use u32.
> >
> > Sure, but I still wonder whether this should be u32 or u16 (or even u8)
> > as UEFI spec doesn't clearly define this.
>
> Enums may hold up to INT_MAX, so just make it u32.
OK.
> >
> >>> + u16 unicode;
> >>> + u16 shifted_unicode;
> >>> + u16 alt_gr_unicode;
> >>> + u16 shifted_alt_gr_unicode;
> >>> + u16 modifier;
> >>> + u16 affected_attribute;
> >>> +};
> >>> +
> >>> +struct efi_hii_keyboard_layout {
> >>> + u16 layout_length;
> >>> + efi_guid_t guid;
> >>
> >> A patch to change the alignment of efi_guid_t to __alinged(8) has been
> >> merged into efi-next.
> >
> > I have one concern here;
> > This structure will also be used as a data format/layout in a file,
> > a package list, given the fact that UEFI defines ExportPackageLists().
> > So extra six bytes after layout_length, for example, may not be very
> > useful in general.
> > I'm not very much sure if UEFI spec intends so.
>
> I'm not sure I fully follow. We ideally should be compatible with edk2,
> no? So if the spec isn't clear, let's make sure we clarify the spec to
> the behavior edk2 exposes today.
I'm not sure that EDK2 is very careful about data alignment.
Regarding guid, in MdePkg/Include/Base.h,
///
/// 128 bit buffer containing a unique identifier value.
/// Unless otherwise specified, aligned on a 64 bit boundary.
///
typedef struct {
UINT32 Data1;
UINT16 Data2;
UINT16 Data3;
UINT8 Data4[8];
} GUID;
in MdePkg/Include/Uefi/UefiBaseType.h,
typedef GUID EFI_GUID;
There is no explicit "aligned()" attribute contrary to Heinrich's patch.
Regarding hii_keyboard_layout,
in Include/Uefi/UefiInternalFormRepresentation.h,
typedef struct {
UINT16 LayoutLength;
EFI_GUID Guid;
UINT32 LayoutDescriptorStringOffset;
UINT8 DescriptorCount;
// EFI_KEY_DESCRIPTOR Descriptors[];
} EFI_HII_KEYBOARD_LAYOUT;
No "packed" attribute, so neither in my code.
> >
> >>> + u32 layout_descriptor_string_offset;
> >>> + u8 descriptor_count;
> >>> + struct efi_key_descriptor descriptors[];
> >>> +};
> >>> +
> >>> +struct efi_hii_package_list_header {
> >>> + efi_guid_t package_list_guid;
> >>> + u32 package_length;
> >>> +} __packed;
> >>
> >> You are defining several structures as __packed. It is unclear to me
> >> where I can find this in the UEFI spec. Looking at EDK2 I could not find
> >> the same __packed attributes.
> >
> > To be honest, I don't know. I just copied these lines from
> > the original patch from Leif & Rob.
> > My guess here is that such data structures are also used as data
> > formats/layouts as part of a package list in a *file* and that no paddings
> > are necessary. Same as I explained above.
> >
> > # Same comments to yours below.
> >
> > I hope that Leif will confirm (or deny) it.
>
> Leif? :)
I'd like to echo, "Leif?"
Thanks,
-Takahiro Akashi
>
> Alex
next prev parent reply other threads:[~2018-12-25 8:30 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-14 10:10 [U-Boot] [RESEND PATCH v2 0/6] subject: efi_loader: add HII database protocol AKASHI Takahiro
2018-12-14 10:10 ` [U-Boot] [RESEND PATCH v2 1/6] lib: add u16_strcpy/strdup functions AKASHI Takahiro
2018-12-14 21:00 ` [U-Boot] [PATCH 1/1] test: tests for u16_strdup() and u16_strcpy() Heinrich Schuchardt
2018-12-14 21:02 ` [U-Boot] [RESEND PATCH v2 1/6] lib: add u16_strcpy/strdup functions Heinrich Schuchardt
2018-12-14 10:10 ` [U-Boot] [RESEND PATCH v2 2/6] efi_loader: Initial HII database protocols AKASHI Takahiro
2018-12-15 20:48 ` Heinrich Schuchardt
2018-12-17 0:36 ` AKASHI Takahiro
2018-12-16 20:36 ` Heinrich Schuchardt
2018-12-17 1:16 ` AKASHI Takahiro
2018-12-23 1:46 ` Alexander Graf
2018-12-25 8:30 ` AKASHI Takahiro [this message]
2019-01-07 14:09 ` Leif Lindholm
2019-01-07 18:29 ` Laszlo Ersek
2019-01-07 19:22 ` Leif Lindholm
2019-01-08 0:28 ` Laszlo Ersek
2019-01-08 9:51 ` Leif Lindholm
2019-01-08 10:07 ` Ard Biesheuvel
2019-01-08 11:55 ` Laszlo Ersek
2019-01-08 15:12 ` Gao, Liming
2019-01-08 15:45 ` Leif Lindholm
2019-01-08 17:15 ` Laszlo Ersek
2019-01-08 15:02 ` [U-Boot] [edk2] " Bi, Dandan
2018-12-18 17:01 ` [U-Boot] " Heinrich Schuchardt
2018-12-19 1:16 ` AKASHI Takahiro
2019-01-06 15:57 ` Heinrich Schuchardt
2019-01-07 2:30 ` AKASHI Takahiro
2018-12-14 10:10 ` [U-Boot] [RESEND PATCH v2 3/6] efi: hii: add guid package support AKASHI Takahiro
2018-12-14 10:10 ` [U-Boot] [RESEND PATCH v2 4/6] efi: hii: add keyboard layout " AKASHI Takahiro
2018-12-14 10:10 ` [U-Boot] [RESEND PATCH v2 5/6] efi: hii: add HII config routing/access protocols AKASHI Takahiro
2018-12-14 10:10 ` [U-Boot] [RESEND PATCH v2 6/6] efi_selftest: add HII database protocols test AKASHI Takahiro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181225083024.GC14405@linaro.org \
--to=takahiro.akashi@linaro.org \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.