<p dir="ltr">I assume nothing has been committed to address this since as of this morning, leon3 still did not run on tsim or grsim.</p>
<div class="quote">On Feb 21, 2014 4:39 AM, Sebastian Huber <sebastian.huber@embedded-brains.de> wrote:<br type='attribution'><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><html><head><meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style></head>
<body>
<font size="2"><div class="PlainText"><span style="background-color: #ffff00">Hello</span> Daniel,<br>
<br>
On 2014-02-21 11:10, Daniel Hellstrom wrote:<br>
> <span style="background-color: #ffff00">Hello</span>,<br>
><br>
> The problem is that the wrong timer is allocated. In the following code t<brhe>
> second GPTIMER core is searched for (idx=1), which most LEON systems don't<br>
> have. The standard configuration is that the LEON chip has one GPTIMER core<br>
> with multiple timer units within that GPTIMER core, what we should do is to use<br>
> the second timer of the first GPTIMER core instead.<br>
<br>
what is if this second timer is the watchdog? What is if this is an AMP <br>
configuration which uses CPU index == Clock timer index?<br>
<br>
><br>
> It is safe to assume that there is always two timer instances with the first<br>
> GPTIMER. If we need a third timer, I think it would be better that it is not an<br>
> critical error if the hardware is not present, or that the driver is selectable<br>
> from project configuration for hardware that supports multiple timers.<br>
<br>
One option would be to use a BSP configure option, but this destroys the PnP <br>
nature of this BSP.<br>
<br>
Another option is to use function pointers in the counter read/difference <br>
functions and initialize them with the best option available.<br>
<br>
><br>
> The only case I can think of that have multiple GPTIMER instances is NGMP, that<br>
> reason for that is to be able to support ASMP easier by letting each OS<br>
> instance have one GPTIMER core itself.<br>
><br>
> On the GR712RC this code will also fail, this is not because the GR712RC miss a<br>
> second timer core. But, because the second timer core is a GRTIMER which has a<br>
> different PnP ID.<br>
<br>
How can I find this second timer?<br>
<br>
><br>
> +void leon3_cpu_counter_initialize(void)<br>
> +{<br>
> + struct ambapp_dev *adev;<br>
> + int idx = 1;<br>
> + volatile struct gptimer_regs *gpt;<br>
> + unsigned new_prescaler = 8;<br>
> + unsigned prescaler;<br>
> + uint32_t frequency;<br>
> +<br>
> + adev = (void *) ambapp_for_each(<br>
> + &ambapp_plb,<br>
> + OPTIONS_ALL | OPTIONS_APB_SLVS,<br>
> + VENDOR_GAISLER,<br>
> + GAISLER_GPTIMER,<br>
> + ambapp_find_by_idx,<br>
> + &idx<br>
> + );<br>
> + if (adev == NULL) {<br>
> + rtems_fatal(RTEMS_FATAL_SOURCE_BSP_SPECIFIC, LEON3_FATAL_CPU_COUNTER_INIT);<br>
> + }<br>
><br>
><br>
> Sebastian, what is the problem of using the System Clock timer<br>
> GPTIMER[0].timer0. It is never stopped right? So basically it is running all<br>
> the time and reading it would not cause the any conflict with the Clock Driver.<br>
> _CPU_Counter_read() does not take into account the underflow of the timer, is<br>
> this accepted by the caller?<br>
<br>
This could be compensated by a custom _CPU_Counter_difference() function.<br>
<br>
> Is 1MHz to slow?<br>
<br>
I don't have enough data to know if 1MHz is too slow. We first need some <br>
profiling data.<br>
<br>
> Will there be a rounding problem<br>
> with the (prescaler / new_prescaler) calculation? The prescaler is always<br>
> initialized to a value of number of MHz the system clock is running at, whic<brh>
> means that LEON is limited to running at a frequency of a multiple of 1MHz, but<br>
> the prescaler does not have to be a multiple of 8.<br>
<br>
After some discussions with the ESA and our consortium we ended up with the <br>
present solution.<br>
<br>
My first proposal was to change the prescaler of GPTIMER 0 to an even multiple <br>
of the original prescaler close to 8, resulting in a 25MHz timer and adjust the <br>
clock driver interval calculation accordingly.<br>
<br>
-- <br>
Sebastian Huber, embedded brains Gmb<brH>
<br>
Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
Phone : +49 89 189 47 41-16<br>
Fax : +49 89 189 47 41-09<br>
E-Mail : sebastian.huber@embedded-brains.de<br>
PGP : Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
</div></font>
</body>
</html>
</blockquote></div>