Re: [PATCH v2 26/35] global_data: Reduce size of early-malloc vars

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 1841 bytes --]

On Fri, Aug 23, 2024 at 02:30:04PM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Fri, 23 Aug 2024 at 07:34, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Wed, Aug 21, 2024 at 10:19:18AM -0600, Simon Glass wrote:
> >
> > > The early malloc region is normally quite small and is certainly less
> > > than 4GB, so use a 32-bit value for the limit and pointer. Update the
> > > comment for clarity while we are here.
> > >
> > > Signed-off-by: Simon Glass <sjg@chromium.org>
> > > ---
> > >
> > > (no changes since v1)
> > >
> > >  arch/arm/lib/bdinfo.c             | 2 +-
> > >  common/board_r.c                  | 2 +-
> > >  common/malloc_simple.c            | 7 ++++---
> > >  common/spl/spl.c                  | 4 ++--
> > >  include/asm-generic/global_data.h | 6 +++---
> > >  5 files changed, 11 insertions(+), 10 deletions(-)
> >
> > This breaks booting on am64x_evm_a53 which is an odd platform that does
> > SPL->SPL->U-Boot.
> 
> OK, I can repeat that on the Beagleplay in my lab. I sent a v3 patch.
> Thanks for bisecting.

Oh good, beagleplay is run after the EVM in my loop and so I didn't see
it was broken there too.

> I'd love to be able to push trees to gitlab and have them run on my
> lab. I think you said that the patches[1] break your lab, so let me
> know if there is anything I can fix.
> 
> Regards,
> Simon
> 
> [1] https://patchwork.ozlabs.org/project/uboot/list/?series=420392

Well the good news is that I've got the tests running again here, and I
think I mostly understand where the challenges will be in updating this
lab to a newer labgrid version and so being able to migrate it to on top
of your patches. The challenge next will be time. Likely the next steps
will be splitting out your serieses in to test fixes and labgrid
implementation details.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]