I assume nothing has been committed to address this since as of this morning,
leon3 still did not run on tsim or grsim.
On Feb 21, 2014 4:39 AM, Sebastian Huber <sebastian.hu...@embedded-brains.de>
wrote:
Hello Daniel,
On 2014-02-21 11:10, Daniel Hellstrom wrote:
> Hello,
>
> The problem is that the wrong timer is allocated. In the following code t >
> second GPTIMER core is searched for (idx=1), which most LEON systems don't
> have. The standard configuration is that the LEON chip has one GPTIMER core
> with multiple timer units within that GPTIMER core, what we should do is to
> use
> the second timer of the first GPTIMER core instead.
what is if this second timer is the watchdog? What is if this is an AMP
configuration which uses CPU index == Clock timer index?
>
> It is safe to assume that there is always two timer instances with the first
> GPTIMER. If we need a third timer, I think it would be better that it is not
> an
> critical error if the hardware is not present, or that the driver is
> selectable
> from project configuration for hardware that supports multiple timers.
One option would be to use a BSP configure option, but this destroys the PnP
nature of this BSP.
Another option is to use function pointers in the counter read/difference
functions and initialize them with the best option available.
>
> The only case I can think of that have multiple GPTIMER instances is NGMP,
> that
> reason for that is to be able to support ASMP easier by letting each OS
> instance have one GPTIMER core itself.
>
> On the GR712RC this code will also fail, this is not because the GR712RC miss
> a
> second timer core. But, because the second timer core is a GRTIMER which has a
> different PnP ID.
How can I find this second timer?
>
> +void leon3_cpu_counter_initialize(void)
> +{
> + struct ambapp_dev *adev;
> + int idx = 1;
> + volatile struct gptimer_regs *gpt;
> + unsigned new_prescaler = 8;
> + unsigned prescaler;
> + uint32_t frequency;
> +
> + adev = (void *) ambapp_for_each(
> + &ambapp_plb,
> + OPTIONS_ALL | OPTIONS_APB_SLVS,
> + VENDOR_GAISLER,
> + GAISLER_GPTIMER,
> + ambapp_find_by_idx,
> + &idx
> + );
> + if (adev == NULL) {
> + rtems_fatal(RTEMS_FATAL_SOURCE_BSP_SPECIFIC, LEON3_FATAL_CPU_COUNTER_INIT);
> + }
>
>
> Sebastian, what is the problem of using the System Clock timer
> GPTIMER[0].timer0. It is never stopped right? So basically it is running all
> the time and reading it would not cause the any conflict with the Clock
> Driver.
> _CPU_Counter_read() does not take into account the underflow of the timer, is
> this accepted by the caller?
This could be compensated by a custom _CPU_Counter_difference() function.
> Is 1MHz to slow?
I don't have enough data to know if 1MHz is too slow. We first need some
profiling data.
> Will there be a rounding problem
> with the (prescaler / new_prescaler) calculation? The prescaler is always
> initialized to a value of number of MHz the system clock is running at, whic
> > means that LEON is limited to running at a frequency of a multiple of 1MHz,
> but
> the prescaler does not have to be a multiple of 8.
After some discussions with the ESA and our consortium we ended up with the
present solution.
My first proposal was to change the prescaler of GPTIMER 0 to an even multiple
of the original prescaler close to 8, resulting in a 25MHz timer and adjust the
clock driver interval calculation accordingly.
--
Sebastian Huber, embedded brains Gmb
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
