<html><head><meta name="Generator" content="Microsoft Exchange Server" /><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style></head><body>I guess the quick fix until its sorted out would be to depend on GPTIMER[0].timer0 (system clock timer) and remove the AMBA scanning. If Sebastian requires more accuracy he could add a read to the prescaler counter too. Of course, if an IRQ is received inbetween or a wraparound happens the value could not be trusted, however I believe a loop could be added that compares values between register reads...<br>
<br>
Joel, would you like me to propose a temporary patch?<br>
<br>
Daniel<br><br><div class="gmail_quote">On 22 February 2014 22:54:45 CET, Joel Sherrill <Joel.Sherrill@OARcorp.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<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">
<!-- converted from text -->
<font size="2"></font><div class="PlainText"><font size="2"><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 />
</brh></brh></brhe></font></div>
</blockquote></div></blockquote></div><br>
-- <br>
Sent from my Android phone with K-9 Mail. Please excuse my brevity.</body></html>