[PATCH] test: do not write to 0x0 except on sandbox

[Simon Glass]

uHi,

On Fri, 7 Nov 2025 at 05:23, Simon Glass <sjg at chromium.org> wrote:
>
> Hi Heinrich,
>
> On Thu, 6 Nov 2025 at 00:09, Tom Rini <trini at konsulko.com> wrote:
> >
> > On Wed, Nov 05, 2025 at 11:57:25PM +0100, Heinrich Schuchardt wrote:
> > > On 11/5/25 20:33, Tom Rini wrote:
> > > > On Wed, Nov 05, 2025 at 01:26:01PM -0600, Tom Rini wrote:
> > > > > On Wed, Nov 05, 2025 at 07:07:47PM +0100, Heinrich Schuchardt wrote:
> > > > > > ARM and RISC-V do not have memory at 0x0.
> > > > > > On X86 interrupt vectors are stored at 0x0.
> > > > > >
> > > > > > Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt at canonical.com>
> > > > > > ---
> > > > > >   test/cmd/fdt.c      | 4 ++++
> > > > > >   test/common/print.c | 8 ++++++--
> > > > > >   2 files changed, 10 insertions(+), 2 deletions(-)
> > > > > >
> > > > > > diff --git a/test/cmd/fdt.c b/test/cmd/fdt.c
> > > > > > index 96a8488e172..6b07999c88f 100644
> > > > > > --- a/test/cmd/fdt.c
> > > > > > +++ b/test/cmd/fdt.c
> > > > > > @@ -269,6 +269,10 @@ static int fdt_test_move(struct unit_test_state *uts)
> > > > > >         uint32_t ts;
> > > > > >         void *buf;
> > > > > > +       /* This test requires low writable memory */
> > > > > > +       if (!IS_ENABLED(CONFIG_SANDBOX))
> > > > > > +               return -EAGAIN;
> > > > > > +
> > > > > >         /* Original source DT */
> > > > > >         ut_assertok(make_test_fdt(uts, fdt, size, &addr));
> > > > > >         ts = fdt_totalsize(fdt);
> > > > >
> > > > > In one of those "what is even going on?" moments, just out of context we
> > > > > set newaddr to 0x10000 and then "fdt move addr newaddr ts". Loooking at
> > > > > my logs for am62x_beagleplay_a53 where memory is not at 0x0, this test
> > > > > is currently running and passing. I'm going to fire the platform up and
> > > > > poke now.
> > > > >
> > > > > > diff --git a/test/common/print.c b/test/common/print.c
> > > > > > index 76ee851fe6a..389d6bf4069 100644
> > > > > > --- a/test/common/print.c
> > > > > > +++ b/test/common/print.c
> > > > >
> > > > > These tests are also running and passing on am62x_beagleplay_a53 I see
> > > > > in that same log.
> > > >
> > > > I'm poking TI folks about this in that it seems like memory is really at
> > > > 0x0 here.
> > > >
> > > > But with respect to this patch, NAK, we need to figure out how to change
> > > > these tests to run elsewhere rather than disable them on all of the
> > > > platforms they currently run on.
> > > >
> > >
> > > These tests that are not passing on qemu-riscv64_smode_acpi because of
> > > illegal memory accesses.
> > >
> > > Unfortunately Simon has written a lot of tests with the sandbox in mind. I
> > > agree that it is preferable to make tests more generic.
>
> So long as we actually want to run them on the target, then maybe. But
> what failure are you expecting to find? Compiler bugs? Mostly these
> tests are a waste of time on QEMU.

I never really heard back on this one, so I suppose my point is made?
Should we set as policy of running core tests only on sandbox?

>
> > >
> > > test/cmd/fdt.c also has issues.
> >
> > Perhaps lmb could be used to ask for a new address to use and then free
> > it?
>
> Eek.

Regards,
Simon