Problem with ticker.exe for or1ksim/OpenRISC BSP

Gedare Bloom gedare at rtems.org
Fri Jul 18 14:17:13 UTC 2014


On Fri, Jul 18, 2014 at 1:35 AM, Hesham Moustafa
<heshamelmatary at gmail.com> wrote:
>
> On Thu, Jul 17, 2014 at 3:10 PM, Joel Sherrill
> <joel.sherrill at oarcorp.com> 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 http://rtems.org/onlinedocs/doc-current/share/rtems/html/porting/Interrupts-Interrupt-Dispatching.html#Interrupts-Interrupt-Dispatching

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.


> 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]  https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html

-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