seebs@plethora.net (Peter Seebach) writes:

> Problem #2:  sip0 never receives packets.  This feels like an interrupt
> problem.  I once saw some note on a web page (haven't been able to rediscover
> it) implying that the 83816 comes up, by default, in a mode that is less
> useful than the similar default on the 83815.  However, I can't find this
> again.  Outgoing packets work; my DHCP server is seeing requests and sending
> packets back, and ARP is working both ways.  However, that's it; no incoming
> packets ever show up, and it looks like the receive interrupt never triggers.
> 
> There is a special piece of code in the Linux port that appears to Do
> Something with interrupts.  It's a function which maps an IDSEL and an INTPIN
> into an INTLINE.  There is some conceptual similarity between this and
> some code in pci_intr_map and pci_conf_interrupt in
> powerpc/ibm4xx/pci_machdep.c, but...

Yeah. As pci_intr_map() notes, it's "highly machine-dependent". You're
encoding "Which PCI interrupt lines are mapped to which interrupt
sources on this chip?" (since each logical PCI slot has 4 interrupt
lines, and PCI doesn't formally impose any restrictions on sharing
lines on a slot, or on different slots, or anything... you could have
all PCI interrupt lines in all slots shared down to 1 interrupt input,
or you could have 4*N separate inputs).

> Even if I were absolutely sure that I knew what changes to make to that file
> for this platform, it seems wrong to make them to that file, and just as wrong
> to make them anywhere else.  That file is included from
> arch/powerpc/conf/files.ibm405gp, and I obviously want everything else in
> that file...

The file really should be board-specific -
sys/arch/evbppc/whatever/pci_machdep.c; feel free to adjust that in
your tree (remove it from files.ibm405gp and add it to
files.tams). Don't feel bad about duplicating pci_conf_read() and
pci_conf_write(); it needs some refactoring - probably, the boards
should get pci_intr_map() and pci_conf_interrupt(), and the generic
ibm405 code should get the rest.

        - Nathan