Hi Tom, On Mon, 26 Aug 2024 at 12:33, Tom Rini <tr...@konsulko.com> wrote: > > 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 <tr...@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 <tr...@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 <tr...@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 <s...@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). >
OK I see > > > > 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. Yes that will help. I think I have a simple way to keep both things working at the same time, so let me try again with that u-boot-test-hooks series. Regards, Simon
