[PATCH v3 03/15] efi: memory: use the lmb API's for allocating and freeing memory

Tom Rini trini at konsulko.com
Mon Oct 14 23:48:41 CEST 2024


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 <trini at konsulko.com> 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 <trini at konsulko.com> 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 <trini at konsulko.com> 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 <sughosh.ganu at linaro.org> 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 <sughosh.ganu at linaro.org>
> > > > > > > > ---
> > > > > > > > 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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20241014/c8509d06/attachment.sig>


More information about the U-Boot mailing list