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:56 PM, Kate Feng wrote:
>
>> I  would like to help you.  Sadly, I  have my own job to
>> worry about.  I will post the updated source on the WEB
>> as soon as I have made sure the change on the PCI API
>> works fine with all  my  application hardware.
>>
>>
>> If you would like to make your life easier,
>> I would recommend you to stay on the same release
>> of RTEMS (4.6.0) , BSP and the toolchain as mine.
>
>
> I took Kate off the headers.
>
> I've verified that the interrupt that is always pending and is locking 
> out the decrementer is interrupt #56, the serial port interrupt.

OK, I wasn't careful enough, thinking that the GT_GPP_IntHandlers clear 
any pending interrupt
used by the BSP [not -1 in config table]. However, the IRQ status is 
(who knows why) anded
with the current mask at entry.

--> if a serial IRQ is pending during init, the init code will mask GPP 
interrupts (but not clear any
     pending ones).
--> pending irq ends up dispatching GT_GPP_IntHandler
         - if it's a 'configured' IRQ it is not cleared as long as no 
handler is installed (i.e., masked
           in the BSP 'cache').
         - if it's a 'unconfigured' IRQ it is never cleared.

Try clearing all pending GPP irqs in 'BSP_rtems_irq_mngt_set()'
(probably 'outl(0, BT_BPP_Int_Cause)') after the
BSP_GPP_IRQ_LOWEST_OFFSET loop.

HTH
-- T.


>
> The serial ports are using ns16550.c, and are embedded in the 
> "Marvell" GT64260 chip that you not only need
> an NDA to get, but I found out today you need to go through a 
> distributor first.
>
> I checked CVS and don't see anything in the 16550 code that has 
> changed.  Can anyone think of anything that might have affected this 
> between 4.6 and the code in CVS?  I don't particularly want to spend 
> the time going back to code that isn't under CVS control.
>
> Peter
>
> Peter Dufault
> HD Associates, Inc.
>