Problem with ticker.exe for or1ksim/OpenRISC BSP

Hesham Moustafa heshamelmatary at
Fri Jul 18 20:15:43 UTC 2014

On Fri, Jul 18, 2014 at 4:17 PM, Gedare Bloom <gedare at> wrote:
> On Fri, Jul 18, 2014 at 1:35 AM, Hesham Moustafa
> <heshamelmatary at> wrote:
>> On Thu, Jul 17, 2014 at 3:10 PM, Joel Sherrill
>> <joel.sherrill at> wrote:
>> > This definitely sounds like not handling the context switch necessary
>> > part of the
>> > IRQ processing properly so always returning to IDLE. I call this a
>> > simple return.
>> >
>> > All ports have a version of this code. no_cpu should have reasonable
>> > pseudo-code.
>> > m68k is likely the easiest to read as real code.
>> >
>> > You need to do a simple return if:
>> >
>> > (a) IRQ is nested, or
>> > (b) DISPATCH_NEEDED is false
>> >
>> This is a macro that defines the address of the corresponding variable
>> within the per cpu config table right? Please correct the following if
>> I it's wrong. From assembly (when doing restore after C ISR handler is
>> executed), I have to load this variable value, check if it's true
>> (greater than zero), and if yes, jump to _ISR_Dispatch. I am a little
>> confused what context should be loaded in both cases of: simple
>> return, and _ISR_Dispatch; In case of _ISR_Dispatch, should I save
>> stack pointer and return address and other context like normal context
>> switch (function call)? While in interrupt context (simple return), I
>> am saving almost all registers with some other necessary registers
>> related to exceptions.
> Please see
Yes, I have read this along with no_cpu.h, m68k, nios2 code.
> Summarizing:
> You need to update a few variables before calling the user ISR:
> _Thread_Dispatch_disable_level += 1
> _ISR_Nest_level += 1
> And decrement them after returning.
> If ISRs are nested you do a simple return.
> Then you need to check if _CPU_ISR_Dispatch_disable is set, if so do a
> simple return.
> Then you need to check if DISPATCH_NEEDED, if so you need to do the
> ISR_Dispatch.
That's what I try to do in assembly, but still I get a compilation error when
including the headers containing DISPATCH_NEEDED macros and other
nesting and dispatch disable macros. The files included in my assembly
file exactly the same as m68k. Please have a look I just pushed for anyone
to review, but it still produce compilation error for no recognizing C code.

>> One thing I have a problem with, is when using some macros like
>> DISPATCH_NEEDED (it's a variable address right?) I am normally
>> including rtems/score/percpu.h from the assembly file (which does the
>> magic) to get these definitions but the compiler suffers. I think I
>> have to provide compiler option or something to just include #define
>> macros? If yes, where to add it?
> Make sure to include rtems/asm.h before including percpu.h so you get
> the ASM defines instead of C defines, since you are (presumably)
> writing this in assembly. You could also use inline assembly, but then
> you need to use expression operands [1] to provide access to these
> variables instead.
> [1]
> -Gedare
>> > Otherwise, you need to some CPU specific magic to get our of the IRQ and
>> > back to the thread. Make it look like it called _Thread_Dispatch with
>> > sufficient saved registers (e.g. callee destroyed). This is usually called
>> > _ISR_Dispatch.  When the call from _ISR_Dispatch to _Thread_Dispatch
>> > returns, you do the magic needed to return tot he interrupted thread
>> > (IDLE in this case) as if nothing happened.

More information about the devel mailing list