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 | 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 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: RTEMS soft reboot |
From: | Till Straumann <[email protected]> |
To: | Matt Rippa <[email protected]> |
Cc: | EPICS-tech-talk <[email protected]> |
Date: | Fri, 23 Jan 2009 14:19:18 -0800 |
Matt Rippa wrote:
Hi Till, Kate - Thanks for the responses. It turns out the keyboard reset was not actually causing trouble --that code was never executing.
?? I thought it would execute (but not have any effect). Didn't it look like this: printk("Printing a stack trace for your convenience :-)\n"); CPU_print_stack(); /* shutdown and reboot */ #if defined(BSP_KBD_IOBASE) kbd_outb(0x4, 0xFE); /* use keyboard controler to do the job... */ #endif #if defined(mvme2100) *(unsigned char*)0xffe00000 |= 0x80; #endif And in bsp.h #if defined(mvme2100) ... #else ... #define BSP_KBD_IOBASE ((_IO_BASE)+0x60) #endif So I guess the code just didn't do anything. The winbond w83c553 simply has nothing mapped at the kbd register address (0x60). I'm not sure if a VME sysreset is the best solution. Unfortunately, the semantics of 'bsp_reset' are not fully defined (board reset, yes, but what happens at the system level?). On a VME system it would be desirable to have 3 variants: board reset only, no VME reset board + VME reset board reset, VME reset only if board is the system controller You can try setting bit 1 of port 0x92 which should perform a board reset -- it would be interesting to know if that also causes a VME sysreset, especially if the board is not the SYSCON. -- Till
Infact (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)