EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  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  <20092010  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: "[email protected]" <[email protected]>, EPICS Techtalk <[email protected]>
Date: Sat, 24 Jan 2009 13:41:04 -0800
Matt.

Thanks for the extensive test.
It would be a good idea to document
the results in the BSP's README
and/or the wiki.

As for the code modification, I'd suggest
to use

outb(1, 0x92);

instead of directly accessing the memory-mapped
device.

T.

Matt Rippa wrote:
Hi Till -

Till Straumann wrote:
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).

Sorry, yes that's correct.


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

oh yes, this does make good sense.

Here's what I did:
1. I set bit 1 port 0x92 and removed the vmeUniverseBusReset call. I verified that exit did (at least) a board reset. That works.

2. I also performed an exit with the board SYSCON disabled (J20). I again verified the exit performed a board reset, but it did not affect any peripheral boards.

3. SYSCON reenabled now, I included a peripheral board (vmic5588) and initialized it to make the fail light turn off. I again issued an exit and the 5588 fail light remained off, while the 2700 reset.

4. I verified pushing the RST on the 2700 that my 5588 fail light transition from OFF->fail, implying this is what I should see during a VME bus reset.

So I think this is a sufficient test indicating the board reset is not resetting the VME bus. code below.

Thanks for the help,
-Matt

void bsp_reset(void)
{
  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... */
  printk("Setting p92\n");
  *(unsigned char*)0x80000092 |= 0x01;

#endif
#if defined(mvme2100)
  *(unsigned char*)0xffe00000 |= 0x80;
#else

#endif
} /* bsp_reset */



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

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)









References:
RTEMS soft reboot Matt Rippa
Re: RTEMS soft reboot Till Straumann
Re: RTEMS soft reboot Matt Rippa
Re: RTEMS soft reboot Till Straumann
Re: RTEMS soft reboot Matt Rippa

Navigate by Date:
Prev: Re: RTEMS soft reboot Matt Rippa
Next: Re: Very slow reconnection to medm after IOC reboot Andrew Johnson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: RTEMS soft reboot Matt Rippa
Next: RE: recordGenerator record Kalantari Babak
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 31 Jan 2014 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·