[PATCH v4 4/5] efi: Reserve some memory for initial use

[Simon Glass]

Hi,

On Fri, 11 Oct 2024 at 23:47, Ilias Apalodimas
<ilias.apalodimas at linaro.org> wrote:
>
> Hi Tom
>
> On Sat, 12 Oct 2024 at 04:27, Tom Rini <trini at konsulko.com> wrote:
> >
> > On Sat, Oct 12, 2024 at 12:01:54AM +0200, Heinrich Schuchardt wrote:
> > >
> > >
> > > Am 11. Oktober 2024 23:21:25 MESZ schrieb Simon Glass <sjg at chromium.org>:
> > > >The 'point of cooperation' is where U-Boot starts allowing EFI to use
> > > >memory outside of the U-Boot region. Until that point, it is desirable
> > > >to keep more below U-Boot free for loading images.
> > > >
> > > >Reserve a small region for this purpose.
> > >
> > > Your commit message provides no clue why this should be needed.

Yes, I hadn't realised that people didn't understand what I was
getting at. Tom asked the same question on irc.

It allows us to separate the lmb allocations from the EFI allocations,
so we don't need to have them both in sync. We use lmb for loading
images, then EFI takes over and does what it likes, respecting the
existing lmb reservations.

> >
> > The alternative here would be a patch to doc/develop/memory.rst saying
> > something to the effect of:
> >
> > EFI pool allocations start at ... U-Boot stack pointer +
> > CONFIG_STACK_SIZE and grow downwards from there. These are done by ... a
> > brief description of how the pool allocations work ... Nominally, this
> > will extend for only a few pages worth of memory but depending on
> > requests made by EFI applications can grow larger. All of this is
> > covered by the LMB that covers U-Boot itself and is considered part of
> > the U-Boot memory map. It may be broken down in to further detail to the
> > memory map provided to the OS, in some cases.
>
> I'll send a patch to update that next week. Perhaps even fold it in
> the LMB series

Before we know we are booting an EFI app? No, thank you. EFI should
not be growing downwards like a stack while U-Boot is running...

Regards,
SImon