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

[jennifer.averett at oarcorp.com (jennifer averett)]

On  Wednesday, May 19, 1999 Joel Wrote
>
>
>
> 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.

If you look at the MSR Bit Settings table 2-B of PPC Programming
Environments Guide, the setting the EE bit to 0 delays recongnition of
external interrupts and decrementer exception conditions.

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

Current implementations are setting this in the bsp configuration file.

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

I agree that this depends on the bsp, but the defination should be
at a higher level than the bsp. For example there are currently 3
bsp's that use the 603e processor.  They should share the same macro
to enable and disable caching.

I would like to add that a bsp may need to recover from other exceptions.
For example one of the 603e processor's I work on will produce a machine
check exception if an accessed vme board is not installed.  The bsp
currently doesn't work like this, but it should be possible to provide a vme
read/write for
the board and recover if there is a vme access error.

Jennifer