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

[valette at crf.canon.fr (VALETTE Eric)]

>>>>> "jennifer" == jennifer averett <jennifer.averett at oarcorp.com> writes:

jennifer> On  Wednesday, May 19, 1999 Joel Wrote

Hi Jennifer,

I was a little bit surprised about your mail as I did
not receive part of the discussion that you have included in 
your mail...

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

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

OK. I know that. But also if you look at the MSR setting while handling
"external interrupt" and "decrementer interrupt", you will notice this
bit (EE) is already cleared so there is no need to clear it again.

I do think MSR[RI] prevent *any* exception handling and such a way must
exist as the SRR1 SRR0 are not stacked. So you must only re-enable global exception
exeption processing via MSR[RI]. For maskable exceptions, there are other selective
bits like EE, FE, ...

My bet is that, if you do not set MSR[RI] you will never see nested interrupts
anyway...

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

Not so sure : on mcp750, there is a second level cache L2 controlled by L2CR registers.
The correct value for L2CR is BSP dependend as it contains things depending
on board specific timing/config (L2 RAM type, L2 output hold, L2 Clock ratio,...)

>From this we can deduce :

     - The correct place ultimate place for enabling the cache is in the BSP,
     and should be called BSP_processor_cache_enable,
     - On processor where the value does not depend on BSP, the implementation can be
     generic and could be found in libcpu/mpc603/mmu/cachexxxx



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

OK. No problem. I oofer an interface for conecting execptions. The code you connect is
BSP dependend...


-- 
   __                 
  /  `                   	Eric Valette
 /--   __  o _.          	Canon CRF
(___, / (_(_(__         	Rue de la touche lambert
				35517 Cesson-Sevigne  Cedex
				FRANCE
Tel: +33 (0)2 99 87 68 91	Fax: +33 (0)2 99 84 11 30
E-mail: valette at crf.canon.fr