[RFC PATCH 08/31] lmb: replcace the lmb_init_and_reserve() function

Tom Rini trini at konsulko.com
Tue Jun 11 15:57:02 CEST 2024


On Tue, Jun 11, 2024 at 02:20:40PM +0530, Sughosh Ganu wrote:
> On Mon, 10 Jun 2024 at 23:01, Tom Rini <trini at konsulko.com> wrote:
> >
> > On Sat, Jun 08, 2024 at 12:22:17AM +0530, Sughosh Ganu wrote:
> > > With the changes to make the Logical Memory Block(LMB) allocations
> > > persistent and with the common memory regions being reserved during
> > > board init, the lmb_init_and_reserve() API can be removed and replaced
> > > with a lmb_add_memory() API, which adds all the available memory to
> > > the LMB pool.
> > >
> > > Signed-off-by: Sughosh Ganu <sughosh.ganu at linaro.org>
> > > ---
> > >  arch/arm/mach-apple/board.c          |  2 +-
> > >  arch/arm/mach-snapdragon/board.c     |  2 +-
> > >  arch/arm/mach-stm32mp/stm32mp1/cpu.c |  2 +-
> > >  cmd/bdinfo.c                         |  2 +-
> > >  cmd/load.c                           |  2 +-
> > >  fs/fs.c                              |  2 +-
> > >  include/lmb.h                        | 12 +++++++++++-
> > >  lib/lmb.c                            | 15 +++++++++++----
> > >  net/tftp.c                           |  2 +-
> > >  net/wget.c                           |  2 +-
> > >  test/cmd/bdinfo.c                    | 10 +---------
> > >  11 files changed, 31 insertions(+), 22 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-apple/board.c b/arch/arm/mach-apple/board.c
> > > index c877c7b94c..2e72d03edd 100644
> > > --- a/arch/arm/mach-apple/board.c
> > > +++ b/arch/arm/mach-apple/board.c
> > > @@ -776,7 +776,7 @@ int board_late_init(void)
> > >  {
> > >       u32 status = 0;
> > >
> > > -     lmb_init_and_reserve(gd->bd, (void *)gd->fdt_blob);
> > > +     lmb_add_memory(gd->bd);
> > >
> > >       /* somewhat based on the Linux Kernel boot requirements:
> > >        * align by 2M and maximal FDT size 2M
> >
> > We already reserved gd->bd as part of the initr_lmb call. So I think
> > this commit needs rethinking, or am I missing something?
> 
> I believe the LMB memory API's also get called from SPL(not sure about
> TPL/VPL though). The memory that gets added in the other commit is for
> U-Boot main, post relocation. These calls will then be needed for
> prior stages of U-Boot that want to use LMB memory.

We do likely make use of LMB at times in SPL, yes, for OS boot and that
does remind me of cases people have had of loading image failures due to
LMB-as-security-mechanism today. So we need to make a call to the new
lmb init for real, once, rather than ad-hoc like this commit makes it.

-- 
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/20240611/5ff9d737/attachment.sig>


More information about the U-Boot mailing list