转载： http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka13835.html
Why must I enable the MMU to use the D-Cache but not for the I-Cache?
Applies to: ARM9 processors
Answer
Data accesses may be accesses to read-sensitive or write-sensitive peripherals (eg. FIFOs), or to components which change the memory system in some way (eg. remap the physical address space). It is not safe for these types of access to be intercepted by a Data Cache, as the side-effects of these accesses would be changed or eliminated by cacheing.
One of the functions of a Memory Management Unit (MMU) is to designate (through the contents of the MMU Page Table) which areas of the memory space are suitable for cacheing (normal memory such as ROM, RAM or Flash) or not (peripheral devices). Therefore cacheing of data accesses is only safe once the Page Tables have been configured and the MMU is enabled.
Since executable code should never be fetched directly from any peripheral devices, but only from regular memory (RAM, ROM, Flash), it is considered 'safe' to allow code fetches to be cached in level 1 even without the MMU attributes available.
The ARM9 cores are optimized to run from their level 1 memory system, and the performance is slow when they are having to fetch directly from level 2 for every instruction; therefore it is very beneficial for the performance of the boot code to allow cacheing of this code, and programmers are encouraged to enable the I-Cache as early as possible in the boot sequence if the boot code is in external memory rather than I-TCM.
Since the address mapping is turned off until the MMU is enabled, this code is cached with its virtual address equal to its physical address. As soon as the MMU is enabled, these flat-mapped addresses will become invalid as the cache is now looking for virtual addresses as defined in the MMU page table, so it is important to remember to invalidate the I-Cache when enabling the MMU. The code which enables the MMU should be placed in an area whose virtual address is the same as its physical address to avoid issues with a discontinuity of the virtual addresses between consecutive instructions when the MMU becomes active.