Hi Mark, On Wed, 27 Nov 2024 at 06:52, Mark Kettenis <mark.kette...@xs4all.nl> wrote: > > > From: Simon Glass <s...@chromium.org> > > Date: Wed, 27 Nov 2024 06:08:10 -0700 > > Hi Simon, > > > Hi Tom, > > > > On Tue, 26 Nov 2024 at 09:08, Tom Rini <tr...@konsulko.com> wrote: > > > > > > On Tue, Nov 26, 2024 at 08:39:05AM -0700, Simon Glass wrote: > > > > Hi Heinrich, > > > > > > > > On Tue, 26 Nov 2024 at 02:10, Heinrich Schuchardt <xypron.g...@gmx.de> > > > > wrote: > > > > > > > > > > On 25.11.24 21:44, Simon Glass wrote: > > > > > > The EFI-loader implementation converts things back and forth between > > > > > > addresses and pointers, with not much consistency in how this is > > > > > > done. > > > > > > > > > > > > Within most of U-Boot a pointer is a void * and an address is a > > > > > > ulong > > > > > > > > > > No. It is phys_addr_t that was introduced to handle the sandbox's > > > > > virtual addresses. > > > > > > > > > > And we should keep this sandbox stuff out of the EFI code. They are > > > > > only > > > > > needed for the command line interface. > > > > > > > > No. My statement is correct and long predates sandbox. U-Boot has > > > > always used ulong. Using an address is generally much easier than a > > > > pointer, so I believe this design decision was (and remains) a good > > > > one. I certainly would not support changing it. The phys_addr_t type > > > > has nothing to do with sandbox. > > > > > > At the high level, I think parts of the problem are that when U-Boot > > > went from 32bit architectures to 36bit architectures (assorted PowerPC > > > Freescale parts) to 64bit architectures that no, we didn't make some > > > concious and consistent statement that "ulong is for address (except > > > when it's not). If you look at the linux kernel, phys_addr_t is physical > > > addresses, ulong is virtual addresses. > > > > > > And so phys_addr_t was introduced, iirc, for PowerPC where we had a > > > 32bit architecture with 36bit addresses and had to deal with that. > > > > OK, thanks. > > > > I'm a bit unsure what to do here...but am leaning towards having a > > separate struct for the memory areas in struct efi_mem_list, rather > > than using the same efi_mem_desc. Then I can have one use addresses > > and the other pointers. > > That does not make sense to me. Why would you want to use pointers to > manage what is effectively a memory address map?
I sent a series with the idea. Basically it is to use addresses within the efi_memory.c implementation, doing the pointer <-> address conversion in efi_boottime.c So efi_memory.c has a table with real addresses. The address-pretending-to-be-pointer happens only in efi_boottime.c and doesn't spread any further. Regards, Simon
