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

[Heinrich Schuchardt]

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.

test/cmd/fdt.c also has issues.

Best regards

Heinrich