RTEMS soft reboot

Till Straumann strauman at slac.stanford.edu
Sat Jan 24 21:41:04 UTC 2009 

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)
>>>>>
>>>>>
>>>>>
>>>
>>
>
>

More information about the users mailing list