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

[Heinrich Schuchardt]

On 1/11/23 23:59, Mark Kettenis wrote:
>> 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.

These 2nd stage boot loader are the EFI stubs of the different operating 
systems.

The non-EFI boot commands are used to call Linux' legacy entry point. We 
will have to manage the architecture specific rules in U-Boot. This 
requires a memory allocator to which we can pass an upper address and an 
alignment requirement.

Best regards

Heinrich

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