[PATCH] Revert "efi_memory: do not add U-Boot memory to the memory map"
Simon Glass
sjg at chromium.org
Tue Nov 26 16:39:25 CET 2024
Hi Sughosh,
On Thu, 21 Nov 2024 at 00:53, Sughosh Ganu <sughosh.ganu at linaro.org> wrote:
>
> On Tue, 12 Nov 2024 at 18:48, Simon Glass <sjg at chromium.org> wrote:
> >
> > A bisect of Ubuntu 2022.04 boot-failure on qemu-x86_64 resulted in this
> > patch. I am not sure how to investigate it.
> >
> > The boot hangs at some point during booting of the install image, before
> > the Ubuntu logo appears.
> >
> > I will sent a series with a script showing how it is run.
> >
> > This reverts commit a68c9ac5d8afc51c619c5d3e865fcf147bea90cb.
> >
> > Signed-off-by: Simon Glass <sjg at chromium.org>
> > ---
>
> I did some digging into this issue, and it turns out that the revert
> is only masking the real issue. What this revert does is mark the
> memory region occupied by U-Boot as EFI_BOOT_SERVICES_CODE. The x86
> kernel seems to mark memory regions other than
> EFI_{BOOT,RUNTIME}_SERVICES_CODE as not executable -- and this is
> precisely why this crash shows up only on x86. The actual cause of
> this issue is in the efi runtime functionality of U-Boot. The kernel
> is calling the SetVirtualAddressMap() runtime service function, and
> that seems to be calling some of the boot service code of U-Boot,
> which it shouldn't. We do not get the crash after disabling the
> ConvertPointer() and SetVirtualAddressMap() runtime functions.
OK, so what is the solution here? Did you send a patch?
Regards,
Simon
More information about the U-Boot
mailing list