Sorry to rehash this, but I don't think we really reached a good answer 
on this yet.  I'm going to keep this particular message focused.

* Alchemy Au15XX (and possibly also others?  Au1200?) need a large 
paddr_t (64-bits).  The reason for this is that mmap() for framebuffers 
may need to return a 36-bit address.  So we cannot hide the large 
addresses inside the details of a custom bus_space implementation.  
(Recall PCI and PCMCIA address spaces are above 4GB.)  This is 
independent of whether these addresses are wired or not.

* Alchemy Au15XX parts also need a different bus_space_XXX 
implementation with support for the stream modes in order to support 
certain devices on the PCI bus, when in big-endian mode.  Other MIPS 
ports may need this too, I think, when in big-endian mode.  So if we 
don't provide our own bus_space framework, then we need to enhance the 
MIPS one.  (Fixing the mips one is probably the "right" answer, but it 
entails the larger set of changes.)

Okay, so let's assume that we'll address the bus_space stream problem by 
fixing the generic MIPS code for the moment.

My question is this: does having a larger paddr_t necessitate a 
different port?

My gut says yes, because of the kernel memory grovelers that may exist 
out in userland.  (I.e. we may need a different set of userland tools.)  
I don't think paddr_t is ever directly exposed to in ioctls, but it 
exists in various structures, like mbuf, uvm structures, etc.

Can anyone think of compelling counterarguments?

If we do need a separate port, my intent would be to create a generic 
"aumips" (or "alchemy", if that name is better) port for all systems 
based on these SoCs.  Then board details and such could likely be 
handled by kernel configuration files.  (So the DBAuXXXX and PBXXXX 
boards can each have their own configs.)

Thanks in advance.

    -- Garrett