Problems with the blackfin port
Thomas.Doerfler at embedded-brains.de
Tue Apr 1 08:21:15 UTC 2008
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?
Alain Schaefer schrieb:
> On Mon, Mar 31, 2008 at 8:11 PM, André Keller Abadie <akabadie at gmail.com>
>> Hi again!
>> I've already talked to Alain about this and he suggested me to discuss it
>> 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
>> 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.
> rtems-users mailing list
> rtems-users at rtems.com
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.
More information about the users