Subject: Re: need advice regarding Au 1550 (MIPS) memory mapping
To: Simon Burge <firstname.lastname@example.org>
From: Garrett D'Amore <email@example.com>
Date: 10/12/2005 09:54:16
A few more comments below:
Simon Burge wrote:
>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 am aware of this. I'm pretty sure I need to wire down at least one
entry for the PCI configuration space. (The IDSEL mapping on these
machines uses one upper address line for each IDSEL pin, so the address
space is huge. Therefore I do the same as Linux and just remap the page
when needed as part of my pci_conf_read/pci_conf_write logic.)
Right now I'm using 32MB entires (16MB pages) with the address map
looking like this:
* D0000000 - DFFFFFFF PCI memory (256 MB)
* E0000000 - E1FFFFFF PCI IO (32 MB)
* E2000000 - E3FFFFFF PCI config space (32 MB)
* E4000000 - E7FFFFFF PCMCIA IO (64 MB)
* E8000000 - EBFFFFFF PCMCIA attribute space (64 MB)
* EC000000 - EFFFFFFF PCMCIA memory (64 MB)
The other spaces (apart from PCI config space) I only map on demand, so
a small machine with only memory devices with small register spaces will
only wire down two entries (one for PCI config and one for register access.)
The PCI memory space is harder, because you could have big framebuffers
out there. (We will have a 32 MB framebuffer.) On our platform I
expect to see 1 page for I/O (maybe), 1 page for framebuffer, and 1 page
for other PCI memory mapped registers. So either 3 or 4 wired entries
Yes, this may have an impact on performance, but at least I can make it
work. And on these platforms the mapped PCI areas will be so frequently
used, that trying to use another approach may not be worthwhile.
Using normal virtual memory (non-wired) mappings is likely to a bit more
complicated, owing the need to get these mappings for devices that may
want to use them from interrupt context.
Admittedly, I'm less familiar with the MMU and paging code on MIPS, so
maybe it isn't a big deal. But for now, I've got the wired logic pretty
much working, and I don't think I want to take the time to do it the
other way yet.
>>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
>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, the WiSOC stuff complicates this. It seems that there are
things like the UARTS that should be underneath mips/alchemy. I'd argue
that core PCI support should be there too, as well as PCMCIA, as these
busses are part of the Au1500 and Au1550 cores.
And then you have some drivers which are probably pretty common, e.g.
auaudio (currently stubbed out AC97 support), which is semi-generic, but
has some board-specific configuration (like which PSC it is attached to.)