[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
PowerPC IRQ QU #2 Current Implementation of ISR low level code
- Date: Wed, 19 May 1999 12:19:48 -0500 (CDT)
- From: joel at OARcorp.com (joel at OARcorp.com)
- Subject: PowerPC IRQ QU #2 Current Implementation of ISR low level code
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
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 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
Unfortunately, we did run into this problem. At least two ROM monitors
> 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.