[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
context switch and interrupts
- Date: Wed, 6 Jan 2010 11:28:16 -0500
- From: gedare at gwu.edu (Gedare Bloom)
- Subject: context switch and interrupts
Thank you, I think I see where and why I got confused. I have been
using the SPARC cpukit as the basis for my port, and it appears to
always enable interrupts during the restore phase of the context
switch. I avoided that choice in my implementation, and now need to
figure out what is the best thing to do.
I guess the original SPARC port solely relies on the interrupt level
for masking out interrupts -- the sparc processor has both an
interrupt enable/disable bit, and a processor interrupt level. Would
it be better to turn on the interrupt bit in _CPU_Context_Initialize
while setting the processor interrupt level, or to emulate the SPARC
port and always enable interrupts and let the interrupt level
determine whether the processor actually takes one?
On Mon, Jan 4, 2010 at 7:32 PM, Joel Sherrill <joel.sherrill at oarcorp.com> wrote:
> On 01/04/2010 04:41 PM, Gedare Bloom wrote:
>> 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
>> Does this mean that _CPU_Context_switch in cpu_asm.S should always
>> turn interrupts on, regardless of the processor's state?
>> 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.
>> rtems-users mailing list
>> rtems-users at rtems.org