Problem with ticker.exe for or1ksim/OpenRISC BSP

[Hesham Moustafa]

Hi,

Now ticker is working fine with interrupt handling, context switch
happening as expected. The problem is that put_name() and print_time()
are not producing any output (except for the first three instances
before _Thread_Dispatch get them executing again after
_Thread_Delay_ended has been executed for each of them), however, when
I replaced them with printk I got the output as expected. Also printf
is not working there. At the end of the test when calling
rtems_test_exit and _exit, I got "Fatal Error 4 Halted" (I have
implemented _CPU_Fatal_halt to print the error this way at cpu.h). Any
hints what's the problem?

On Sat, Jul 19, 2014 at 12:11 AM, Joel Sherrill
<joel.sherrill at oarcorp.com> wrote:
>
> 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.
>
Thanks for the patch.
> + 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
>