Problem with ticker.exe for or1ksim/OpenRISC BSP

[Gedare Bloom]

On Fri, Jul 18, 2014 at 4:15 PM, Hesham Moustafa <heshamelmatary at gmail.com>
wrote:

> On Fri, Jul 18, 2014 at 4:17 PM, Gedare Bloom <gedare at rtems.org> wrote:
> > 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
> >
> 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.
>
> What is the compilation error? Is it only DISPATCH_NEEDED, or also
ISR_NEST_LEVEL and THREAD_DISPATCH_DISABLE_LEVEL?

Do you have the correct define for SYM() in your asm.h?


[1]
> https://github.com/heshamelmatary/rtems-gsoc2014/blob/or1k/cpukit/score/cpu/or1k/or1k-exception-handler-low.S
> >
> >> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140718/4f4e2270/attachment-0002.html>