Can't enable a dummy clock driver

[Hesham Almatary]

On Mon, Jul 24, 2017 at 8:27 AM, Joel Sherrill <joel at rtems.org> wrote:
>
>
> On Jul 23, 2017 5:15 PM, "Denis Obrezkov" <denisobrezkov at gmail.com> wrote:
>
> 2017-07-23 22:30 GMT+02:00 Joel Sherrill <joel at rtems.org>:
>>
>> Increasing the stack size effectively eliminated a data corruption issue.
>> The memory corrupted likely was an RTEMS internal object structure.
>>
>> What is the stack frame size required by each subroutine call?
>
> How can I determine it?
>
>
> If it isn't directly in the CPU's ABI definition, then what is pushed to the
> stack or reserved on each subroutine call. You may see it in terms of stack
> pointer, frame pointer, reserved space, etc.
>
> For example, the m68k had a minimum of 4 registers saved and the return
> address. More registers could be saved for complicated methods.
>
> I think some risc CPU has a number like 172 bytes reserved for possible
> register saves.
>
> So the scheme varies
>
>>
>> How much stack to call printf()?
>>
>> The minimum is an educated guess by the porter that is large enough to run
>> many/most small applications. You should be able to call RTEMS services and
>> do a context switch.
>>
>> Hope that helps pick one. :)
>
>
> As for now, I have increased the minimum stack size and get the following
> 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
>
> I will try to determine how to proceed further.
>
Do you configure RISC-V to get timer (or any) interrupts? You might
want to disable all sources of interrupts, and make sure no interrupts
are generated at all, just to figure out if the problem is with
interrupt handling (including context save/restore).


>
>
> --
> Regards, Denis Obrezkov
>
>
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel



-- 
Hesham