A few more comments below:

Simon Burge wrote:

>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 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 
total.

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
>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.
>
>  
>
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.)

    -- Garrett