I just glanced in my mips32 manual and I have seen there that just 
setting cpu to use 4K pages and modifying TLB entries correctly would 
give you access to 36 bit physical address space. I guess I was wrong on 
that one. Sorry if I caused confusion.

You would have to setup one TLB entry to access that space. Look at the 
code that sets up EntryLo0/EntryLo1 in netbsd tree. Unfortunately I an 
not familiar with the netbsd kernel, I am just a user of it ;).
PFN field of these registers is the physical address bits that you are 
looking for.

Thanks,
Alex

Garrett D'Amore wrote:
> 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
>>>
>>>   
> 
> 
> 
> 
>