对不起,让大伙久等了
|
这是ADS安装后自带的在线手册《ARM Architecture Reference Manual》的第11章 Introduction to Memory and System Architectures<br />原文如：<br /><br /><br /><br />11 Introduction to Memory and System Architectures<br />This chapter provides a high-level overview of memory and system architectures. It contains the following sections:<br />about the memory system<br />system-level issues.<br />11.1 About the memory system<br /><font color=#0000FF>ARM processors are used in a wide range of embedded systems and other applications. The memory system requirements of these applications vary considerably, from simple memory blocks with a flat address map, to systems using any or all of the following to optimize their use of memory resources:<br /> <li>multiple types of memory</li><br /> <li>caches </li><br /> <li>write buffers </li><br /> <li>virtual memory and other memory remapping techniques.</li></font><br />The range of memory-mapped I/O devices that can be used adds further to the variety of systems based on ARM processors. <br />Most systems need to initialize and control their memory system facilities in various ways, such as:<br />Enabling a cache, to ensure that its performance benefits are realized.<br />Setting up the virtual-to-physical address mapping for a virtual memory system.<br />Restricting access to memory regions.<br />Ensuring that the correct accesses to memory-mapped I/O devices occur, and that they occur at the correct times. (This usually happens automatically in the simplest memory systems, but caches and other facilities in more complex systems can interfere with it.)<br />The standard way to perform memory system control in ARM-based systems is to use coprocessor 15 (CP15), which is also known as the System Control coprocessor. Chapter 12 The System Control Coprocessor provides a top-level overview of this coprocessor.<br />The rest of Part B (Chapter 13 through Chapter 16) describes standardized ways to perform a variety of memory system control operations using CP15:<br />Chapter 13 Memory Management Unit<br />Describes a sophisticated system to control virtual-to-physical address mapping, access permissions to memory, and other memory attributes, based on the use of a Memory Management Unit (MMU).<br />Chapter 14 Protection Unit<br />Describes a simpler Protection Unit system which is suitable for many applications which do not require the full facilities provided by the MMU memory system.<br />Chapter 15 Caches and Write Buffers<br />Describes facilities to control caches and write buffers. These are common to the MMU and Protection Unit systems<br />Chapter 16 Fast Context Switch Extension<br />Describes the Fast Context Switch Extension, which facilitates fast switching between up to 128 processes executing in separate process blocks, each of size up to 32MB.<br />Note<br />Because of the wide variety of systems based on ARM processors, all functionality described in Part B might be inappropriate to any given system. Furthermore, some ARM processors have implemented functions in a different manner to the one described here. Because of this, the datasheet or Technical Reference Manual for a particular ARM processor is the definitive source for its memory and system control facilities.<br />Part B therefore does not attempt to specify absolute requirements on the functionality of the System Control coprocessor or other memory system components. Instead, it contains guidelines which, if followed: <br />?mean that the system is more likely to be compatible with existing and future ARM software.<br />?probably make it easier to port incompatible software to the system.<br />In order to provide an adequate description of the range of memory and system facilities on existing ARM implementations, Part B describes a number of options that will not be used on new ARM implementations. For information on the rules that must be followed by new implementations of the memory and system architectures, contact ARM Ltd. <br />The fact that Part B describes a broad range of facilities, many of which are used only on some existing ARM implementations, also means that architecture version numbers for the memory and system architectures would not be helpful or descriptive. They are therefore not used.<br />11.2 System-level issues<br />This section lists a number of general and operating-system issues that the system designer needs to address when using an ARM processor.<br />11.2.1 Memory systems, write buffers and caches<br />ARM processors and software are designed to be connected to a byte-addressed memory. Word and halfword accesses to the memory ignore the alignment of the address and access the naturally-aligned value that is addressed (so a memory access ignores address bits 0 and 1 for word access, and ignores bit 0 for halfword accesses). The endianness of the ARM processor should normally match that of the memory system, or be configured to match it before any non-word accesses occur (when the endianness is configurable and CP15 is implemented, bit[7] of CP15 register 1 controls the endianness).<br />Memory that is used to hold programs and data should be marked as follows:<br />稭ain (RAM) memory is normally set as cachable and bufferable.<br />稲OM memory is normally set as cachable, and should be marked as read only, so the bufferable attribute is not used and should be 1.<br />Write buffers<br />Some ARM implementations incorporate a merging write buffer that subsumes multiple writes to the same location into a single write to main memory. Furthermore, some write buffers re-order writes, so that writes are issued to memory in a different order to the order in which they are issued by the processor. Therefore, I/O locations should not normally be marked as bufferable, to ensure all writes are issued to the I/O device in the correct order.<br />For writes to bufferable areas of memory, memory aborts can only be signaled to the processor as a result of conditions that are detectable at the time the data is placed in the write buffer. Conditions that can only be detected when the data is later written to main memory (such as a parity error from main memory) must be handled by other methods (typically by raising an interrupt).<br />Caches<br />Frame buffers can be cachable, but frame buffers on writeback cache implementations must be copied back to memory after the frame buffer has been updated. Frame buffers can be bufferable, but again the write buffer must be written back to memory after the frame buffer has been updated.<br />ARM processors do not normally support cache coherence between the ARM and other system bus masters. Bus snooping is not supported. If memory data is to be shared between multiple bus masters without taking special software measures to ensure coherency, then the data must be mapped as: <br />穟ncachable to ensure that all reads access main memory<br />穟nbufferable to ensure that all write access main memory.<br />Alternatively, using software, you can manage the coherence of data buffers that are read or written by another bus master by:<br />穋leaning data from writeback caches and write buffers to memory when the processor has written to the data buffer and before the other bus master reads the buffer<br />穎lushing relevant data from caches when the buffer is being read after the other bus master has written the buffer. <br />You can use an爑ncached, unbuffered semaphore to maintain synchronization between multiple bus masters (see燬emaphores). <br />For implementations with writeback caches, all dirty cache data must be written back before any alterations are made to the MMU page tables, to ensure that cache line write back can use the page tables to form the correct physical address for the transfer.<br />You can index caches using either virtual or physical addresses. Physical pages must only be mapped into a single virtual page, otherwise the result is UNPREDICTABLE. ARM processors do not normally provide coherence between multiple virtual copies of a single physical page.<br />Some ARM implementations support separate instruction and data caches. Coherence between the data and instruction caches is not necessarily maintained in hardware, so if the instruction stream is written, the instruction cache and data cache must be made coherent. This can entail:<br />穋leaning the data cache (storing dirty data to memory)<br />穌raining the write buffer (completing all buffered writes)<br />穎lushing the instruction cache.<br />Instruction and data memory incoherence occurs after a program has been loaded (and therefore treated as data) and is about to be executed. It also occurs if self-modifying code is used or generated.<br />11.2.2 Interrupts<br />ARM processors implement fast and normal levels of interrupt. Both interrupts are signaled externally, and many implementations synchronize interrupts before an exception is raised. <br />Fast interrupt request (FIQ)<br />Disables subsequent normal and fast interrupts by setting the I and F bits in the CPSR.<br />Normal interrupt request (IRQ)<br />Disables subsequent normal interrupts by setting the營 bit in the CPSR.<br />For more information, see Exceptions.<br />Canceling interrupts<br />It is the responsibility of software (the interrupt handler) to ensure that the cause of an爄nterrupt is canceled (no longer signaled to the processor) before interrupts are re-enabled (by clearing the I and/or F bit in the CPSR). Interrupts can be canceled with any instruction that might make an external data bus access, meaning any load or store, a爏wap, or any coprocessor instruction. <br />Canceling an interrupt via an instruction fetch is UNPREDICTABLE. <br />Canceling an interrupt with a load multiple that restores the CPSR and re-enables interrupts is UNPREDICTABLE.<br />Devices that do not instantaneously cancel an interrupt (that is, they do not cancel the爄nterrupt before letting the access complete) must be probed by software to ensure that interrupts have been canceled before interrupts are re-enabled. This allows a燿evice connected to a爎emote I/O bus to operate correctly.<br />11.2.3 Semaphores<br />The Swap and Swap Byte instructions have predictable behavior when used in two ways:<br />稴ystems with multiple bus masters that use the Swap instructions to implement semaphores to control interaction between different bus masters. <br />In this case, the semaphores must be placed in an uncached and unbufferable region of memory. The Swap instruction then causes a (locked) read-write bus transaction. <br />This爐ype of semaphore can be externally aborted.<br />稴ystems with multiple threads running on a uniprocessor that use the Swap instructions to implement semaphores to control interaction of the threads.<br />In this case, the semaphores can be placed in a cached and bufferable region of memory, and a (locked) read-write bus transaction might or might not occur. The Swap and Swap Byte instructions are likely to have better performance on such a system than they do on a system with multiple bus masters (as described above). <br />This type of semaphore has UNPREDICTABLE behavior if it is externally aborted.<br />Semaphores placed in uncachable/bufferable memory regions have UNPREDICTABLE results. Semaphores placed in cachable/unbufferable memory regions have UNPREDICTABLE results.
|
|
楼主
