leon3 broken for hello

[Daniel Hellstrom]

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...

Joel, would you like me to propose a temporary patch?

Daniel

On 22 February 2014 22:54:45 CET, Joel Sherrill <Joel.Sherrill at OARcorp.com> wrote:
>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.huber at 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.huber at embedded-brains.de
>PGP     : Public key available on request.
>
>Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140222/ff457a25/attachment-0001.html>