Problem with ticker.exe for or1ksim/OpenRISC BSP

[Joel Sherrill]

The ASM macro needs to be properly used in rtems/score/cpu.h.

I sent a patch to devel@ but it is really a hack. Things compile but
I wouldn't trust it.

+ ASM should protect C only code from being used in .S code.
And vice-versa.

When I started, there was C code exposed to .S. When I blocked
off a huge block of the code, I discovered two macro constants
in the middle that were needed in .S files. Please check how these
are done in other ports to minimize the number of ifdef's and
to keep things logically together. The area I saw them in looked
like a dumping ground for miscellaneous stuff. Maybe you inherited
it but I don't like it.

Also ...

+ minimum failed to compile in a weird way. Could be a side-effect
of what I did but I don't see how.

+ I don't like your cpu isr disable/enable.  Post the bodies in a
new email thread. I think neither is using the right asm constraints.
And enable seems to be using too many instructions. My guess is
you only need to get the value in a register and move to the spr.
Handling the constraints right will probably reduce this to one
instruction.  We need Christian's help since I don't know or1k asm.

+ disable didn't return the previous level so it couldn't be restored.

+ I (think) I fixed the prototype for _CPU_Initialize_fp.

In general, any warning originating from score/cpu code is very bad
and usually indicates a real problem. It also results in 1000s of
warnings in the build logs.

--joel

On 7/18/2014 3:16 PM, Hesham Moustafa wrote:
> On Fri, Jul 18, 2014 at 4:19 PM, Gedare Bloom <gedare at rtems.org> wrote:
>> I see you are kind of copying the file structure of ARM. I'm not sure
>> this is a good example for a simple port. m68k is more
>> straightforward.
>>
> Which file?y
>> -Gedare
>>
>> On Fri, Jul 18, 2014 at 10:17 AM, 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
>>>
>>> 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.

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985