[PATCH v4 0/5] Adjust initial EFI memory-allocation to be in the U-Boot region

[Tom Rini]

On Sat, Oct 19, 2024 at 05:51:03AM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Thu, 17 Oct 2024 at 17:35, Tom Rini <trini at konsulko.com> wrote:
> >
> > On Thu, Oct 17, 2024 at 05:22:52PM -0600, Simon Glass wrote:
> > > Hi Ilias,
> > >
> > > On Tue, 15 Oct 2024 at 07:32, Ilias Apalodimas
> > > <ilias.apalodimas at linaro.org> wrote:
> > > >
> > > > On Tue, 15 Oct 2024 at 16:26, Simon Glass <sjg at chromium.org> wrote:
> > > > >
> > > > > Hi Ilias,
> > > > >
> > > > > On Mon, 14 Oct 2024 at 22:28, Ilias Apalodimas
> > > > > <ilias.apalodimas at linaro.org> wrote:
> > > > > >
> > > > > > Hi Simon,
> > > > > >
> > > > > > On Sat, 12 Oct 2024 at 00:23, Simon Glass <sjg at chromium.org> wrote:
> > > > > > >
> > > > > > > U-Boot relocates itself to the top of memory and is supposed to avoid
> > > > > > > using any memory below that region. This allows the maximum amount of
> > > > > > > memory to be available for loading images.
> > > > > > >
> > > > > > > The lmb subsystem automatically protects U-Boot's code and data from
> > > > > > > being overwritten. It relies on this region being a contiguous area of
> > > > > > > memory. This setup has worked well for at least 15 years and has been
> > > > > > > documented in the README for as long.
> > > > > > >
> > > > > > > The EFI_LOADER subsystem currently uses memory outside the U-Boot region
> > > > > > > when starting up.
> > > > > > >
> > > > > > > Some of the downstream problems this causes are:
> > > > > > >
> > > > > > > 1. It can overwrite images that have been loaded
> > > > > >
> > > > > > So can the load command
> > > > >
> > > > > Can you point to where? If lmb is enabled, it should be using that, so
> > > > > not overwrite anything.
> > > > >
> > > >
> > > > If you load the initrd in memory X and make the kernel ovelap you will
> > > > overwrite parts of the initrd.
> > >
> > > But lmb stops that. It is actually what it is for.
> > >
> > > > Let's try once again, the ''''problem''' that was discussed in IRC, is
> > > > that the initramfs overwrites memory that was allocated by the EFI
> > > > subsystem *because* we haven't merged the LMB followup patches yet.
> > >
> > > OK, my problem was booting Ubuntu where the bootflow was unbound by
> > > exit-boot-services, resulting in freeing memory (and re-using it)
> > > which was still in use. I don't actually remember what was in that
> > > memory, though. This was over a year ago, when I sent my first version
> > > of the test[1]
> >
> > This was on x86 as well, yes? I believe that's what you said on the call
> > and part of where people get confused I believe.
> 
> Yes, x86

I just want to emphasize that this is a rather critical detail that was
unintentionally omitted and lead to much of the confusion. This is a
heavily tested path on aarch64 and I strongly suspect riscv and then I'm
not sure who aside from you is testing this path on x86.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20241019/61875c16/attachment.sig>