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

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 2917 bytes --]

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@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@xs4all.nl> wrote:
> > > > > 
> > > > > > From: Simon Glass <sjg@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.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]