[PATCH v2 3/3] lmb: consider EFI memory map

[Mark Kettenis]

> From: Simon Glass <sjg at chromium.org>
> Date: Wed, 11 Jan 2023 14:08:27 -0700

Hi Simon,

> Hi Heinrich,
> 
> On Wed, 11 Jan 2023 at 11:03, Heinrich Schuchardt
> <heinrich.schuchardt at canonical.com> wrote:
> >
> >
> >
> > On 1/11/23 18:55, Simon Glass wrote:
> > > Hi Heinrich,
> > >
> > > On Wed, 11 Jan 2023 at 09:59, Heinrich Schuchardt
> > > <heinrich.schuchardt at canonical.com> wrote:
> > >>
> > >>
> > >>
> > >> On 1/11/23 17:48, Simon Glass wrote:
> > >>> Hi,
> > >>>
> > >>> On Wed, 11 Jan 2023 at 06:59, Tom Rini <trini at konsulko.com> wrote:
> > >>>>
> > >>>> On Wed, Jan 11, 2023 at 08:43:37AM +0100, Heinrich Schuchardt wrote:
> > >>>>>
> > >>>>>
> > >>>>> On 1/11/23 01:15, Simon Glass wrote:
> > >>>>>> Hi Heinrich,
> > >>>>>>
> > >>>>>> On Mon, 9 Jan 2023 at 13:53, Heinrich Schuchardt
> > >>>>>> <heinrich.schuchardt at canonical.com> wrote:
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> On 1/9/23 21:31, Simon Glass wrote:
> > >>>>>>>> Hi Mark,
> > >>>>>>>>
> > >>>>>>>> On Mon, 9 Jan 2023 at 13:20, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
> > >>>>>>>>>
> > >>>>>>>>>> From: Simon Glass <sjg at chromium.org>
> > >>>>>>>>>> Date: Mon, 9 Jan 2023 13:11:01 -0700
> > >>>>>>>>>>
> > >>>>>>>>>> Hi Heinrich,
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> We need to fix how EFI does addresses. It seems to use them as
> > >>>>>>>>>> pointers but store them as u64 ?
> > >>>>>>>
> > >>>>>>> That is similar to what you have been doing with physical addresses.
> > >>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> They're defined to a 64-bit unsigned integer by the UEFI
> > >>>>>>>>> specification, so you can't change it.
> > >>>>>>>>
> > >>>>>>>> I don't mean changing the spec, just changing the internal U-Boot
> > >>>>>>>> implementation, which is very confusing. This confusion is spreading
> > >>>>>>>> out, too.
> > >>>>>>>>
> > >>>>>>>> Regards,
> > >>>>>>>> Simon
> > >>>>>>>
> > >>>>>>> The real interesting thing is how memory should be managed in U-Boot:
> > >>>>>>>
> > >>>>>>> I would prefer to create a shared global memory management on 4KiB page
> > >>>>>>> level used both for EFI and the rest of U-Boot.
> > >>>>>>
> > >>>>>> Sounds good.
> > >>>>>>
> > >>>>>>>
> > >>>>>>> What EFI adds to the requirements is that you need more than free
> > >>>>>>> (EfiConventionalMemory) and used memory. EFI knows 16 different types of
> > >>>>>>> memory usage (see enum efi_memory_type).
> > >>>>>>
> > >>>>>> That's a shame. How much of this is legacy and how much is useful?
> > >>>>>>
> > >>>>>>>
> > >>>>>>> When loading a file (e.g. with the "load" command) this should lead to a
> > >>>>>>> memory reservation. You should not be able to load a second file into an
> > >>>>>>> overlapping memory area without releasing the allocated memory first.
> > >>>>>>>
> > >>>>>>> This would replace lmb which currently tries to recalculate available
> > >>>>>>> memory ab initio again and again.
> > >>>>>>>
> > >>>>>>> With managed memory we should be able to get rid of all those constants
> > >>>>>>> like $loadaddr, $fdt_addr_r, $kernel_addr_r, etc. and instead use a
> > >>>>>>> register of named loaded files.
> > >>>>>>
> > >>>>>> This is where standard boot comes in, since it knows what it has
> > >>>>>> loaded and has pointers to it.
> > >>>>>>
> > >>>>>> I see a future where we don't use these commands when we want to save
> > >>>>>> space. It can save 300KB from the U-Boot size.
> > >>>>>>
> > >>>>>> But this really has to come later, since there is so much churn already!
> > >>>>>>
> > >>>>>> For now, please don't add EFI allocation into lmb..that is just odd.
> > >>>>>
> > >>>>> It is not odd but necessary. Without it the Odroid C2 does not boot but
> > >>>>> crashes.
> > >>>>
> > >>>> It's not Odroid C2, it's anything that with the bad luck to relocate
> > >>>> over the unprotected EFI structures.
> > >>>
> > >>> So can EFI use the lmb calls to reserve its memory? This patch is backwards.
> > >>
> > >> Simon, the EFI code can manage memory, LMB cannot.
> > >>
> > >> Every time something in U-Boot invokes LMB it recalculates reservations
> > >> *ab initio*.
> > >>
> > >> You could use lib/efi_loader/efi_memory to replace LMB but not the other
> > >> way round.
> > >>
> > >> We should discard LMB and replace it by proper memory management.
> > >
> > > We have malloc() but in general this is not used (so far) except with
> > > some parts of standard boot, and even there we are maintaining
> > > compatibility with existing fdt_addr_r vars, etc.
> >
> > malloc() currently manages a portion of the memory defined by
> > CONFIG_SYS_MALLOC_LEN. It cannot manage reserved memory. I don't know if
> > it can allocate from non-consecutive memory areas.
> 
> This depends on whether we do what you were talking about above, i.e.
> get rid of the env vars and allocate things. One way to allocate would
> be with malloc().

Almost certainly not a good idea.  There are all sorts of constraints
an things like the address where you load your kernel.  Something
like: "128M of memory, 2MB aligned not crossing a 1GB boundary".  

Now *I* would argue that encoding the specific requirements of an OS
into U-Boot is the wrong approach to start with and that you're better
off having U-Boot load an OS-specific 2nd (or 3rd or 4th) stage loader
that loads the actual OS kernel.  Which is why providing an interface
like EFI that provides a lot of control over memory allocation is so
useful.

> > > So what is the plan for this?
> >
> > The next step should be a design document.
> 
> OK
> 
> Regards,
> Simon
>