On Fri, Jul 18, 2014 at 10:35 PM, Gedare Bloom <ged...@rtems.org> wrote: > > > > On Fri, Jul 18, 2014 at 4:15 PM, Hesham Moustafa <heshamelmat...@gmail.com> > wrote: >> >> On Fri, Jul 18, 2014 at 4:17 PM, Gedare Bloom <ged...@rtems.org> wrote: >> > On Fri, Jul 18, 2014 at 1:35 AM, Hesham Moustafa >> > <heshamelmat...@gmail.com> wrote: >> >> >> >> On Thu, Jul 17, 2014 at 3:10 PM, Joel Sherrill >> >> <joel.sherr...@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? > No, the error is because C symbols are not recognized to assembler. The following is a snippet of the error: "or1k-rtems4.11-gcc --pipe -DHAVE_CONFIG_H -I../../.. -I../../../../cpukit/../../../or1k_or1ksim/lib/include -DASM -O0 -g -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -O0 -g -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT libscorecpu_a-or1k-exception-handler-low.o -MD -MP -MF .deps/libscorecpu_a-or1k-exception-handler-low.Tpo -c -o libscorecpu_a-or1k-exception-handler-low.o `test -f 'or1k-exception-handler-low.S' || echo '../../../../../../../../rtems/c/src/../../cpukit/score/cpu/or1k/'`or1k-exception-handler-low.S mv -f .deps/libscorecpu_a-or1k-context-switch.Tpo .deps/libscorecpu_a-or1k-context-switch.Po /opt/rtems-4.11/or1k-rtems4.11/include/machine/_default_types.h: Assembler messages: /opt/rtems-4.11/or1k-rtems4.11/include/machine/_default_types.h:27: Error: unrecognized instruction `typedef signed char __int8_t' /opt/rtems-4.11/or1k-rtems4.11/include/machine/_default_types.h:29: Error: unrecognized instruction `typedef unsigned char __uint8_t' /opt/rtems-4.11/or1k-rtems4.11/include/machine/_default_types.h:41: Error: unrecognized instruction `typedef short int __int16_t' /opt/rtems-4.11/or1k-rtems4.11/include/machine/_default_types.h:43: Error: unrecognized instruction `typedef short unsigned int __uint16_t' /opt/rtems-4.11/or1k-rtems4.11/include/machine/_default_types.h:63: Error: unrecognized instruction `typedef long int __int32_t' /opt/rtems-4.11/or1k-rtems4.11/include/machine/_default_types.h:65: Error: unrecognized instruction `typedef long unsigned int __uint32_t' /opt/rtems-4.11/or1k-rtems4.11/include/machine/_default_types.h:89: Error: unrecognized instruction `typedef long long int __int64_t'"
> Do you have the correct define for SYM() in your asm.h? > Yes. > >> [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. > > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
