> On Sep 21, 2019, at 17:04 , Chris Johns <chr...@rtems.org> wrote: > > On 22/9/19 2:39 am, dufa...@hda.com wrote: >>> On Sep 21, 2019, at 11:44 , Joel Sherrill <j...@rtems.org> wrote: >>> On Sat, Sep 21, 2019, 10:09 AM Peter Dufault <dufa...@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
You are bringing up most of my concerns in your response, I’ll go over your response properly tomorrow AM when I’ll have free time. Thanks. Peter ----------------- Peter Dufault HD Associates, Inc. Software and System Engineering This email is delivered through the public internet using protocols subject to interception and tampering. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
