Andrey Petrov wrote:

>On Fri, Sep 30, 2005 at 09:08:07AM -0700, Garrett D'Amore wrote:
>  
>
>>Thanks for the advice.  It looks like I need to change the size of 
>>paddr_t, to accomodate a larger 36-bit value.  (The ARC port already 
>>does this, though I don't know why it needs 64-bit values here.)
>>
>>    
>>
>
>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'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.

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.

Btw, I appreciate all the good advice I've gotten so far, its really 
helped me focus where I look.  The advice to examine the wired mapping 
in the ARC code was particularly helpful.  Now I just have to execute on 
this. :-)

    -- Garrett

>>I believe this means I have to create a new port, so that I can provide 
>>my own types.h to override the size of the paddr_t, just like the ARC 
>>port does.  I'm proposing that this port be called "aumips".
>>
>>Does anyone have any advice about the wisdom of this course of action?  
>>Any suggestions for better courses?
>>
>>   -- Garrett
>>
>>    
>>