Subject: aumips port revisited
To: None <port-evbmips@netbsd.org, port-mips@netbsd.org>
From: Garrett D'Amore <garrett_damore@tadpole.com>
List: port-mips
Date: 10/20/2005 10:30:34
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