[PATCH 07/10] efi: Add another tranch of GUIDs

Simon Glass sjg at chromium.org
Thu Mar 2 00:38:25 CET 2023


Hi Ilias,

On Wed, 1 Mar 2023 at 01:52, Ilias Apalodimas
<ilias.apalodimas at linaro.org> wrote:
>
> Hi Simon
>
> On Sun, 26 Feb 2023 at 03:33, Simon Glass <sjg at chromium.org> wrote:
> >
> > Provide information about the GUIDs supplied by QEMU, so far as it is
> > known.
>
> What the patch does is obvious.  Can you explain why this is needed though?

Yes. It allows seeing what the tables actually are, since the GUIDs
are impenetrable for that. See for example the 'efi table' command in
this series.

I think %sU uses it too.

>
> >
> > Signed-off-by: Simon Glass <sjg at chromium.org>
> > ---
> >
> >  include/efi_api.h | 28 ++++++++++++++++++++++++++++
> >  lib/uuid.c        | 12 ++++++++++++
> >  2 files changed, 40 insertions(+)
> >
> > diff --git a/include/efi_api.h b/include/efi_api.h
> > index 2d18d25a713..90caee4038c 100644
> > --- a/include/efi_api.h
> > +++ b/include/efi_api.h
> > @@ -1909,6 +1909,34 @@ struct efi_system_resource_table {
> >         EFI_GUID(0x4aafd29d, 0x68df, 0x49ee, 0x8a, 0xa9, \
> >                  0x34, 0x7d, 0x37, 0x56, 0x65, 0xa7)
> >
> > +#define EFI_LZMA_COMPRESSED \
> > +       EFI_GUID(0xee4e5898, 0x3914, 0x4259, 0x9d, 0x6e, \
> > +                0xdc, 0x7b, 0xd7, 0x94, 0x03, 0xcf)
> > +#define EFI_DXE_SERVICES \
> > +       EFI_GUID(0x05ad34ba, 0x6f02, 0x4214, 0x95, 0x2e, \
> > +                0x4d, 0xa0, 0x39, 0x8e, 0x2b, 0xb9)
> > +#define EFI_HOB_LIST \
> > +       EFI_GUID(0x7739f24c, 0x93d7, 0x11d4, 0x9a, 0x3a,  \
> > +                0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d)
> > +#define EFI_MEMORY_TYPE \
> > +       EFI_GUID(0x4c19049f, 0x4137, 0x4dd3, 0x9c, 0x10, \
> > +                0x8b, 0x97, 0xa8, 0x3f, 0xfd, 0xfa)
> > +#define EFI_SMBIOS \
> > +       EFI_GUID(0xeb9d2d31, 0x2d88, 0x11d3, 0x9a, 0x16,  \
> > +                0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d)
>
> This already exists as SMBIOS_TABLE_GUID

Oh dear, OK. Would you mind if I rename it? It is hard to find things
if the naming is inconsistent.

>
> > +#define EFI_MEM_STATUS_CODE_REC \
> > +       EFI_GUID(0x060cc026, 0x4c0d, 0x4dda, 0x8f, 0x41, \
> > +                0x59, 0x5f, 0xef, 0x00, 0xa5, 0x02)
> > +#define EFI_GUID_SNBIOS \
> > +       EFI_GUID(0xeb9d2d31, 0x2d88, 0x11d3, 0x9a, 0x16, \
> > +                0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d)
>
> what is SNBIOS? I assume it's a typos since it matches the existing
> SMBIOS_TABLE_GUID?

Yes, a typo

>
> > +#define EFI_GUID_EFI_ACPI1 \
> > +       EFI_GUID(0xeb9d2d30, 0x2d88, 0x11d3,  0x9a, 0x16, \
> > +                0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d)
> > +#define EFI_GUID_EFI_ACPI2 \
> > +       EFI_GUID(0x8868e871, 0xe4f1, 0x11d3, 0xbc, 0x22, \
> > +                0x00, 0x80, 0xc7, 0x3c, 0x88, 0x81)
>
> Already exists as EFI_ACPI_TABLE_GUID

OK, bind if I rename it so we have these consistent?
>
> > +
> >  /**
> >   * struct win_certificate_uefi_guid - A certificate that encapsulates
> >   * a GUID-specific signature
> > diff --git a/lib/uuid.c b/lib/uuid.c
> > index 465e1ac38f5..77aef746a2e 100644
> > --- a/lib/uuid.c
> > +++ b/lib/uuid.c
> > @@ -255,6 +255,18 @@ static const struct {
> >                 EFI_CERT_TYPE_PKCS7_GUID,
> >         },
> >  #endif
> > +#ifdef CONFIG_EFI_APP
> > +#endif
> > +       { "EFI_LZMA_COMPRESSED", EFI_LZMA_COMPRESSED },
> > +       { "EFI_DXE_SERVICES", EFI_DXE_SERVICES },
> > +       { "EFI_HOB_LIST", EFI_HOB_LIST },
> > +       { "EFI_MEMORY_TYPE", EFI_MEMORY_TYPE },
> > +       { "EFI_SMBIOS", EFI_SMBIOS },
> > +       { "EFI_MEM_STATUS_CODE_REC", EFI_MEM_STATUS_CODE_REC },
> > +       { "EFI_GUID_SNBIOS", EFI_GUID_SNBIOS },
> > +       { "EFI_GUID_EFI_ACPI1", EFI_GUID_EFI_ACPI1 },
> > +       { "EFI_GUID_EFI_ACPI2", EFI_GUID_EFI_ACPI2 },
> > +
> >  };
> >
> >  /*
> > --
> > 2.39.2.637.g21b0678d19-goog
> >

Regards,
Simon


More information about the U-Boot mailing list