[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
PowerPC IRQ QU #2 Current Implementation of ISR low level code
- Date: Thu, 20 May 1999 17:52:35 -0500
- From: jennifer.averett at oarcorp.com (jennifer averett)
- Subject: PowerPC IRQ QU #2 Current Implementation of ISR low level code
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:
> 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
> + 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
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
the board and recover if there is a vme access error.