Problems with the blackfin port

[Joel Sherrill]

Allan Hessenflow wrote:
> 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.
>>
>> Does it make sense?
>>     
>
> I guess I don't quite understand where there would be a problem.  When
> there is ISR specific stuff saved (I assume you mean by the context
> save/restore function), it will only be restored when a context switch
> is done back to the interrupted task, which will then correctly lead to
> an RTI to that task.  This is why self-nesting must be enabled, so
> additional preemptive context switches can occur before that original
> task is rescheduled.
>   
self-nesting?  Is this "restoring the interrupt disable
level to that of the task"?

The context switch code is supposed to include interrupt
disable level per task.  

The m68k is the easiest port to explain.  On the m68k,
when you get to _ISR_Dispatch, the interrupt level
is equal to that it was before the interrupt and we
have pushed a "dummy interrupt return frame"
on the stack with the same interrupt level but different
return address.  It looks like a signal handler was called
or an arbitrary subroutine was called in the middle
of the interrupted function.

        movml   d0-d1/a0-a1,a7 at -
        jsr     SYM (_Thread_Dispatch)
        movml   a7 at +,d0-d1/a0-a1
        rte

Save registers destroyed by C, call dispatcher which
might context switch away, restore registers.  Return
to interruption point.
> If you're actively working on this, perhaps it would be useful if I sent
> my cpukit/score/cpu/bfin/* that I think solves these problems and get you
> to try to poke holes in it...
>   
Oh... I am not actively working on it.  Just explaining another
port and the general scheme. :) Hopefully you can map the
general and m68k onto what you understand.

Happy to consult and look at it but I do not have any blackfin
hardware at the moment.  I have used skyeye some.
> 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