Subject: Re: need advice regarding Au 1550 (MIPS) memory mapping
To: Andrey Petrov <email@example.com>
From: Garrett D'Amore <firstname.lastname@example.org>
Date: 09/30/2005 15:36:43
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
>>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