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

[Tom Rini]

On Fri, Aug 23, 2024 at 05:30:48PM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Fri, 23 Aug 2024 at 15:49, Tom Rini <trini at konsulko.com> wrote:
> >
> > 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.
> 
> Oh...is it posted somewhere?

I posted it in response to your other lab grid series at various points.
At this point there's not much too it because it's just one-liners more
or less like:
$ cat console.labgrid
exec $LG_CLIENT -c $LG_ENV console

and so forth (and LG_CLIENT shouldn't be abstracted honestly, it should
just be labgrid-client).

> > > 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.
> 
> It might have been that it stopped running conf.xxx files...I fixed that in v3.
> 
> OK, I will wait to hear.

It was I think a lack of the new top-level scripts being present, I
think. We might need to re-work that part of the series to be 3 parts,
where release.none/u-boot-test-release are added in preparation for
adding the labgrid specific one.

-- 
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/20240826/4398e8df/attachment.sig>