Exception processing for MIPS R4000/__mips==3?

[gregory.menke at gsfc.nasa.gov]

Bruce Robinson writes:
 > Hello Friends,
 > 
 > I'm working on a BSP for a Toshiba TX4925 MIPS processor. I've run into some
 > problems in the exception handling code for the MIPS R4000 (__mips==3) under
 > RTEMS4.6.0. Maybe some of the MIPS contributors could give me some feedback
 > on the following issues. Do I have some valid points, or am I totally off
 > base? Have these issues already been debated and decided?
 > 
 > 1. In RTEMS 4.5.0, defining CPU_R3000 and CPU_R4000 selected the MIPS
 > hardware implementation, and defining __mips=1 and __mips=3 selected whether
 > you used 32 bit or 64 bit registers respectively. There was a close
 > correlation between __mips==3 and the GCC -mips3 compiler option.
 > 
 > In RTEMS 4.6.0, defining __mips=1 and __mips=3 selects R3000 or R4000
 > hardware respectively, and also selects 32 bit or 64 bit registers
 > respectively. But what if you have R4000 hardware, and want to use 32 bit
 > registers for performance? This new arrangement does not allow for this. It
 > seems to me this is one design change that should be reconsidered.

R4000 support in RTEMS is only being debugged now.  I think it would
be entirely reasonable to have a mechanism for selecting 32 bit R4000.
I <think> the only impact is in cpu_asm.S and cpu.h (the stack frame &
task context structs).

I'd really like to find a better way to control it than a bazillion
#ifdefs all over the place.  Perhaps we need to standardize just a few
#defines in the libcpu and libbsp headers for the various MIPS
targets, then testing them could be done consistently.


 > 2. In RTEMS 4.6.0, for R3000/mips=1 the SR_IEC status flag is used to
 > enable/disable interrupts. For the R4000/mips=3 the SR_EXL flag is used in
 > combination with the SR_IE flag. Using the SR_EXL flag for this purpose
 > appears to be incompatible with the exception handling by a resident debug
 > monitor. Here's one situation I'm running into: I have an evaluation board
 > running PMON debug monitor, I load a build of RTEMS into memory and use PMON
 > to set a breakpoint in a task. If interrupts are disabled (SR_EXL set) when
 > I hit the breakpoint, PMON takes the exception but fails to get the right
 > breakpoint address.

RTEMS should be taking over all exception handling from PMON.  As I
understand it, all exceptions should be funneled through cpu_asm.  We
have a gdb stub in the MIPS bsp's that can be remote controlled from a
PC running a MIPS cross-compiled gdb.  I believe that any exception
that is routed outside of RTEMS is a bug.  

OTOH, I think exceptions could be routed to PMON from cpu_asm.S, in
which case the problem then is matching up the register context.
RTEMS uses a standard GNU defined stack frame for the register
context- which PMON might not.


 > The way I understand the SR_EXL flag, it should be used solely as a hold off
 > of interrupts inside the exception handler. For the R4000, the SR_IE flag
 > can be used by RTEMS to enable/disable interrupts, as is done for the R3000.
 > 
 > Even if there is some justification for using the SR_EXL flag for this
 > purpose, I think the current code needs further review. It appears that
 > SR_EXL is being set to enable interrupts, when it should be cleared. See
 > #define _INTON (SR_EXL | SR_IE) in cpu.h.

The way the R4000 int enable is done now was straight out of a generic
R4000 book and was tested on one R4000 device.  Please make the
change, test it and we can work out a patch.  Its worth noting that
the current MIPS interrupt model is not nested, so all exceptions
should be off while inside cpu_asm.S or while scheduling.

 
 > 3. The MIPS exception handler is shared by all MIPS BSP's. In trying to run
 > RTEMS in conjunction with a debug monitor that may be resident, it would be
 > desirable to have an exception handler that can be tailored to the BSP. This
 > appears to have been done for some of the PowerPC ports. Does anybody else
 > see the benefit of supporting a BSP or processor specific exception handler
 > in the libbsp or libcpu directories?

The interrupt handler is already per-cpu since there is a wide variety
of interrupt models on MIPS variants.  I don't think it would be
unreasonable to do the same thing with exceptions.  However, the way
its arranged now is all exceptions are vectored just like interrupts,
so you could install your own exception handler in userspace and still
use the generic MIPS exception handler.


 > 4. A few problems in cpu_asm.S for __mips==3:
 > 
 > 4a. "#define NOP <blank>" causes assembler warnings about instructions in
 > delay slots. I don't think this "deleted" nop is correct.

This is a bug- I think it should be #defined to something useful.


 > 4b. The _CPU_Context_restore_fp_from_exception routine uses "*4" to
 > calculate address offsets. I think it should use "*F_SZ".
 
Thats correct.


 > 4c. _CPU_Context_save_fp_from_exception and
 > _CPU_Context_restore_fp_from_exception routines should use sdc1 and ldc1
 > instructions for __mips==3.

You may well be right, as far as I know these routines have only been
tested on R3000 devices.  I don't have experience on an R4000 to
address the question.

 
 > I'll be happy to provide my proposed fixes to rtems.org, but I need some
 > guidance on the best way to do that.
 > 
 > Thanks in advance for any feedback!

I maintain the BSP for the Mongoose which is an R3000 device, so if
you could funnel patches through me, I can merge them & ensure they
don't disrupt our R3000 support & then forward them to Joel.  I have a
patch from Jay Monkman that I'm treating this way already.

Gregm