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.
With the new CPU counter API we can also use a generic benchmark timer and get
rid of the problem with the timer driver.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
