Problems with the blackfin port

[Alain Schaefer]

Hi,

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

> 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
interrupt
hanlding dealing with interruptions between call/link is a bit hacky and I
don't
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
call
any other functions. Maybe this can lead to any solution. As far as I
remember
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.


alani
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20080401/8b669682/attachment.html>