On 02/24/2014 04:16 PM, Sebastian Huber wrote:
On 2014-02-24 15:20, Daniel Hellstrom wrote:
Sebastian, I think it's a good solution to rely on the GPTIMER[0].timer0 as a
fallback.
Looks good to me, and should work on the TSIM/GRSIM and LEON3 hardware.
Assuming that the frequency has been initialized to 1MHz for secondary GPTIMER
may be wrong when invoked from a boot loader, however this can be fixed later
if determined a problem.
Thanks for the quick review. I checked in a slightly different version that
uses now only the first GPTIMER to determine the frequency:
http://git.rtems.org/rtems/commit/?id=a4bc90af4ee55e72b18de4b64da6338634490760
Ok. that is much better I think. But it is not 100% correct, you can not be
sure that the timers are clocked at the same frequency. To your help is the
function call:
freq_hz = ambapp_freq_get(&ambapp_plb, adev_gptimer1);
That will return the frequency of any APB or AHB device in the system, the call
can be made after the frequency of the AMBA bus have been initialized in
amba_initialize() calling ambapp_freq_init().
Basically we don't have to use AMBA PnP to search for GPTIMER[0], since we assume that initialization has been performed by the system clock driver we could might as well assume that the
LEON3_Timer_Regs variable is initialized too? The problem is that the CPU cycle counter is initialized before the timer driver, but is that working for all other platform also or are we really sure no
other platform depend upon the system clock initialisation to complete?
Regards,
Daniel
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
