Problems with the blackfin port

[Joel Sherrill]

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.
> André--
>
>
> 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
>>
>> --
>> Allan N. Hessenflow      allanh at kallisti.com
>>
>>     
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>   


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