context switch and interrupts
Joel Sherrill
joel.sherrill at OARcorp.com
Tue Jan 5 00:32:08 UTC 2010
On 01/04/2010 04:41 PM, Gedare Bloom wrote:
> Hi,
>
> I'm working on a port of RTEMS to the Sparc 64 (with Eugen) using the
> existing SPARC port as a basis. Our port is "working", but I have
> found that when any RTEMS application begins to run, interrupts are
> disabled. After some initial debugging, it appears that interrupts are
> turned off explicitly by boot_card and do not appear to be explicitly
> turned on.
>
>
That is correct. The interrupt enable/disable/level state
is part of the per thread context. Interrupts should be
enabled when you restore the context of the first task
since tasks normally run with interrupts enabled.
> Looking at the BSP guide, I noticed this in section 7.3.2 about
> boot_card: "RTEMS will context switch to the first application task.
> As a side-effect of this context switch, processor interrupts will be
> enabled."
>
> Does this mean that _CPU_Context_switch in cpu_asm.S should always
> turn interrupts on, regardless of the processor's state?
>
>
No.
> Or is it just that the first context pointed to by Context_Control
> *heir on the first context switch has the appropriate processor state
> for interrupts to be enabled? If so, where is that context
> initialized so that I can make sure it is correct? The obvious
> candidate seems to be _CPU_Context_Initialize, but it only seems to
> set an interrupt masking level, not actually change whether interrupts
> are enabled or disabled.
>
>
Every context switch includes the "processor status register"
or whatever it is called. So interrupt state is switched every
task switch.
It may not be the architecture you are most familiar with but
the m68k is IMO probably the easiest to understand. There are
+ a0-a7 (address registers)
- a6 - frame pointer
- a7 - stack pointer
+ d0-d7 (data registers)
+ sr - (status register)
Three bits in the sr determine the interrupt level and the
entire sr is considered part of the per thread context.
Also a0/a1/d0/d1 are assumed NOT to be preserved across
subroutine calls so are not saved in _CPU_Context_switch
but as part of the interrupt context.
I hope this helps. Ask questions. This is tricky.
--joel
> Thanks,
> Gedare
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>
More information about the users
mailing list