diff mbox series

[18/38] efi: Show all known UUIDs with CONFIG_CMD_EFIDEBUG

Message ID 20230331103047.18.I8b1d3f1a3ffca2880596902c87d794f4ea59a53a@changeid
State Superseded
Delegated to: Bin Meng
Headers show
Series x86: Use qemu-x86_64 to boot EFI installers | expand

Commit Message

Simon Glass March 30, 2023, 9:32 p.m. UTC 
The CMD_EFIDEBUG option enables debugging so it is reasonable to assume
that all effects should be made to decode the dreaded UUIDs favoured by
UEFI.

Update the table to show them all when CONFIG_CMD_EFIDEBUG is enabled.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

 lib/uuid.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Heinrich Schuchardt March 30, 2023, 10:38 p.m. UTC | #1 
Am 30. März 2023 23:32:07 MESZ schrieb Simon Glass <sjg@chromium.org>:
>The CMD_EFIDEBUG option enables debugging so it is reasonable to assume
>that all effects should be made to decode the dreaded UUIDs favoured by
>UEFI.
>
>Update the table to show them all when CONFIG_CMD_EFIDEBUG is enabled.
>
>Signed-off-by: Simon Glass <sjg@chromium.org>
>---
>
> lib/uuid.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/lib/uuid.c b/lib/uuid.c
>index 96e1af3c8b00..ab30fbf9152f 100644
>--- a/lib/uuid.c
>+++ b/lib/uuid.c
>@@ -255,7 +255,7 @@ static const struct {
> 		EFI_CERT_TYPE_PKCS7_GUID,
> 	},
> #endif
>-#ifdef CONFIG_EFI
>+#if defined(CONFIG_CMD_EFIDEBUG) || defined(CONFIG_EFI)
> 	{ "EFI_LZMA_COMPRESSED", EFI_LZMA_COMPRESSED },
> 	{ "EFI_DXE_SERVICES", EFI_DXE_SERVICES },
> 	{ "EFI_HOB_LIST", EFI_HOB_LIST },

None of these are used when not building the EFI app.

Best regards

Heinrich
Simon Glass March 30, 2023, 11:48 p.m. UTC | #2 
Hi Heinrich,

On Fri, 31 Mar 2023 at 11:38, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
>
>
> Am 30. März 2023 23:32:07 MESZ schrieb Simon Glass <sjg@chromium.org>:
> >The CMD_EFIDEBUG option enables debugging so it is reasonable to assume
> >that all effects should be made to decode the dreaded UUIDs favoured by
> >UEFI.
> >
> >Update the table to show them all when CONFIG_CMD_EFIDEBUG is enabled.
> >
> >Signed-off-by: Simon Glass <sjg@chromium.org>
> >---
> >
> > lib/uuid.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >diff --git a/lib/uuid.c b/lib/uuid.c
> >index 96e1af3c8b00..ab30fbf9152f 100644
> >--- a/lib/uuid.c
> >+++ b/lib/uuid.c
> >@@ -255,7 +255,7 @@ static const struct {
> >               EFI_CERT_TYPE_PKCS7_GUID,
> >       },
> > #endif
> >-#ifdef CONFIG_EFI
> >+#if defined(CONFIG_CMD_EFIDEBUG) || defined(CONFIG_EFI)
> >       { "EFI_LZMA_COMPRESSED", EFI_LZMA_COMPRESSED },
> >       { "EFI_DXE_SERVICES", EFI_DXE_SERVICES },
> >       { "EFI_HOB_LIST", EFI_HOB_LIST },
>
> None of these are used when not building the EFI app.

So you think we should disable them? As I said above, enabling
debugging seems like a good reason to allow decoding of all of them.

Regards,
SImon
Heinrich Schuchardt March 31, 2023, 12:27 a.m. UTC | #3 
Am 31. März 2023 01:48:57 MESZ schrieb Simon Glass <sjg@chromium.org>:
>Hi Heinrich,
>
>On Fri, 31 Mar 2023 at 11:38, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>>
>>
>>
>> Am 30. März 2023 23:32:07 MESZ schrieb Simon Glass <sjg@chromium.org>:
>> >The CMD_EFIDEBUG option enables debugging so it is reasonable to assume
>> >that all effects should be made to decode the dreaded UUIDs favoured by
>> >UEFI.
>> >
>> >Update the table to show them all when CONFIG_CMD_EFIDEBUG is enabled.
>> >
>> >Signed-off-by: Simon Glass <sjg@chromium.org>
>> >---
>> >
>> > lib/uuid.c | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> >diff --git a/lib/uuid.c b/lib/uuid.c
>> >index 96e1af3c8b00..ab30fbf9152f 100644
>> >--- a/lib/uuid.c
>> >+++ b/lib/uuid.c
>> >@@ -255,7 +255,7 @@ static const struct {
>> >               EFI_CERT_TYPE_PKCS7_GUID,
>> >       },
>> > #endif
>> >-#ifdef CONFIG_EFI
>> >+#if defined(CONFIG_CMD_EFIDEBUG) || defined(CONFIG_EFI)
>> >       { "EFI_LZMA_COMPRESSED", EFI_LZMA_COMPRESSED },
>> >       { "EFI_DXE_SERVICES", EFI_DXE_SERVICES },
>> >       { "EFI_HOB_LIST", EFI_HOB_LIST },
>>
>> None of these are used when not building the EFI app.
>
>So you think we should disable them? As I said above, enabling
>debugging seems like a good reason to allow decoding of all of them.
>
>Regards,
>SImon

U-Boot, Shim, GRUB will not use any of these. The EFI app sees them if shared by the preceding UEFI firmware.

There are zillions other GUIDs that a vendor UEFI might use. But why should we care?

I would rather drop these strings from the code base.

Best regards

Heinrich
Simon Glass March 31, 2023, 1:16 a.m. UTC | #4 
Hi Heinrich,

On Fri, 31 Mar 2023 at 13:27, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
>
>
> Am 31. März 2023 01:48:57 MESZ schrieb Simon Glass <sjg@chromium.org>:
> >Hi Heinrich,
> >
> >On Fri, 31 Mar 2023 at 11:38, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> >>
> >>
> >>
> >> Am 30. März 2023 23:32:07 MESZ schrieb Simon Glass <sjg@chromium.org>:
> >> >The CMD_EFIDEBUG option enables debugging so it is reasonable to assume
> >> >that all effects should be made to decode the dreaded UUIDs favoured by
> >> >UEFI.
> >> >
> >> >Update the table to show them all when CONFIG_CMD_EFIDEBUG is enabled.
> >> >
> >> >Signed-off-by: Simon Glass <sjg@chromium.org>
> >> >---
> >> >
> >> > lib/uuid.c | 2 +-
> >> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >> >
> >> >diff --git a/lib/uuid.c b/lib/uuid.c
> >> >index 96e1af3c8b00..ab30fbf9152f 100644
> >> >--- a/lib/uuid.c
> >> >+++ b/lib/uuid.c
> >> >@@ -255,7 +255,7 @@ static const struct {
> >> >               EFI_CERT_TYPE_PKCS7_GUID,
> >> >       },
> >> > #endif
> >> >-#ifdef CONFIG_EFI
> >> >+#if defined(CONFIG_CMD_EFIDEBUG) || defined(CONFIG_EFI)
> >> >       { "EFI_LZMA_COMPRESSED", EFI_LZMA_COMPRESSED },
> >> >       { "EFI_DXE_SERVICES", EFI_DXE_SERVICES },
> >> >       { "EFI_HOB_LIST", EFI_HOB_LIST },
> >>
> >> None of these are used when not building the EFI app.
> >
> >So you think we should disable them? As I said above, enabling
> >debugging seems like a good reason to allow decoding of all of them.
> >
> >Regards,
> >SImon
>
> U-Boot, Shim, GRUB will not use any of these. The EFI app sees them if shared by the preceding UEFI firmware.
>
> There are zillions other GUIDs that a vendor UEFI might use. But why should we care?
>
> I would rather drop these strings from the code base.

I would far rather drop the UUIDs from the code base. Is that
possible? We should use a simple numeric tag, like 0, 1, 2, 3, 4 with
an associated descriptive string. Even using a 16-byte string would be
better than a UUID.

While we have to put up with UUIDs, we need a way to make them
intelligible for us poor sods who need to decode boot-time traces[1]
and the like.

Regards,
Simon

[1]
    EFI: Exit: efi_open_protocol: 0
    EFI: Entry efi_open_protocol(000000007ed33da0,
5b1b31a1-9562-11d2-8e3f-00a0c969723b, 000000007ecf4978,
000000007ed33da0, 00000000000
00000, 0x2)
    EFI: Exit: efi_open_protocol: 0
    EFI: Entry efi_open_protocol(000000007ed238b0,
09576e91-6d3f-11d2-8e39-00a0c969723b, 000000007ecf4978,
000000007ed33da0, 00000000000
00000, 0x2)
    EFI: Exit: efi_open_protocol: 0
    EFI: Entry efi_locate_handle_ext(2,
a19832b9-ac25-11d3-9a2d-0090273fc14d, 0000000000000000,
000000007ecf4948, 000000007d6f3ba0)
    EFI: Exit: efi_locate_handle_ext: 0
    EFI: Entry efi_open_protocol(000000007ed25040,
09576e91-6d3f-11d2-8e39-00a0c969723b, 000000007ecf4978,
000000007ed33da0, 00000000000
00000, 0x2)
    EFI: Exit: efi_open_protocol: 0
    EFI: Entry efi_open_protocol(000000007ed25040,
a19832b9-ac25-11d3-9a2d-0090273fc14d, 000000007ecf4978,
000000007ed33da0, 00000000000
00000, 0x2)
    EFI: Exit: efi_open_protocol: 0
    EFI: Entry efi_open_protocol(000000007ed33da0,
5b1b31a1-9562-11d2-8e3f-00a0c969723b, 000000007ecf49b8, 00000
0007ed33da0, 0000000000000000, 0x2)
    EFI: Exit: efi_open_protocol: 0
    EFI: Entry efi_open_protocol(000000007ed238b0,
09576e91-6d3f-11d2-8e39-00a0c969723b, 000000007ecf4958,
000000007ed33da0, 00000000000
00000, 0x2)
    EFI: Exit: efi_open_protocol: 0
    EFI: Entry efi_locate_protocol(96751a3d-72f4-41a6-a794-ed5d0e67ae6b,
0000000000000000, 000000007ecf4668)
    EFI: Exit: efi_locate_protocol: 14
    EFI: Entry efi_locate_handle_ext(2,
f541796d-a62e-4954-a775-9584f61b9cdd, 0000000000000000,
000000007ecf4638, 000000007d40be00)
    EFI: Exit: efi_locate_handle_ext: 14
    EFI: Entry efi_locate_handle_ext(2,
607f766c-7455-42be-930b-e4d76db2720f, 0000000000000000,
000000007ecf4638, 000000007d40be00)
    EFI: Exit: efi_locate_handle_ext: 14
    EFI: Entry efi_locate_protocol(f42f7782-012e-4c12-9956-49f94304f721,
0000000000000000, 000000007ecf43e8)
    EFI: Exit: efi_locate_protocol: 14
Heinrich Schuchardt March 31, 2023, 6:46 a.m. UTC | #5 
Am 31. März 2023 03:16:06 MESZ schrieb Simon Glass <sjg@chromium.org>:
>Hi Heinrich,
>
>On Fri, 31 Mar 2023 at 13:27, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>>
>>
>>
>> Am 31. März 2023 01:48:57 MESZ schrieb Simon Glass <sjg@chromium.org>:
>> >Hi Heinrich,
>> >
>> >On Fri, 31 Mar 2023 at 11:38, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>> >>
>> >>
>> >>
>> >> Am 30. März 2023 23:32:07 MESZ schrieb Simon Glass <sjg@chromium.org>:
>> >> >The CMD_EFIDEBUG option enables debugging so it is reasonable to assume
>> >> >that all effects should be made to decode the dreaded UUIDs favoured by
>> >> >UEFI.
>> >> >
>> >> >Update the table to show them all when CONFIG_CMD_EFIDEBUG is enabled.
>> >> >
>> >> >Signed-off-by: Simon Glass <sjg@chromium.org>
>> >> >---
>> >> >
>> >> > lib/uuid.c | 2 +-
>> >> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >> >
>> >> >diff --git a/lib/uuid.c b/lib/uuid.c
>> >> >index 96e1af3c8b00..ab30fbf9152f 100644
>> >> >--- a/lib/uuid.c
>> >> >+++ b/lib/uuid.c
>> >> >@@ -255,7 +255,7 @@ static const struct {
>> >> >               EFI_CERT_TYPE_PKCS7_GUID,
>> >> >       },
>> >> > #endif
>> >> >-#ifdef CONFIG_EFI
>> >> >+#if defined(CONFIG_CMD_EFIDEBUG) || defined(CONFIG_EFI)
>> >> >       { "EFI_LZMA_COMPRESSED", EFI_LZMA_COMPRESSED },
>> >> >       { "EFI_DXE_SERVICES", EFI_DXE_SERVICES },
>> >> >       { "EFI_HOB_LIST", EFI_HOB_LIST },
>> >>
>> >> None of these are used when not building the EFI app.
>> >
>> >So you think we should disable them? As I said above, enabling
>> >debugging seems like a good reason to allow decoding of all of them.
>> >
>> >Regards,
>> >SImon
>>
>> U-Boot, Shim, GRUB will not use any of these. The EFI app sees them if shared by the preceding UEFI firmware.
>>
>> There are zillions other GUIDs that a vendor UEFI might use. But why should we care?
>>
>> I would rather drop these strings from the code base.
>
>I would far rather drop the UUIDs from the code base. Is that
>possible? We should use a simple numeric tag, like 0, 1, 2, 3, 4 with
>an associated descriptive string. Even using a 16-byte string would be
>better than a UUID.
>
>While we have to put up with UUIDs, we need a way to make them
>intelligible for us poor sods who need to decode boot-time traces[1]
>and the like.

The EFI spec uses GUIDs and these are strings you will find with Google. Natural numbers that have bo significance won't serve anybody. GUIDs not used inside U-Boot we should not care to translate as there are too many.

>
>Regards,
>Simon
>
>[1]
>    EFI: Exit: efi_open_protocol: 0
>    EFI: Entry efi_open_protocol(000000007ed33da0,
>5b1b31a1-9562-11d2-8e3f-00a0c969723b, 000000007ecf4978,
>000000007ed33da0, 00000000000
>00000, 0x2)
>    EFI: Exit: efi_open_protocol: 0
>    EFI: Entry efi_open_protocol(000000007ed238b0,
>09576e91-6d3f-11d2-8e39-00a0c969723b, 000000007ecf4978,
>000000007ed33da0, 00000000000
>00000, 0x2)
>    EFI: Exit: efi_open_protocol: 0
>    EFI: Entry efi_locate_handle_ext(2,
>a19832b9-ac25-11d3-9a2d-0090273fc14d, 0000000000000000,
>000000007ecf4948, 000000007d6f3ba0)
>    EFI: Exit: efi_locate_handle_ext: 0
>    EFI: Entry efi_open_protocol(000000007ed25040,
>09576e91-6d3f-11d2-8e39-00a0c969723b, 000000007ecf4978,
>000000007ed33da0, 00000000000
>00000, 0x2)
>    EFI: Exit: efi_open_protocol: 0
>    EFI: Entry efi_open_protocol(000000007ed25040,
>a19832b9-ac25-11d3-9a2d-0090273fc14d, 000000007ecf4978,
>000000007ed33da0, 00000000000
>00000, 0x2)
>    EFI: Exit: efi_open_protocol: 0
>    EFI: Entry efi_open_protocol(000000007ed33da0,
>5b1b31a1-9562-11d2-8e3f-00a0c969723b, 000000007ecf49b8, 00000
>0007ed33da0, 0000000000000000, 0x2)
>    EFI: Exit: efi_open_protocol: 0
>    EFI: Entry efi_open_protocol(000000007ed238b0,
>09576e91-6d3f-11d2-8e39-00a0c969723b, 000000007ecf4958,
>000000007ed33da0, 00000000000
>00000, 0x2)
>    EFI: Exit: efi_open_protocol: 0
>    EFI: Entry efi_locate_protocol(96751a3d-72f4-41a6-a794-ed5d0e67ae6b,
>0000000000000000, 000000007ecf4668)
>    EFI: Exit: efi_locate_protocol: 14
>    EFI: Entry efi_locate_handle_ext(2,
>f541796d-a62e-4954-a775-9584f61b9cdd, 0000000000000000,
>000000007ecf4638, 000000007d40be00)
>    EFI: Exit: efi_locate_handle_ext: 14
>    EFI: Entry efi_locate_handle_ext(2,
>607f766c-7455-42be-930b-e4d76db2720f, 0000000000000000,
>000000007ecf4638, 000000007d40be00)
>    EFI: Exit: efi_locate_handle_ext: 14
>    EFI: Entry efi_locate_protocol(f42f7782-012e-4c12-9956-49f94304f721,
>0000000000000000, 000000007ecf43e8)
>    EFI: Exit: efi_locate_protocol: 14
Simon Glass April 1, 2023, 6:31 a.m. UTC | #6 
Hi Heinrich,

On Fri, 31 Mar 2023 at 19:46, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
>
>
> Am 31. März 2023 03:16:06 MESZ schrieb Simon Glass <sjg@chromium.org>:
> >Hi Heinrich,
> >
> >On Fri, 31 Mar 2023 at 13:27, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> >>
> >>
> >>
> >> Am 31. März 2023 01:48:57 MESZ schrieb Simon Glass <sjg@chromium.org>:
> >> >Hi Heinrich,
> >> >
> >> >On Fri, 31 Mar 2023 at 11:38, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> >> >>
> >> >>
> >> >>
> >> >> Am 30. März 2023 23:32:07 MESZ schrieb Simon Glass <sjg@chromium.org>:
> >> >> >The CMD_EFIDEBUG option enables debugging so it is reasonable to assume
> >> >> >that all effects should be made to decode the dreaded UUIDs favoured by
> >> >> >UEFI.
> >> >> >
> >> >> >Update the table to show them all when CONFIG_CMD_EFIDEBUG is enabled.
> >> >> >
> >> >> >Signed-off-by: Simon Glass <sjg@chromium.org>
> >> >> >---
> >> >> >
> >> >> > lib/uuid.c | 2 +-
> >> >> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >> >> >
> >> >> >diff --git a/lib/uuid.c b/lib/uuid.c
> >> >> >index 96e1af3c8b00..ab30fbf9152f 100644
> >> >> >--- a/lib/uuid.c
> >> >> >+++ b/lib/uuid.c
> >> >> >@@ -255,7 +255,7 @@ static const struct {
> >> >> >               EFI_CERT_TYPE_PKCS7_GUID,
> >> >> >       },
> >> >> > #endif
> >> >> >-#ifdef CONFIG_EFI
> >> >> >+#if defined(CONFIG_CMD_EFIDEBUG) || defined(CONFIG_EFI)
> >> >> >       { "EFI_LZMA_COMPRESSED", EFI_LZMA_COMPRESSED },
> >> >> >       { "EFI_DXE_SERVICES", EFI_DXE_SERVICES },
> >> >> >       { "EFI_HOB_LIST", EFI_HOB_LIST },
> >> >>
> >> >> None of these are used when not building the EFI app.
> >> >
> >> >So you think we should disable them? As I said above, enabling
> >> >debugging seems like a good reason to allow decoding of all of them.
> >> >
> >> >Regards,
> >> >SImon
> >>
> >> U-Boot, Shim, GRUB will not use any of these. The EFI app sees them if shared by the preceding UEFI firmware.
> >>
> >> There are zillions other GUIDs that a vendor UEFI might use. But why should we care?
> >>
> >> I would rather drop these strings from the code base.
> >
> >I would far rather drop the UUIDs from the code base. Is that
> >possible? We should use a simple numeric tag, like 0, 1, 2, 3, 4 with
> >an associated descriptive string. Even using a 16-byte string would be
> >better than a UUID.
> >
> >While we have to put up with UUIDs, we need a way to make them
> >intelligible for us poor sods who need to decode boot-time traces[1]
> >and the like.
>
> The EFI spec uses GUIDs and these are strings you will find with Google. Natural numbers that have bo significance won't serve anybody. GUIDs not used inside U-Boot we should not care to translate as there are too many.

I think it is an interesting idea though, to have an internal register
of these things with an enum. Then U-Boot can just use that everywhere
and it is clear what it is, at least within the U-Boot code base.
Things that are not understood don't matter anyway, since we don't
have code for them.

Anyway, back to the original topic, as you can see from the trace
below, it is far too tedious for a human to decode the UUIDs. That is
what the computer is for.

But if this patch has no value, because the UUIDs I mention are never
shown, we can drop it.

Regards,
Simon


>
> >
> >Regards,
> >Simon
> >
> >[1]
> >    EFI: Exit: efi_open_protocol: 0
> >    EFI: Entry efi_open_protocol(000000007ed33da0,
> >5b1b31a1-9562-11d2-8e3f-00a0c969723b, 000000007ecf4978,
> >000000007ed33da0, 00000000000
> >00000, 0x2)
> >    EFI: Exit: efi_open_protocol: 0
> >    EFI: Entry efi_open_protocol(000000007ed238b0,
> >09576e91-6d3f-11d2-8e39-00a0c969723b, 000000007ecf4978,
> >000000007ed33da0, 00000000000
> >00000, 0x2)
> >    EFI: Exit: efi_open_protocol: 0
> >    EFI: Entry efi_locate_handle_ext(2,
> >a19832b9-ac25-11d3-9a2d-0090273fc14d, 0000000000000000,
> >000000007ecf4948, 000000007d6f3ba0)
> >    EFI: Exit: efi_locate_handle_ext: 0
> >    EFI: Entry efi_open_protocol(000000007ed25040,
> >09576e91-6d3f-11d2-8e39-00a0c969723b, 000000007ecf4978,
> >000000007ed33da0, 00000000000
> >00000, 0x2)
> >    EFI: Exit: efi_open_protocol: 0
> >    EFI: Entry efi_open_protocol(000000007ed25040,
> >a19832b9-ac25-11d3-9a2d-0090273fc14d, 000000007ecf4978,
> >000000007ed33da0, 00000000000
> >00000, 0x2)
> >    EFI: Exit: efi_open_protocol: 0
> >    EFI: Entry efi_open_protocol(000000007ed33da0,
> >5b1b31a1-9562-11d2-8e3f-00a0c969723b, 000000007ecf49b8, 00000
> >0007ed33da0, 0000000000000000, 0x2)
> >    EFI: Exit: efi_open_protocol: 0
> >    EFI: Entry efi_open_protocol(000000007ed238b0,
> >09576e91-6d3f-11d2-8e39-00a0c969723b, 000000007ecf4958,
> >000000007ed33da0, 00000000000
> >00000, 0x2)
> >    EFI: Exit: efi_open_protocol: 0
> >    EFI: Entry efi_locate_protocol(96751a3d-72f4-41a6-a794-ed5d0e67ae6b,
> >0000000000000000, 000000007ecf4668)
> >    EFI: Exit: efi_locate_protocol: 14
> >    EFI: Entry efi_locate_handle_ext(2,
> >f541796d-a62e-4954-a775-9584f61b9cdd, 0000000000000000,
> >000000007ecf4638, 000000007d40be00)
> >    EFI: Exit: efi_locate_handle_ext: 14
> >    EFI: Entry efi_locate_handle_ext(2,
> >607f766c-7455-42be-930b-e4d76db2720f, 0000000000000000,
> >000000007ecf4638, 000000007d40be00)
> >    EFI: Exit: efi_locate_handle_ext: 14
> >    EFI: Entry efi_locate_protocol(f42f7782-012e-4c12-9956-49f94304f721,
> >0000000000000000, 000000007ecf43e8)
> >    EFI: Exit: efi_locate_protocol: 14
diff mbox series

Patch

diff --git a/lib/uuid.c b/lib/uuid.c
index 96e1af3c8b00..ab30fbf9152f 100644
--- a/lib/uuid.c
+++ b/lib/uuid.c
@@ -255,7 +255,7 @@  static const struct {
 		EFI_CERT_TYPE_PKCS7_GUID,
 	},
 #endif
-#ifdef CONFIG_EFI
+#if defined(CONFIG_CMD_EFIDEBUG) || defined(CONFIG_EFI)
 	{ "EFI_LZMA_COMPRESSED", EFI_LZMA_COMPRESSED },
 	{ "EFI_DXE_SERVICES", EFI_DXE_SERVICES },
 	{ "EFI_HOB_LIST", EFI_HOB_LIST },