PowerPC IRQ QU #2 Current Implementation of ISR low level code

[joel at OARcorp.com (joel at OARcorp.com)]

On Wed, 19 May 1999, VALETTE Eric wrote:

> >>>>> "joel" == joel  <joel at OARcorp.com> writes:
> 
> joel> This code is supposed to load the precalculated (in cpu.c) msr from cpu
> joel> initialization that should have exceptions disabled.  This is based on the
> joel> fact that the BSP is supposed to run with all exceptions disabled.  The
> joel> BSP is responsible for setting the initial value of the msr.
> 
> As far as I understand MSR[RI] prevents nested exception processing, not
> MSR[EE]. SRR0 and SRR1 are not stacked so you must save them before reenabling
> exception processing...

That does not match my interpretation.  On 6-17 of the PPC: Programming
Environments Guide.  

The OS should handle MSR[RI] as follows:

  + In machine check and system reset exception handlers -- Is the SRR1
bit corresponding to the MSR[RI] bit is cleared, the exception is not
recoverable.
  + In each exception handler -- When enough start information has been
saved that a machine check or system reset exception can reconstruct the
previous state, set MSR[RI].
  + In each exception handler -- Clear MSR[RI], set the srr0 and srr1
registers appropriately , and then execute rfi.

Anyway, that combined with the description in 6.2.1 Enabling and Disabling
Exceptions, leads be to believe the MSR[EE] is for "interrupts" and
"nested interrupts".  I did not check but I assume this logic applies for
the decrementer as well.

MSR[RI] is set whenever the machine state is questionable and cleared when
the ISR has saved enough state so a (bad) exception could be processed.

> joel> The two paths are supposed to be equivalent.  The sprg path just has to be
> joel> avoided if running with a ROM monitor/debugger that uses sprg's.
> 
> OK. I do not mind having code that works without sprg's provided this is BSP
> dependent...

Unfortunately, we did run into this problem.  At least two ROM monitors
use sprgs.

> joel> OK.  All of this can be done with the existing PPC port code.  The only
> joel> issues are that various tools (emulators, debuggers, etc.) break with
> joel> caching enabled.  The BAT initialization has also been left as a BSP
> joel> issue.
> 
> Again this should be BSP dependent...

We are in agreement about the dependency.

> joel> This only impacts the EE and any CPU model specific interrupts right?
> 
> I would also add the decrementer interrupt because the way it is handled
> must be coherent with external interrupt code (premption disabled/ stack switch
> as it may be used for timeout execution path...)

OK.  I meant to incldue that one.

> joel> I look forward to it.  It sounds like someone is interested in this on the
> joel> mips.
> 
> I have it readdy if you want. The code I wrote during vacation using a PC->PPC
> development tool had the good idea to work immediately...

If you are in a state where you want to get it reviewed, send it in.  I
will likely start with libcpu since the mpc750 is new anyway.  I want to
move it in in pieces and address BSP incompatiabilities as we merge.  
There are too many PPC BSPs to do it any other way.

--joel