leon3 broken for hello

[Joel Sherrill]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140222/5e1b7f68/attachment-0001.html>