Problems with the blackfin port

[Thomas Dörfler]

Hi,

first of all: I have NO knowledge about the bfin architecture, but I
have a strange feeling your discussion handles thing that are already
solved in different architectures.

The first point is, that bfin obviously only increments the
thread_dispatch_level in certain conditions. In other architectures it
is incremented in any case, this blocks dispatches to actually occur
during interrupt handling. Have a look e.g. into the m68k implementation.

Normally a context switch should be triggered only, when the outermost
ISR leaves (it decrements thread_dispatch_disable_level to zero).

Would it help if you changed the bfin ISR handling in that way and
possibly add RETI (or some more vital resources) to the ISR/task context?

wkr,
thomas.


Alain Schaefer schrieb:
> 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
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>   


-- 
--------------------------------------------
embedded brains GmbH
Thomas Doerfler           Obere Lagerstr. 30
D-82178 Puchheim          Germany
Tel. : +49-89-18 90 80 79-2
Fax  : +49-89-18 90 80 79-9
email: Thomas.Doerfler at embedded-brains.de
PGP public key available on request

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.