Okay, I have PCI working now, mostly.  (wi(4) doesn't work, because the 
bus_space_read_multi_stream() seems busted -- I don't understand it, but 
I'm getting scrambled data here -- not endian reversed, but almost as if 
caching is busted or somesuch.  I have work to do there.  Advice from 
anyone who's seem problems with wi(4) like this would be helpful.)

But ath(4) works fine.  So DMA, basic register access, and interrupt 
mapping seems to work.

Here's why we need a new port, though:

* paddr_t really does have to be 64-bit, I think, in order for mmap() to 
work properly for mmap() to work (needed for framebuffers).

* the bus_space_align_chipdep.c logic from the generic mips port is 
busted for little endian busses when the processor is running in 
big-endian mode.  And it lacks the bus_space_XXX_stream methods (it 
#define's them to the non-stream versions).

* having a new paddr_t seems to break some tools.  vmstat is busted 
right now, and my first guess is that this data structure is busted.  
Kernel grovelers will be busted as well.

So, my "aumips" port (maybe "alchemy" is a better name?) is going to 
remain apart from evbmips, for the time being.

Hopefully I'll be submitting patches back to netbsd before too long.

    -- Garrett