Problems with the blackfin port

[André Keller Abadie]

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?

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
>