powerpc mvme5500 clock off by factor of 150

[Till Straumann]

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.
>
> Peter
>
> Peter Dufault
> HD Associates, Inc.
>