> 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. > > > So what is the plan for this? > > > > The next step should be a design document. > > OK > > Regards, > Simon >