Problems with the blackfin port

Alain Schaefer alani at
Tue Apr 1 06:29:57 UTC 2008


On Mon, Mar 31, 2008 at 8:11 PM, André Keller Abadie <akabadie at>

> Hi again!
> I've already talked to Alain about this and he suggested me to discuss it
> here.
> The problem happens when thread_dispatch is scheduled within an isr to
> be executed after its return. This scheduling procedure has a flaw and
> RTEMS keeps crashing every time a few conditions are met.
> Blackfin is an architecture that saves the return pointer of a call in
> a register - called RETS - instead of saving in the stack. However you
> can use the instruction 'link' to create a stack frame and this
> automatically pushes the RETS' value. All C code has this call+link
> pair so technically we do save the return pointer in the stack.

The problem here is that call/link resp. it's counter pair unlink/ret are
two separate instructions and thus not atomic. The whole part in the
hanlding dealing with interruptions between call/link is a bit hacky and I
like it very much.

> This routine that schedules the execution of thread_dispatch after the
> return of an interruption does so by changing the RETI's ('return from
> interrupt' register) value to point to thread_dispatch and then
> changes RETS's value to the old RETI's. Because of this operation, the
> old RETS is lost if not previously saved by 'link'. All this procedure
> goes perfectly well if the call+link pair is executed, but there are a
> few functions that doesn't use 'link' (gcc code written in assembly).

One thing I had not thought about was that these functions don't seem to
any other functions. Maybe this can lead to any solution. As far as I
RETS is not reset by the link instruction. So we can not simply check RETS
if a call has been made without a LINK.

I guess there are other architectures that, as blackfin, don't save
> the return pointers in the stack. If so, how did you solve this
> problem?
> Any suggestions?
> I do have a working solution but it uses a separate software
> interruption to handle the threaddispatch function.

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list