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

[Simon Glass]

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.

> >
> > 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