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. Regards, Simon
