On Mon, Oct 14, 2024 at 01:13:17PM -0600, Simon Glass wrote: > Hi Tom, > > On Mon, 14 Oct 2024 at 09:56, Tom Rini <[email protected]> wrote: > > > > On Mon, Oct 14, 2024 at 09:50:37AM -0600, Simon Glass wrote: > > > Hi Sughosh, > > > > > > On Sun, 13 Oct 2024 at 04:55, Sughosh Ganu <[email protected]> > > > wrote: > > > > > > > > Use the LMB API's for allocating and freeing up memory. With this, the > > > > LMB module becomes the common backend for managing non U-Boot image > > > > memory that might be requested by other modules. > > > > > > > > Signed-off-by: Sughosh Ganu <[email protected]> > > > > --- > > > > Changes since V2: > > > > * Use map_to_sysmem() to get the user-visible address to be shared > > > > with the lmb API's for sandbox. > > > > > > > > lib/efi_loader/Kconfig | 1 + > > > > lib/efi_loader/efi_memory.c | 77 +++++++++++-------------------------- > > > > 2 files changed, 24 insertions(+), 54 deletions(-) > > > > > > When efi_init_obj() is called, it should be able to add the lmb memory > > > to its own tables. There is no need to worry about lmb after that, > > > since no other images will be loaded, except under EFI's control. Then > > > perhaps you don't need this patch? > > > > But that's not true. The EFI application can return us to the U-Boot > > prompt. > > Can you finish that thought? What are you getting at?
Your assumption is false. As Heinrich followed up with, there are plenty of common cases, including *env* where efi_init_obj() is called and then the user can still do whatever they like via bootm. There is a need to worry about it. Trying to make an artificial distinction here complicates matters. Much more so than adjusting our almost non-existent documentation about memory map / layout to say that this EFI related data *is* U-Boot. -- Tom
signature.asc
Description: PGP signature
