Clock not running (was Re: RTEMS4.7 and its tool chain (Re: powerpc mvme5500 clock off by factor of 150))

[Till Straumann]

Peter Dufault wrote:

>
> On Mar 8, 2005, at 12:36 PM, Kate Feng wrote:
>
>>
>> How did the binary  I sent you run on your  mvme5500 ?
>> If the clock is not running with the binary I sent you,
>> then you should contact Motorla for repair.
>
>
> It worked fine with your binary.
>
> There is still an interrupt always firing on mine, though.  Can you 
> decipher what that interrupt is from the output I posted before? 

I don't have the docs but since Kate is so busy I try to jump in
(not that I'm not busy ;-)):

It seems that the four bits main interrupt 1:0x0f000000
map to 4 four groups of GPP pins
1<<24 -> GPP 0.7
1<<25 -> GPP 8..15
etc.

you are getting a GPP0..7 interrupt

The MVME5500 programming manual  (pp2-4) lists the wiring
of devices to GPP0..7 on that board (unused lines not mentioned)

GPP0: COM1/COM2
GPP2: abort switch
GPP3: RTC II Thermostat Output
GPP6: GT-64260 WDMNI Interrupt
GPP7: LXT971 (10/100Mb PHY)

Hence, you'd have to print the GPP_Interrupt_Cause register contents
to find the culprit [why the code in irq.c is so complicated is a 
mystery to me].

It seems the BSP disables all unused GPP interrupts at init but fails to
clear pending unused interrupts. Maybe a PHY IRQ is pending? Anyways,
dumping the GPP cause reg should help.

If my speculations turn out to be right, the code needs to be fixed:

init should mask unused interrupts and clear all pending ones - the ISR
probably should also clear spurious IRQs to be on the safe side.

Preferrably, the whole PIC code should be overhauled and greatly
simplified, of course.

HTH
-- T.

BTW: Looking at the linux driver [2.6.11] is quite helpful
          e.g., http://lxr.linux.no/source/arch/ppc/syslib/mv64360_pic.c

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