Clock not running (was Re: RTEMS4.7 and its tool chain (Re: powerpc mvme5500 clock off by factor of 150))
strauman at slac.stanford.edu
Tue Mar 8 20:59:32 UTC 2005
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 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
> 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 Dufault
> HD Associates, Inc.
More information about the users