On Fri, Nov 14, 2025 at 05:44:42AM -0700, Simon Glass wrote: > uHi, > > On Fri, 7 Nov 2025 at 05:23, Simon Glass <[email protected]> wrote: > > > > Hi Heinrich, > > > > On Thu, 6 Nov 2025 at 00:09, Tom Rini <[email protected]> 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 > > > > > > > <[email protected]> > > > > > > > --- > > > > > > > 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?
No, and no. Heinrich just fixed this in a cleaner way. -- Tom
signature.asc
Description: PGP signature
