IRQ mapping on 405GPr board, et al.

I'm making some progress with my TAMS 3011 port.  Thanks to some friendly
and patient folks, I have a workaround for getting the boot ROM information
needed for startup, and I can now probe both Ethernet devices correctly.

I have a couple of problems where I am not sure what the right solution is,
and I'd like some advice.

Problem #1:  Machine hangs on reboot.  Debugging printfs reveal that we're
getting to ppc4xx_reboot, which looks pretty simple... But it hangs on this
machine, most but not all of the time.  For a really interesting data point,
if I halt (which drops to debugger), the debugger's reboot command works.
Since it's the same syscall, and it should be going to the same place, the
only thing I can think of is that "ba 0" is not always the right thing to do
after writing a reset into the status register on this hardware.

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...

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...

That said, manually hacking it to try different interrupt values seems not to
have any useful effect, so it may be that the problem is something else with
the 83816.

-s