Problem with ticker.exe for or1ksim/OpenRISC BSP

Hesham Moustafa heshamelmatary at gmail.com
Sat Jul 26 02:43:48 UTC 2014 

Hi,

On Fri, Jul 25, 2014 at 4:32 AM, Hesham Moustafa
<heshamelmatary at gmail.com> wrote:
> 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?
>
I tried to add the following lines to or1ksim/configure.ac to get
around printf problem:
"RTEMS_BSPOPTS_SET([TESTS_USE_PRINTK],[*],[1])
RTEMS_BSPOPTS_HELP([TESTS_USE_PRINTK],[tests use printk() for output])"

but still there is the same problem. So, I have added the following
snippet of code
to buffer_test_io.h
"#if defined(__OR1K__)
#define TESTS_USE_PRINTK
#endif"
And ticker is now working fine. I am not sure this is the best
solution giving the following
output:

"*** BEGIN OF TEST CLOCK TICK ***
TA1  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA2  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA3  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA1  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA2  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA1  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA3  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA1  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA2  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA1  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA1  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA3  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA1  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA2  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA1  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA2  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA1  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA3  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA1  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA2  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA1  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA1  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA3  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA1  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA2  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA1  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA2  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA1  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA3  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA1  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA2  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA1  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA1  - rtems_clock_get_tod - 09:00:00   12/31/1988
*** END OF TEST CLOCK TICK ***
Fatal Error 0 Halted"

> 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
>>

More information about the devel mailing list