Hi Till, Kate -
Thanks for the responses. It turns out the keyboard reset was
not actually causing trouble --that code was never executing. In
fact (for the 2700) no reset of any kind was attempted. The
stackTrace seems to just have been called for debugging reasons.
Adding vmeUniverseResetBus() works great and now exit perform as
expected. I've attached a patch, but it still includes the stack
trace in case whom ever included it still wants it.
If it's ok, I'll request this be added to the 4.10 release on
the rtems site.
Thanks!
-Matt
Till Straumann wrote:
Matt Rippa wrote:
Running 'exit' on an RTEMS ioc I get a stack trace. Is exit the
intended mechanism for a soft reboot?
Well - 'exit' should bring you back to the point where you
started RTEMS. However, this is not really possible on all
boards because the environment that booted RTEMS may
have been destroyed (in your case, RTEMS overwrites
critical memory that was used by PPCBug) and in this case
a hard reset may be required (IIRC, 'exit' should in these
cases do that for you so you may have encountered a bug).
Different BSPs used to have their own API to reset the board
(PPC/shared boards used to call this rtemsReboot(), IIRC)
but, again IIRC, this should have been made more consistent
(don't recall if this happened before or after forking 4.9) and
renamed 'bsp_reset()' across multiple architectures/boards.
Now that I write all this I believe I remember that the old
motorola BSP (mvme2300..2700) indeed has a bug; it tries
to reset via the KBD controller and (again IIRC) that doesn't
work. If it did, rtemsReboot()/bsp_reset() or 'exit()' should both
do the job...
You should be able to reset the board via a VME sysreset
(vmeUniverseResetBus())
-- T.
I've shown gdb output below. This is running on an MVME-2700.
Thanks,
-Matt
EPICS 3.14.10 /RTEMS 4.9.1
------
10.1.5.253> exit
Printing a stack trace for your convenience :-)
0x0011A8E0--> 0x0010F55C--> 0x0010A888--> 0x0010A76C--> 0x0000322C
gdb shows:
(gdb) x 0x0000322C
0x322c <enter_C_code+68>: 0x4800004d
(gdb)
0x3230 <MMUon>: 0x7c0000a6
(gdb)
0x3234 <MMUon+4>: 0x6000a972
(gdb)
0x3238 <MMUon+8>: 0x68008940
(gdb)
0x323c <MMUon+12>: 0x7d6802a6
(gdb)
0x3240 <MMUon+16>: 0x7d7a03a6
(gdb)
0x3244 <MMUon+20>: 0x7c1b03a6
(gdb)
0x3248 <MMUon+24>: 0x7c0004ac
(gdb)
0x324c <MMUon+28>: 0x4c00012c
(gdb)
0x3250 <MMUon+32>: 0x4c000064
(gdb)
0x3254 <MMUoff>: 0x7c0000a6
(gdb)
0x3258 <MMUoff+4>: 0x60000070
(gdb)
0x325c <MMUoff+8>: 0x7d6802a6
(gdb)
0x3260 <MMUoff+12>: 0x68000030
(gdb)
0x3264 <MMUoff+16>: 0x7d7a03a6
(gdb)
0x3268 <MMUoff+20>: 0x7c1b03a6
(gdb)
0x326c <MMUoff+24>: 0x7c0004ac
(gdb)
0x3270 <MMUoff+28>: 0x4c00012c
(gdb)
0x3274 <MMUoff+32>: 0x4c000064
(gdb)
0x3278 <_return_to_ppcbug>: 0x7fc802a6
(gdb)
--- /tmp/rtems-4.9.1/c/src/lib/libbsp/powerpc/shared/console/reboot.c 2008-10-23 03:45:55.000000000 -1000
+++ reboot.c 2009-01-23 09:16:01.312017000 -1000
@@ -21,5 +21,7 @@
#endif
#if defined(mvme2100)
*(unsigned char*)0xffe00000 |= 0x80;
+#else
+ vmeUniverseResetBus();
#endif
} /* bsp_reset */
- Replies:
- Re: RTEMS soft reboot Till Straumann
- References:
- RTEMS soft reboot Matt Rippa
- Re: RTEMS soft reboot Till Straumann
- Navigate by Date:
- Prev:
RE: Very slow reconnection to medm after IOC reboot Mark Rivers
- Next:
Re: Very slow reconnection to medm after IOC reboot J. Lewis Muir
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
<2009>
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: RTEMS soft reboot Kate Feng
- Next:
Re: RTEMS soft reboot Till Straumann
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
<2009>
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|