On Feb 22, 2014 4:27 PM, Daniel Hellstrom <dan...@gaisler.com> wrote:
>
> 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?
Please. This has had us stopped dead since it was merged.
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.
--joel
> Daniel
>
> On 22 February 2014 22:54:45 CET, Joel Sherrill <joel.sherr...@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.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.
>
>
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
