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

[Heinrich Schuchardt]

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.

> 
> So what is the plan for this?

The next step should be a design document.

Best regards

Heinrich