Hello,
I'm not familiar with this, but indeed it look a bit wrong. The timer resources on LEON is not per-CPU, they area shared and we never know how many timers are available. Most systems have at least two
timers. In case of a multi-processor system the LEON3 usually configured which timer it takes by looking at the CPU index. It seems like there are two ways, of course the preferable way would be to
look at LEON3_Cpu_Index in case the AMP CPUs does not involve CPU0. How does other AMP systems assign resources? I guess it would be better to solve it in another way, by a BSP configuration option
instead so select timer? But then you would need different kernel libraries...
Is there a reason why having both timer and ckinit using the same timer?
Perhaps it is assumed that the timer interface is only used when the clock
timer is disabled?
Daniel
On 02/11/2014 09:46 AM, Sebastian Huber wrote:
Hello,
the LEON3 clock and timer driver use both LEON3_Timer_Regs (usually GPTIMER 0).
In separate source files we have
http://git.rtems.org/rtems/tree/c/src/lib/libbsp/sparc/leon3/clock/ckinit.c#n33
#if defined(RTEMS_MULTIPROCESSING)
#define LEON3_CLOCK_INDEX \
(rtems_configuration_get_user_multiprocessing_table() ? LEON3_Cpu_Index : 0)
#else
#define LEON3_CLOCK_INDEX 0
#endif
and
http://git.rtems.org/rtems/tree/c/src/lib/libbsp/sparc/leon3/timer/timer.c#n24
#if defined(RTEMS_MULTIPROCESSING)
#define LEON3_TIMER_INDEX \
((rtems_configuration_get_user_multiprocessing_table()) ? \
(rtems_configuration_get_user_multiprocessing_table()->node) - 1 : 1)
#else
#define LEON3_TIMER_INDEX 0
#endif
So we cannot use a clock and timer driver at the same time. Is this
intentional?
Why are there different methods used to select the index in the
RTEMS_MULTIPROCESSING case?
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
