Optimization issue in RISC-V BSP

[Hesham Almatary]

Hi Denis,

If you're not using interrupts (i.e. only using dummy clock), then
trap_entry at start.S shouldn't be executed after bootstrap. That's
why I suggested you use dummy clock first to figure out if the problem
is with the context switch code or not.

I'm not getting the full context/details; did you try with dummy clock
first (interrupts disabled) and it didn't work? If so, you can set a
breakpoint at trap_entry to check it's not being executed.

Cheers,
Hesham

On Mon, Jul 31, 2017 at 8:23 PM, Denis Obrezkov <denisobrezkov at gmail.com> wrote:
> 2017-07-31 11:56 GMT+02:00 Denis Obrezkov <denisobrezkov at gmail.com>:
>>
>> 2017-07-31 1:08 GMT+02:00 Hesham Almatary <heshamelmatary at gmail.com>:
>>>
>>> On Mon, Jul 31, 2017 at 5:03 AM, Denis Obrezkov <denisobrezkov at gmail.com>
>>> wrote:
>>> > 2017-07-30 20:40 GMT+02:00 Joel Sherrill <joel at rtems.org>:
>>> >>
>>> >>
>>> >>
>>> >> On Jul 30, 2017 12:19 PM, "Denis Obrezkov" <denisobrezkov at gmail.com>
>>> >> wrote:
>>> >>
>>> >> 2017-07-30 3:10 GMT+02:00 Joel Sherrill <joel at rtems.org>:
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Jul 29, 2017 8:02 PM, "Denis Obrezkov" <denisobrezkov at gmail.com>
>>> >>> wrote:
>>> >>>
>>> >>>
>>> >>>
>>> >>> 2017-07-30 2:34 GMT+02:00 Joel Sherrill <joel at rtems.org>:
>>> >>>>
>>> >>>>
>>> >>>> Sorry to top post but this thread is very deep to answer on a phone.
>>> >>>>
>>> >>>> Try looking at the same code on the erc32 bsp and see how it is
>>> >>>> done.
>>> >>>>
>>> >>>> Also you could disable the atexit() call and see how.much further
>>> >>>> you
>>> >>>> get.
>>> >>>>
>>> >>>>
>>> >>> Ok, I will look at erc32 bsp.
>>> >>> I have removed atexit call, now I can proceed further, till the
>>> >>> while(1)
>>> >>> loop in the low ticker test.
>>> >>> But the Dummy Clock doesn't tick.
>>> >>> So, I again get the output:
>>> >>> *** LOW MEMORY CLOCK TICK TEST ***
>>> >>> 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
>>> >>>
>>> >>>
>>> >>> Low ticker has its Init task become the idle task. Your clock driver
>>> >>> simulator thread is likely never running.
>>> >>>
>>> >>> Try turning that option off in the test
>>> >>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>> Regards, Denis Obrezkov
>>> >>>
>>> >>>
>>> >>
>>> >> I tried it, but I had an error
>>> >> ../../../../../hifive1/lib/include/rtems/confdefs.h:3586:2: error:
>>> >> #error
>>> >> "CONFIGURATION ERROR: No initialization tasks or threads configured!!"
>>> >>  #error "CONFIGURATION ERROR: No initialization tasks or threads
>>> >> configured!!"
>>> >>
>>> >>
>>> >> You have to configure an Init task.
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Regards, Denis Obrezkov
>>> >>
>>> >>
>>> > Yes, I understand that, but I can't find proper configuration options.
>>> >
>>> #define CONFIGURE_INIT
>>>
>>> There might be other #ifdefs needed as well like:
>>>
>>> #define CONFIGURE_RTEMS_INIT_TASKS_TABLE
>>>
>>> Have a look at the existing hello and ticker examples (not low ticker).
>>> >
>>> >
>>> > --
>>> > Regards, Denis Obrezkov
>>> >
>>> > _______________________________________________
>>> > devel mailing list
>>> > devel at rtems.org
>>> > http://lists.rtems.org/mailman/listinfo/devel
>>>
>>>
>>>
>>> --
>>> Hesham
>>
>>
>> I was trying to implement interrupt-driven clock driver. In bspstart.c I
>> added bsp_interrupt_initialize() and
>> added an interrupt initialization code
>> static void FE310_clock_driver_support_install_isr(
>>   rtems_isr_entry Clock_isr
>> )
>> {
>>   rtems_status_code sc = RTEMS_SUCCESSFUL;
>>
>>   sc = rtems_interrupt_handler_install(
>>     1,
>>     "Clock",
>>     RTEMS_INTERRUPT_UNIQUE,
>>     (rtems_interrupt_handler) Clock_isr,
>>     NULL
>>   );
>>   if ( sc != RTEMS_SUCCESSFUL ) {
>>     rtems_fatal_error_occurred(0xdeadbeef);
>>   }
>> }
>>
>> Also, I added a call in IRQ handler:
>>
>> bsp_interrupt_handler_table[1].handler(bsp_interrupt_handler_table[1].arg);
>>
>> This way I was able to generate one tick and get an exception on the
>> second with -O0 and
>> I wasn't able to generate any interrupts with -Os option with the same
>> code.
>>
>> With -O0 code behaves differently, I think I am missing something.
>>
>> --
>> Regards, Denis Obrezkov
>
> I think I have an error during context switching/context saving.
> Hesham, can you check it:
> https://github.com/embeddedden/rtems-riscv/blob/hifive1/cpukit/score/cpu/riscv32/riscv-context-switch.S
> https://github.com/embeddedden/rtems-riscv/blob/hifive1/c/src/lib/libbsp/riscv32/hifive1/start/start.S#L196
>
>
> --
> Regards, Denis Obrezkov



-- 
Hesham