Problem with ticker.exe for or1ksim/OpenRISC BSP

Hesham Moustafa heshamelmatary at gmail.com
Fri Jul 18 21:40:06 UTC 2014


On Fri, Jul 18, 2014 at 10:35 PM, Gedare Bloom <gedare at rtems.org> wrote:
>
>
>
> 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?
>
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.
>
>



More information about the devel mailing list