On Thu, Jan 12, 2023 at 12:35:15AM +0100, Heinrich Schuchardt wrote: > > > 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.
Or we just say that $range is available for at-will usage. So yes, a design document, that states the goals of what we're trying to do here, is really the next step. -- Tom
signature.asc
Description: PGP signature
