[PATCH 22/32] efi: arm: Allow use of the EFI table in the app

[Simon Glass]

Hi Heinrich,

On Thu, 6 Feb 2025 at 10:13, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>
> On 2/6/25 13:37, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Thu, 6 Feb 2025 at 03:52, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> >>
> >> On 2/3/25 18:42, Simon Glass wrote:
> >>> It isn't worth the hassle of omitting this field for the app, since code
> >>> is shared between the payload and the app. Adjust the condition to avoid
> >>> a build error in the 'efi' command with the app on ARM.
> >>>
> >>> Signed-off-by: Simon Glass <sjg at chromium.org>
> >>> ---
> >>>
> >>>    arch/arm/include/asm/global_data.h | 2 +-
> >>>    1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/arch/arm/include/asm/global_data.h b/arch/arm/include/asm/global_data.h
> >>> index 8d51111f095..6a85fb2e152 100644
> >>> --- a/arch/arm/include/asm/global_data.h
> >>> +++ b/arch/arm/include/asm/global_data.h
> >>> @@ -108,7 +108,7 @@ struct arch_global_data {
> >>>    #ifdef CONFIG_SMBIOS
> >>>        ulong smbios_start;             /* Start address of SMBIOS table */
> >>>    #endif
> >>> -#ifdef CONFIG_EFI_STUB
> >>> +#ifdef CONFIG_EFI
> >>>        ulong table;
> >>
> >> Unfortunately this field is not documented at all. Please, add a
> >> description. The description '/* Table pointer from previous loader */'
> >> given in the X86 code is quite unsatisfactory. I would not know what
> >> table the field points to.
> >>
> >> If this field is EFI specific, shouldn't it be defined in
> >> arch/x86/include/asm/global_data.h?
> >
> > It depends on what the previous firmware was. Where it is coreboot,
> > this stores a pointer to the coreboot tables.
> >
> > On ARM it is somewhat EFI-specific, although only because we don't
> > expect people to want to boot from coreboot to U-Boot on ARM. But I
> > have long-since given up betting against any particular boot
> > combination.
>
> This does not quite answer the question if we should move this field to
> asm-generic.

I didn't see that question in your response.

>
> As the usage of the field is non-trivial it should be documented.

Yes, agreed.

Regards,
Simon