rtems tester: Why does rtems_test_assert() just exit?

[Chris Johns]

On 22/9/19 2:39 am, dufault at hda.com wrote:
>> On Sep 21, 2019, at 11:44 , Joel Sherrill <joel at rtems.org> wrote:
>> On Sat, Sep 21, 2019, 10:09 AM Peter Dufault <dufault at hda.com> wrote:
>> Most of the failures I see on “beatnik” are detected by “rtems_test_assert()”.  That prints the assertion and calls exit, e.g. on beatnik:
>>
>> ] allocate most of memory - attempt to fail chroot - expect ENOMEM
>> ] ../../../../../../rtems/c/src/../../testsuites/psxtests/psxchroot01/test.c: 126 status == -1
>> ] fatal source: RTEMS_FATAL_SOURCE_EXIT, error code: 0
>> ] bsp_fatal_extension(): RTEMS terminated -- no way back to MotLoad so I reset the card
>> ] Printing a stack trace for your convenience :-)
>>
>> The failure is detected by the tester when the test platform requests a “tftp” transfer at an unexpected time:
>>
>> ] Subnet IP Address Mask = 255.255.248.0
>> ] 
>> =>  tftp: re-requesting exe; target must have reset
>> ] Network File Load in Progress...
>> =>  target reset condition detected
>> =>  target reset: ./power-ctl 1 off-on
>> ] Error Status: 00000081 - File not found.
>>
>> This takes at least 10 seconds using “motload” and the power switch I’m using.  Why doesn’t "rtems_test_assert()” output something that shows the test failed so that the reset can happen then?
>>
>> That's a good suggestion no one has made. That would work on all automated configurations.

The trigger is up to you. The boot loader's start message is normally the best
to use because it catches the case of the board resetting with no output or
error messages.

The triggers can be ORed together, The documentation ...

https://docs.rtems.org/branches/master/user/testing/tftp.html

.. has the example for the Zedboard of:

target_reset_regex = ^No ethernet found.*|^BOOTP broadcast 6.*|^.+complete\.+
TIMEOUT.*

I do not see a need for anything special being added. Am I missing something?

>> Also the beatnik bsp exit path could have reset enabled on exit. There is a parameter to pass on the configure like which enables reset on exit if the bsp has a functional bsp_reset. Sorry I'm at home on my phone and don't recall the exact name.
>>
>>
> Beatnik does reset on exit.  That’s the “no way back to MotLoad so I reset the card” message.  First it prints out a stack trace, though.

Then I suggest you add this to your target reset trigger. The tester will then
know a reset has happened.

> The BSP reset will boot into MOTLOAD, so you get a first ten second hit, then the tester sees the “tftp” request and invokes the power cycle, so then there is a twelve second hit.  The total is a minimum 22 seconds:>
> - Beatnik issues a BSP reset;
> - Ten seconds for MOTLOAD to get to the point it starts tftp;
> - The tester detects this and issues a beatnik-tester reset, which in my setup is a power cycle;
> - Two seconds for power-off/power-on sequence to the network power cycler;
> - Another ten seconds for MOTLOAD to get to tftp again.

The tester is designed to avoid cycling power. A clean working target should
only need a single power on at the start and a single power off at the end.
Repeated power cycling can stress power supplies and targets, some switch modes
do not like it. Some targets have hardware reset issues and may need a power
cycle and I have seen uboot get wedged. The power cycle logic is for those
cases. I would not expect this being needed on each boot. Also it is a reset
which can be a power cycle or a wired reset signal however some SOCs these days
have separate power on reset (POR) logic and a reset signal logic.

Chris