powerpc mvme5500 clock off by factor of 150

[Till Straumann]

Peter Dufault wrote:

>
> On Mar 7, 2005, at 1:30 PM, Till Straumann wrote:
>
>> As far as I can see (looking at src in CVS) there is a bug in the BSP
>>
>> mvme5500/irq/irq.c comments the line (BSP_install_rtems_irq_handler())
>>
>>
>> /*
>>     * Enable interrupt on device
>>        irq->on(irq);*/
>>
>>
>>
>> --> clockOn() is not called on this BSP. Note that eventually (i.e.,
>> after the decrementer reaching zero from the initial 0xffffffff count
>> [~250seconds at a decr/timebase clock rate of 16MHz]) the algorithm
>> works normally. Since Kate is probably testing on a 'live' system
>> using dynamic loading she is not observing the bug. Peter, however
>> seems to work with the statically linked test app where the bug
>> manifests itself.
>>
>> HTH
>> -- T.
>>
>>
>> Peter Dufault wrote:
>>
>>>
>>>> I do not have to test  tests/samples/ticker.  My EPICS applications
>>>> use timeouts on blocking, sleep, etc.  The clock works fine on all my
>>>> application.
>>>>
>>>> Anyway, I have a look at the code :
>>>>     status = rtems_task_wake_after( task_index * 5 * 
>>>> get_ticks_per_second()
>>>> );
>>>>
>>>> Thus the time it takes is subject to the value of task_index.
>>>> That is how he can get the factor of 5 seconds, right ?
>>>> Peter, can you print out what the value of task_index is ?
>>>
>>>
>>>
>>> If its off by 150, not by 5.  But where is the time base and 
>>> decrementer enabled?  
>>
Probably MotLoad does the job.

>>> The code to do that is in mpc6xx/mmu/mmuAsm.S in the call to 
>>> "L1_caches_enables", but the call to that is commented out in 
>>> mvme5500/startup/bspstart.c.
>>>
>>> I tried just setting the bit in bspstart.c at that point but it 
>>> didn't help.
>>
>
>
> Well, I'm baffled by this.  As I mentioned, I can't enable that 
> "irq->on()" because I get a stack backtrace when it tries to call it 
> for the first IRQ, "main irq 56" with "exception handler called for 
> exception 7". 

oops - Kate should debug this (I have no 5500 hardware and no discovery 
docs). Even
if the IRQ API is broken by design - once we adopt it we must implement 
it :-(

>
> Also, I know "clockOn" is never called during startup because I put in 
> a dramatic "printk" when it is called and it isn't. 

Sure - it's normally called by irq->on().

>
>
> That means "PPC_Set_decrementer" isn't called with anything other than 
> the initial -1, and so the decrementer value should always be 2^32. 

No. The decrementer is a counter register.

>
>
> So I tried to forceably call clockOn, but regardless of what value I 
> load using PPC_Set_decrementer I see ticks about every 57 seconds (I 
> put a printk in the clock tick), at least when it starts up. 

Hmm - be careful that your printk doesn't mess up the timing. Could be 
that the next clock tick is lost
because it occurs while printk is still executing. In this case, you get 
a new tick only when the
decrementer rolls over - still, it's strange - that should only happen 
every 2^32/fbus*4 ~ 120s

>
>
> However, when interrupt driven I/O finally happens displaying the "TAx 
> - rtems_clock_get" stuff from the "ticker" task thinking five seconds 
> have gone by I see a burst of clock ticks, as if they are being driven 
> by the serial I/O interrupt. 

bizarre - I have no clue here.

>
>
> I guess I need to get gdb working so I can see where the "tick" 
> interrupt is coming from. 

At least my GDB stub won't help you here - it's intended to debug user 
apps and needs
at least a working clock and networking [you could implement serial-IO 
methods but
you'd probably still need a working clock].

T.

>
>
> Peter
>
> Peter Dufault
> HD Associates, Inc.
>