Hi Tom, On Mon, 14 Oct 2024 at 15:48, Tom Rini <[email protected]> wrote: > > On Mon, Oct 14, 2024 at 03:35:12PM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Mon, 14 Oct 2024 at 15:27, Tom Rini <[email protected]> wrote: > > > > > > On Mon, Oct 14, 2024 at 03:13:01PM -0600, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Mon, 14 Oct 2024 at 15:04, Tom Rini <[email protected]> wrote: > > > > > > > > > > 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, > > > > > > Saying "There is no need to worry about lmb after that" is not true. > > > Invoking the "env" command for example will have efi_init_obj() be > > > called, among the others that Heinrich listed. And to possibly refute > > > a next issue, that is intentional so that efivars, the standard > > > mechanism used by an OS to talk with the firmware can be available to > > > U-Boot, if I recall things correctly. > > > > > > My understanding of your assumption is that you believe that once the > > > EFI_LOADER subsystem has started work on a payload we're just a few call > > > chains away from the OS being started and runtime services aside U-Boot > > > being done. > > > > > > My understanding of how things are used today is that this is incorrect. > > > > What I am getting at is that once we have called that function we know > > we are booting an EFI app or using an EFI feature in preparation for > > doing so. Let's start there. Is that correct? > > No, it is not correct.
Can you give me a code link? Regards, Simon
