How is that? And how about the 68040? Of course I ask this in the context of Apollo Core 
The problem with the 68040 and above (and to some degree also the 68030) is that they don't have a cache-inibit-in line anymore (and it's partially non-functional on the 68030, as said, as it only applies to read, but not to write accesses), so you can no longer turn on and off caching based on some hardware logic that identifies chip ram and/or custom chip/hardware IO accesses. This is how all GVP and CBM cards attempted to solve the caching issue for the 68030, or rather believed so. That \CIIN was non-working for write accesses was found out only later, and Motorola then declared it as "specification change" in the later versions of the 68030 stating that one should use the MMU.
So, one needs to disable caching by software one way or another, on the 68040 and 68060 for certain, on the 68030 with its small cache it usually goes unnoticed since the data leaves the cache so early that it does (typically) not matter much. Exceptions do exist, though.
In principle, the TTx-registers of the 040 and 060 are "almost sufficient" because they could map the entire lower 16MB as non-cachable (all of the chip ram, all of the hardware registers), even though this is a bit extreme (also all of Zorro expansion ram becomes non-cachable by that). The exec coldstart does exactly that as "best attempt".
However, it doesn't end there: Also, you need the MMU to make DMA working. Due to a side effect of the '040 and '060 copyback cache, you need to temporarily turn off copyback caching for non-cache-aligned DMA read accesses as otherwise a dirty cache-line could overwrite data read from disk.
In other words: Either full MMU control, or only writethrough cache and no copyback cache. Or no stable DMA. Pick your poison.
In case you wonder: No, the 040 and 060 bus snooper does not help because the bus snooper cannot snoop behind the Zorro bus drivers that may separate the CPU bus from the Zorro bus.
Concerning Apollo: Yes, Gunnar and I had a long dispute over the issue as I really had some doubts concerning this problem. It turned out that the Apollo core only implements a write-through cache, so the DMA problem does not exist, and otherwise uses a fixed (but in principle software-adjustable) cache control in page sizes of 256K. This is much too coarse for most useful MMU application, but fine enough to ensure that chip RAM and IO resources are not cached, while everything else can be cached. So in principle, the Apollo core is working in this respect, though not as flexible as I was hoping for.
