<p dir="ltr"><br>
On Feb 22, 2014 4:27 PM, Daniel Hellstrom <daniel@gaisler.com> wrote:<br>
><br>
> 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?</p>
<p dir="ltr">Please. This has had us stopped dead since it was merged.</p>
<p dir="ltr">As far as I am concerned it can be committed since it fixes a breakage. When Sebastian has a working solution, we can test that.</p>
<p dir="ltr">--joel</p>
<p dir="ltr">> Daniel<br>
><br>
> On 22 February 2014 22:54:45 CET, Joel Sherrill <Joel.Sherrill@OARcorp.com> wrote:<br>
>><br>
>> I assume nothing has been committed to address this since as of this morning,  leon3 still did not run on tsim or grsim.<br>
>><br>
>> On Feb 21, 2014 4:39 AM, Sebastian Huber <sebastian.huber@embedded-brains.de> wrote:<br>
>>><br>
>>> Hello Daniel,<br>
>>><br>
>>> On 2014-02-21 11:10, Daniel Hellstrom wrote:<br>
>>> > Hello,<br>
>>> ><br>
>>> > 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<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 > 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 <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>
><br>
><br>
> -- <br>
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.</p>