PowerPC exceptions and critical interrupts

Till Straumann strauman at slac.stanford.edu
Mon Jun 9 16:33:34 UTC 2008


My idea was committing one of the SPRGs to holding the IRQ mask.
Currently, the TOS pointer of the interrupt stack is held in SPRG1
(for no really good reason). Using e.g., SPRG0 (the current purpose:
making sure that SPRG0 is not used for the IRQ_Nest_level (see PR288)
is probably obsolete by now).

The only caveat is that I'm not sure if every flavor of PPC features
SPRG0/SPRG1 but I suspect the ones we currently support do since
SPRG1 is used anyways.

You don't need a run-time check orgie - the bspsupport already
has done it. The variable 'ppc_exc_msr_irq_mask' should hold the
correct value.

What needs to be done is:

 - eliminate current checks for SPRG0 contents
 - load SPRG0 with ppc_exc_msr_irq_mask (probably from
   initialize_exceptions)
 - convert _CPU_ISR_Set_level, _CPU_ISR_Disable, _CPU_ISR_Enable
   etc. to using SPRG0 instead of a static value.
 - convert the bspsupport to using SPRG0 instead of the ppc_exc_msr_irq_mask
   variable (optional but would be a little bit more efficient and 
consistent).

-- Till

Sebastian Huber wrote:
> Hi,
> I adapt the gen83xx BSP for the MPC8313E currently. I switched to the 
> new support code (libcpu/powerpc/new-exceptions/bspsupport) and adjusted 
> it for e300 cores. With this framework it is possible to use RTEMS 
> routines and the dispatcher from external and critical exceptions (some 
> sophisticated lock variables are involved for this).  In order too test 
> it I configured the interrupt controller (IPIC) in a way so that for 
> some interrupt sources a critical interrupt exception will be generated. 
> This works fine except that the current rtems_interrupt_{enable,disable} 
> functions are not aware of critical interrupts. This leads to race 
> conditions in the system core. I guess that this is also true for Book E 
> critical interrupts. A solution is to add the appropriate bits to the 
> disable mask (MSR_CE or MSR_E300_CE), but this leads to a preprecessor 
> or runtime cpu check orgie. Do we really need RTEMS support in critical 
> or machine check exceptions?
>
> Ciao,
>     Sebastian
>
>   




More information about the users mailing list