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

[Tom Rini]

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.

-- 
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/20241017/8701d246/attachment.sig>