> Date: Wed, 11 Jan 2023 17:59:27 +0100 > From: Heinrich Schuchardt <heinrich.schucha...@canonical.com> > > 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.
Actually LMB is fine. It is the way it is used in U-Boot, where subsystems each have their own struct lmb that is the problem. Also note that I'm using LMB in a upcoming patch for the Apple DART IOMMU to manage device virtual addresses. In that case having a a separate struct lmb actually makes sense since the device virtual address spaces are completely separate from eachother and from the physical address space. So don't remove it just yet ;).
