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

[Tom Rini]

On Fri, Aug 23, 2024 at 03:44:45PM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Fri, 23 Aug 2024 at 15:07, Tom Rini <trini at konsulko.com> wrote:
> >
> > 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 at 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 at 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.
> 
> I just sent v3 of the u-boot-test-hooks series. That needs to be in
> for Labgrid to work.

Yes, thanks. It reminded me how far apart what you have is from what I
have, for labgrid.

> The only other series is [1] which makes the integration nicer, but is
> not necessary. That makes sense since we still want the lab to be able
> to test older commits.
> 
> From that series patch [2] fixes a problem which breaks pytest runs,
> since without it, pytest gets a double echo of a few of the characters
> of the first command it sends. It is a pretty annoying problem which
> took a while to figure out. I tried very hard to fix it without
> patching U-Boot's pytest code, but I gave up. One thought I just had
> is that it is possible that setting up the terminal in the
> u-boot-test-console script might work most of the time, i.e. before
> calling Labgrid.

I know with previous iterations of all of the test cleanups and changes
you did, my non-labgrid lab also started failing immediately. Keeping in
mind that today I run all of the pytests on a few hardware platforms,
both with and without labgrid, I need to see what changes you've done
lead to what behavior changes here, and then eventually get things
boiled down to just the your labgrid implementation specific parts, and
see how to work with them, or if it's too far away from the rest of my
use case.

-- 
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/20240823/959f3d3f/attachment.sig>