Hi Garrett,

On Fri, Sep 30, 2005 at 03:36:43PM -0700, Garrett D'Amore wrote:

> Andrey Petrov wrote:
> 
> >On Fri, Sep 30, 2005 at 09:08:07AM -0700, Garrett D'Amore wrote:
> >
> >If you need 36-bit address (constant prefixes even) only for PCI access 
> >then
> >likely you can work it out in your bus_.. functions. And that wouldn't 
> >justify
> >larger paddr_t and new port, I understand temptation thou -)
> >
> Hmmm... looking at this, the problem isn't just setting up DMA, but also 
> setting up the MMU mappings.  I'm pretty sure that the new port is the 
> right way to handle this.
> 
> There is precedent -- the ARC port does much the same thing.  Actually, 
> it does this apparently because of a need to map above KSEG0/1.  I not 
> only need to map above that, but above 4GB entirely!  I'll map the PAs 
> into KSEG2, most likey, following the example of the ARC port.
> 
> So what I'm going to do is break out the AMD/Alchemy stuff from evbmips 
> into a new port "aumips".

I don't think there's a need to move all the existing Alchemy eval board
support from out of evbmips.  For 64-bit paddr_t support, you can just
add something like:

        options _MIPS_PADDR_T_64BIT

to evbmips/conf/std.pb1000 (ignoring for now that the file should
probably be renamed to std.alchemy).  There may be issues with building
LKMs by doing this, but that's a bridge that can be crossed later.  I'm
also not sure that you should be wiring down TLBs like the ARC port
does.  The Au1 core has only 32 TLB entries, so it's not as if you want
to lower the general number available any more than you have too.

I'm not sure if you're targetting the AMD/Alchemy Au1550 eval board
or an entirely new board.  Ignore the next few paragraphs if you're
targeting the DBAu1550. :-)

If the board you're targeting is an SBC or thin-client type machine,
you'd create a new sub-port under evbmips.  The current evbmips PB1000
sub-port (again, that probably should be renamed to ALCHEMY as well)
is specifically for the AMD/Alchemy eval boards.  Maybe something like
evbmips/tadpole.

An example of a recently added SBC is the ARM TS7200 (under evbarm) and
a somewhat less recent example of a thin-client is the PowerPC Explora
(under evbppc).  Some other currently separate ports (such as algor and
sbmips) probably should be moved under evb* at some stage as they also
fit in this category.

If the board you're targeting is more or less a standalone computer,
then that would probably be enough to justify a completely new port.
However, that new port wouldn't be "aumips" but something along the
board/model name of your port.  Without knowing more about your target,
"tadpolemips" or "autadpole" something similar, given that there are
other sorts of tadpoles available with different CPUs.

The ARC port you've already mentioned is an example of a "normal"
standalone computer, and thus has its own port.

> I'm also going to move the alchemy specific logic from mips/alchemy to 
> the aumips directory.  Hopefully this cleanup will make it easier to see 
> what is going on.

The way the arch directories are structured is that any CPU specific
support is under arch/mips and any board/port specific support is under
arch/<machine-name>.

By doing this, multiple different machines can use the same CPU support.
If, for example, a new game console called (for example) the frobnitz
were to be based on an Alchemy CPU, it would possibly live under
arch/frobnitz but use the shared Alchemy support from arch/mips/alchemy.

> Of course, whether or not any of this gets committed to NetBSD-current 
> is unclear at this time.  I hope that once I have pretty much the full 
> Au1550 (and probably also the Au1500) going, that I can get the stuff 
> committed.  I'm going to try to do it in a way that localizes 
> "board-specific" changes to the configuration files, since otherwise 
> these SoCs all have pretty much the same stuff on them.

You mentioned (I think) that USB was broken?  It works on at least
the Au1000 and Au1500, and I thought the USB controller on the Au1550
was the same.  You may have some board specific problem rather than a
general Au1xxx USB problem there.

Cheers,
Simon.
--
Simon Burge                                   <simonb@wasabisystems.com>
NetBSD Development, Support and Service:   http://www.wasabisystems.com/