On 1/11/23 23:59, Mark Kettenis wrote:
From: Simon Glass <s...@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.schucha...@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.schucha...@canonical.com> wrote:
On 1/11/23 17:48, Simon Glass wrote:
Hi,
On Wed, 11 Jan 2023 at 06:59, Tom Rini <tr...@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.schucha...@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.kette...@xs4all.nl> wrote:
From: Simon Glass <s...@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
