Simon,

First off thanks for getting back to me.  More detail follows:

Simon Burge wrote:

>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
>  
>
I thought about this, but I am concerned about this type being different 
for userland bits.  It seems like there is only one userland for 
evbmips, and having the size of paddr_t be different for diffferent 
kernels might break some things (tools, etc.)

If paddr_t is truly confined to the kernel and is not exposed to any 
user applications, then it will work.

I've also considered *not* changing paddr_t and instead just localizing 
the larger types to the logic that wires down the addresses.  For now 
I've gone the other way, but I might go back and localize it.  
Certainly, if we are going to remain in evbmips then I think it is a 
good idea to try to minimize changes to the system types like paddr_t.

>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. :-)
>  
>
I'm targetting both the DBAu1550 (which is my bring up machine), and 
will eventually have our own board design.  I fully realize that parts 
of the design will be board-specific, but for the moment everything I'm 
doing is generic to the Au1550 chip itself.  (And pretty much for the 
Au1500 as well.)

>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.
>  
>
Yes.  But ideally I think a lot of the changes from our board to the 
eval boards will be easily handled by a different kernel config.  The 
main source files should all be the same, I think.

In any case, whether our "tadpole" platform lives in a separate port or 
in evbmips should not be a major concern, because I strongly doubt that 
we will be putting *that* part of the code back into NetBSD.  (We are 
likely to have some proprietary bootup logic, as well as other bits that 
are not generally applicable.)

>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.
>  
>
Okay.  So it seems like the idea is that evbmips should be a catchall 
for all of the various mips ports.

>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.
>  
>
Yes, we could do that.  But my intent is not to have a full port, 
because I don't think I need one.  The only truly unique part of our 
kernel will probably be the bits around the booting logic.  (We may or 
may not use yamon.)

>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.
>  
>
Okay, perhaps I was too hasty in moving this.  I may have been confused 
about the delineation between "port" and "processor".  I would have 
thought that a "port" would be to a processor, and that most of the 
other details (IO, address maps, IRQs etc.) would be handled by 
configuration files.

>  
>
>>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.
>  
>
It doesn't work on the Au1550.  It complains about a bad OHCI version.  
I don't have an Au1500 to test it with.  (I did fix the address and 
interrupt mappings for this, because they are different on the Au1550.)

    -- Garrett

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