leon3 broken for hello

[Joel Sherrill]

On Feb 22, 2014 4:27 PM, Daniel Hellstrom <daniel at 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.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/c6607934/attachment-0001.html>