Correcting myself yet again...

Patrick Chase (patrickjchase.delete@this.gmail.com) on August 21, 2013 11:42 pm wrote:
> Where this typically arises is in systems that do not provide cache coherency for
> I/O devices. In that case it's convenient (but not necessary) for the OS to have
> multiple "views" of physical memory with different cachability attributes. If you
> have a system with 4 such views, and if you need 1/2 of the virtual address space for
> application memory, then that leaves you with (1/2)*(1/4)=1/8 of the virtual address
> space per view.
>
> Such a partitioning is actual baked into the MIPS32 memory map (the kseg[012] views,
> which range from 512-1024 MB in size). When this is done with other architectures it's
> typically implemented either in the bus fabric, or via MPU/MMU configuration.

What I should have said above is: When this is done with other architectures, it's typically implemented either in the bus fabric + MPU, or in the MMU. What I mean is the following:

1. In an MMU-less core that has an MPU (for example, Cortex R4) the SoC designer would typically instantiate replicated views of physical memory in the bus fabric. You would then use the MPU to assign different cachability attributes to each such view

2. In an MMU-equipped core you can implement both the replication and the cachability attributes in the MMU. You no longer need help from the fabric.