Thanks Dan, Thanks Andrew,
I am using MVista spdemo-linux-2.3.16-2000.02.10 from
ftp://ftp.mvista.com/pub/Area51/Sandpoint-8240 and
made a change to boot/ns16550.h for COM1 and defined
sandpoint_progress() to get output from the kernel.
Also, I removed the 8259 cascade intterupt and that
got me far enough to see that interrupts are not happening.
It is not a mapping issue though, since the registers can
be dumped and they show the right value.
Dan, is there a more recent version of the kernel source
which I should use?
Andrew, I am using the EPIC in direct (discrete mode) as
you are with EPIC IRQ4=SIO INTR, EPIC IRQ1=Enet Intr,
and EPIC IRQ3=PCI slot. Are you simply defining the
InitSenses[] array with 24 entries and the 0 sense for
UART, 1 for PCI (makes sense since PCI is active high).
If so, what kernel source are you using?
Finally, attached is the MPC8240 EPIC driver I am using
under VxWorks. It simply hooksup the PPC interrupt handler
to use the EPIC interrupt handler and initializes the
controller to run in discrete mode. This seems trivial to
port to Linux, the only question is how to make the
PPC irq handler call the epic IRQ handler.
Many thanks in advance.
-James
quoted
I am sure someone out there has had to deal with this issue before, so any
pointers in the right direction would be greatly appreciated.
I have HHL2.0 (Linux-2.4.2) running on an MVME2100 board (MPC8240) which
only uses the interrupts on the built-in EPIC device, no 8259. I don't
pretend to fully understand PCI interrupts, but I did discover that the
OpenPIC_InitSenses[] array is critical to getting interrupts to work, and
I also had to edit openpic.c to remove the 8259 stuff from
openpic_get_irq() in my configuration. You're working with an earlier
version though, so YMMV.
The openpic driver gets the default number of IRQs from the register on
the EPIC chip to be 24, but these are not contiguous nor in their
canonical places, so you need to provide the InitSenses array to let it
know the real configuration. I start with 16 zero entries as the first
EPIC IRQ is offset by 16, then provide up to 16 entries for the real
serial IRQ inputs to the EPIC. The value you give to each entry
determines the polarity / edge-sensitivity; my setup needs 1 for PCI
devices, but 0 for the 16550 UART. I'm not sure how you cope with the
large gap before the I2C and DMA IRQ numbers; it looks like openpic.c
needs modifying to properly cope with holes in the IRQ space, but it may
be that you can do this with a cannonicalize_irq() routine (I don't have
one, but I don't need the high IRQs and they're not essential for Linux to
run).
I discovered that even without serial interrupts working it was possible
to type commands to my init shell (mount /proc;cat /proc/interrupts was
very useful); you just have to wait up to 10 seconds for them to arrive,
and don't type more than will fill the FIFO; be prepared to wait a while
for the output to appear too!
- Andrew
--
The world is such a cheerful place when viewed from upside-down
It makes a rise of every fall, a smile of every frown
James F Dougherty wrote:
Andrew, I am using the EPIC in direct (discrete mode) as
you are with EPIC IRQ4=SIO INTR, EPIC IRQ1=Enet Intr,
and EPIC IRQ3=PCI slot. Are you simply defining the
InitSenses[] array with 24 entries and the 0 sense for
UART, 1 for PCI (makes sense since PCI is active high).
The MVME2100 uses the EPIC in serial mode not direct, so I have 16 IRQs to
deal with as well as the 16 dummy entries.
If so, what kernel source are you using?
Hard Hat Linux 2.0 Journeyman edition from ftp://ftp.mvista.com/ which is
based on Linux 2.4.2. I too started from the Sandpoint LSP.
Here are the interrupt parts of my mvme2100_setup.c file - not much to
this. I think you'll need to make another openpic call to select direct
mode, but otherwise the 2.4.2 kernel makes this very easy.
static u_char mvme2100_openpic_initsenses[] __initdata = {
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
/* 0..15 not used by EPIC but still required */
0, /* 16: Not Used */
1, /* 17: DEC21143 */
1, /* 18: PMC Slot */
1, /* 19: PC-MIP-1 Slot 2 */
1, /* 20: PC-MIP-2 Slot 1 */
1, /* 21: PC-MIP-2 Slot 2 */
0, /* 22: Not Used */
1, /* 23: Universe-2 LINT0 */
1, /* 24: Universe-2 LINT1 */
1, /* 25: Universe-2 LINT2 */
1, /* 26: Universe-2 LINT3 */
0, /* 27: Not Used */
0, /* 28: Not Used */
0, /* 29: 16550 UART */
0, /* 30: Abort button */
0, /* 31: RTC IRQ */
};
...
/* Interrupts on the MVME2100 all come through the 8240's EPIC */
static void __init
mvme2100_init_IRQ(void)
{
if (ppc_md.progress)
ppc_md.progress("mvme2100_init_IRQ: enter", 0);
OpenPIC_InitSenses = mvme2100_openpic_initsenses;
OpenPIC_NumInitSenses = sizeof(mvme2100_openpic_initsenses);
openpic_init(1, 0, NULL, -1);
if (ppc_md.progress)
ppc_md.progress("mvme2100_init_IRQ: exit", 0);
}
...
void __init
mvme2100_init(unsigned long r3, unsigned long r4, unsigned long r5,
unsigned long r6, unsigned long r7)
{
...
/* ppc_md.irq_cannonicalize = NULL; */
ppc_md.init_IRQ = mvme2100_init_IRQ;
ppc_md.get_irq = openpic_get_irq;
/* ppc_md.post_irq = NULL; */
...
}
I also added these #ifndefs in open_pic.c - they probably don't belong
here, but the i8259 stuff should be split off as already commented below:
int
openpic_get_irq(struct pt_regs *regs)
{
#ifndef CONFIG_MVME2100
extern int i8259_irq(int cpu);
#endif
int irq = openpic_irq();
#ifndef CONFIG_MVME2100
/* Management of the cascade should be moved out of here */
if (open_pic_irq_offset && irq == open_pic_irq_offset)
{
/*
* This magic address generates a PCI IACK cycle.
*/
if ( chrp_int_ack_special )
irq = *chrp_int_ack_special;
else
irq = i8259_irq( smp_processor_id() );
openpic_eoi();
}
#endif
if (irq == OPENPIC_VEC_SPURIOUS + open_pic_irq_offset) {
irq = -1;
/* That's not SMP safe ... but who cares ? */
ppc_spurious_interrupts++;
}
return irq;
}
HTH,
- Andrew
--
The world is such a cheerful place when viewed from upside-down
It makes a rise of every fall, a smile of every frown
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
On Mon, Jul 09, 2001 at 02:57:24PM -0700, James F Dougherty wrote:
Dan, is there a more recent version of the kernel source
which I should use?
The linuxppc_2_4_devel, with some minor patching (the compile will
fail and tell you where the patch is, iirc) should work fine on this.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/