Can't enable a dummy clock driver

Denis Obrezkov denisobrezkov at gmail.com
Mon Jul 24 06:56:24 UTC 2017


2017-07-24 8:27 GMT+02:00 Hesham Almatary <heshamelmatary at gmail.com>:

> 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
>
Interrupts are disabled.


-- 
Regards, Denis Obrezkov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20170724/38a09a21/attachment.html>


More information about the devel mailing list