powerpc mvme5500 clock off by factor of 150

[Peter Dufault]

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

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

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.

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.

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.

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

Peter

Peter Dufault
HD Associates, Inc.