Hi, On Fri, Jul 25, 2014 at 4:32 AM, Hesham Moustafa <heshamelmat...@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.sherr...@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 <ged...@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 <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 >>>>> >>>>> 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.sherr...@oarcorp.com On-Line Applications Research >> Ask me about RTEMS: a free RTOS Huntsville AL 35805 >> Support Available (256) 722-9985 >> _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
