Problems with the blackfin port
joel.sherrill at OARcorp.com
Tue Apr 1 17:33:33 UTC 2008
André Keller Abadie wrote:
> Actually I did the same thing at first. However, after a few tests I
> found that this too has a flaw.
> If context_switch is called within this thread_dispatch, a context
> will be saved with some isr-specific stuff in the stack.
> The problem is that the thread_dispatch function can also be called by
> other parts of the system, like when you release a semaphore. Whenever
> this call is made and a context switch to a context containing those
> isr stuff in the stack happens, threaddispatch will return to the isr
> and will cause an exception by executing the RTI instruction.
Other ports leave an interrupt stack frame on the stack
of the preempted task when they context switch away as
for a preempt.
For example, see the m68k code for _ISR_Dispatch where
a fake interrupt return frame is pushed to get you to
_ISR_Dispatch and we do another rte to pop the real
one off when we return to the interrupted task.
> Does it make sense?
I think so but I don't know the blackfin architecture enough
to be sure about the ramifications.
> On Tue, Apr 1, 2008 at 12:35 PM, Allan Hessenflow <allanh at kallisti.com> wrote:
>> Alain Schaefer wrote:
>>> Which puts architecure dependent code in parts of the rtems codebase which
>>> are clearly
>>> architecture independent. I am almost 100% this patch will not get accepted.
>>> Even if it
>>> is "protected" by a #IFDEF.
>> The version I've done does not require any modification of the rtems codebase
>> besides the bfin specific files in cpukit/score/cpu/bfin/. Basically, the
>> ISR, just prior to doing a RTI, does a RAISE 15. So as soon as the RTI has
>> executed, the level 15 interrupt handler is entered. That handler calls
>> thread dispatch, and can do an RTI to return. This does require that
>> self-nesting be enabled.
>> The only thing making me a little uncomfortable with this approach is that
>> the interrupt controller is not documented sufficiently to determine if
>> this might introduce some additional limit to the number of tasks that can
>> exist (the maximum nest level is the number of tasks). The hardware has to
>> in some way keep track of the nesting level because the outermost RTI would
>> switch from supervisor mode back to user mode (we don't ever let it get that
>> far; everything is run from inside one level 15 interrupt).
>> Anyway, it does seem to work; it's only the fact that I haven't had time to
>> do much testing that has stopped me from submitting the changes yet. Let
>> me know if either of you would like to try it.
>> Allan N. Hessenflow allanh at kallisti.com
> rtems-users mailing list
> rtems-users at rtems.com
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherrill at OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
More information about the users