From: Simon Glass sjg@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 trini@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.glpk@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?