On 02/12/2014 02:33 PM, Sebastian Huber wrote:
On 2014-02-12 12:11, Daniel Hellstrom wrote:
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...
Ok, I will change this to use LEON3_Cpu_Index instead of
rtems_configuration_get_user_multiprocessing_table()->node.
Is there a reason why having both timer and ckinit using the same timer?
Its a bit unusual. On other BSPs this is separate. Also the timer
initialization will destroy the setup of the clock driver.
Perhaps it is assumed that the timer interface is only used when the clock
timer is disabled?
I don't know. For the timer driver one dedicated timer should be enough.
That means that timer driver should use timer1 instead of timer0. But in the
case of AMP it should use (MAX_CPUs*1 + LEON3_Cpu_Index + 1)?
With the new CPU counter API we can also use a generic benchmark timer and get
rid of the problem with the timer driver.
That sounds good, but relies on the NGMP hardware or rather the IRQCTRLs that
support this feature starting with NGMP, so its not limited to LEON4 but can be
available in newer LEON3 designs too.
Daniel
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
