Re: RTEMS soft reboot

[Till Straumann <strauman@slac.stanford.edu>]

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)