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

[Heinrich Schuchardt]

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.

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).

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.

Best regards

Heinrich