📄 x-arm5.html
字号:
</tr><tr valign="top"><td></td><td><hr></td></tr><tr valign="middle"><td colspan="20"></td></tr></table></p callout><dl class="margin"><dd><p class="Body"><a name="84712"> </a>On ARM, while each word of a <b class="symbol_lc">double</b> is stored little-endian, the most significant word (the word containing the sign bit) is at the lower address. This is neither<i class="term"> pure big-endian</i> (as implemented in 68k processors) nor <i class="term">pure little-endian</i> (as implemented in x86 processors). Cygnus added a new binary floating point format, <b class="symbol_lc">littlebyte_bigword</b>, to GNU <b class="library">libiberty</b> and changed GDB to use this format for ARM; this implementation is adopted for WRS ARM BSPs and for CrossWind.</p><dd><p class="Body"><a name="84713"> </a>This format is chosen to be consistent with the ARM hardware floating point implementation, the ARM7500FE FPA Coprocessor Macrocell. However, since most IEEE floating point implementations are <i class="term">pure big-</i> or <i class="term">little-endian</i>, shared memory exchange of <b class="symbol_lc">double</b> variables is complicated by the unique <i class="term">cross-endianness</i> of ARM <b class="symbol_lc">double</b> variables.</p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H4"><i><a name="84715">Caches</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84716"> </a>The ARM-7TDMI processor does not have a cache or an MMU. The ARM SA-110 processor has a 16 KB instruction cache, a 16 KB data cache, a write buffer, and an MMU on the chip. The ARM SA-1100 has a 16 KB instruction cache, an 8 KB data cache, and a 512 byte minicache. The ARM-710A and ARM-810 each have an 8KB mixed instruction and data cache, with write buffer and an MMU on chip. The following subsections augment the information in <a href="c-vm.html#84369"><i class="title">7. Virtual Memory Interface</i></a>.</p><dd><p class="Body"><a name="84720"> </a>For all of the ARM caches, the cache capabilities must be used with the MMU to resolve cache coherency problems. When the MMU is enabled, the page descriptor for each page selects the cache mode, which can be cacheable or non-cacheable. This page descriptor is configured by filling in the <b class="symbol_lc">sysPhysMemDesc[ ]</b> structure defined in the BSP <i class="textVariable">installDir</i><b class="file">/target/config/</b><i class="textVariable">bspname</i><b class="file">/sysLib.c</b> file. (For more information about cache coherency, see the <b class="symbol_lc">cacheLib</b> reference entry. For information on VxWorks's MMU support, see <a href="c-vm.html#84369"><i class="title">7. Virtual Memory Interface</i></a>. For MMU information specific to the ARM family, see <a href="x-arm5.html#84744"><i class="title">Memory Management Unit</i></a>.) </p><dd><p class="Body"><a name="84727"> </a>VxWorks for ARM does not support locking and unlocking of ARM caches. Not all ARM caches support cache locking and unlocking. Thus the <b class="routine"><i class="routine">cacheLock</i></b><b>( )</b> and <b class="routine"><i class="routine">cacheUnlock</i></b><b>( )</b> routines have no effect on ARM targets and always return <b class="symbol_UC">ERROR</b>.</p><dd><p class="Body"><a name="84728"> </a>The effects of the <b class="routine"><i class="routine">cacheClear</i></b><b>( )</b> and <b class="routine"><i class="routine">cacheInvalidate</i></b><b>( )</b> routines depend on the CPU type and on which cache is specified.</p></dl></dl><dl class="margin"><dd><font face="Helvetica, sans-serif" size="-1" class="sans"><h5 class="HU"><i><a name="84729">SA-110 and SA-1100 Caches</a></i></h5></font><dl class="margin"><dd><p class="Body"><a name="86088"> </a>The SA-110 and SA-1100 processors contain an instruction cache and a data cache. By default, VxWorks uses both caches; that is, both are enabled. To disable the instruction cache, highlight the <b class="symbol_UC">USER_I_CACHE_ENABLE</b> macro in the <b class="guiLabel"><font face="Helvetica, sans-serif" size="-1" class="sans">Params</font></b> tab under <b class="symbol_UC">INCLUDE_CACHE_ENABLE</b> and remove the <b class="symbol_UC">TRUE</b>; to disable the data cache, highlight the <b class="symbol_UC">USER_D_CACHE_ENABLE </b>macro and remove the <b class="symbol_UC">TRUE</b>. </p><dd><p class="Body"><a name="84731"> </a>The data cache, if enabled, must be set to cacheable copyback mode. Although the cache appears to support a write-through mode, the effect of the write-buffer is to make this effectively a copyback mode, as all writes from the cache are buffered. The <b class="symbol_UC">USER_D_CACHE_MODE</b> parameter in the <b class="guiLabel"><font face="Helvetica, sans-serif" size="-1" class="sans">Params</font></b> tab under <b class="symbol_UC">INCLUDE_CACHE_MODE</b> should not, therefore be changed from the default setting of <b class="symbol_UC">CACHE_COPYBACK</b>.</p><dd><p class="Body"><a name="84732"> </a>It is not appropriate to think of the mode of the instruction cache. The instruction cache is a read cache that is not coherent with stores to memory so code that writes to cacheable instruction locations must ensure instruction cache validity. You should set the <b class="symbol_UC">USER_I_CACHE_MODE</b> parameter in the <b class="guiLabel"><font face="Helvetica, sans-serif" size="-1" class="sans">Params</font></b> tab under <b class="symbol_UC">INCLUDE_CACHE_MODE</b>.to <b class="symbol_UC">CACHE_WRITETHROUGH</b> and not change it. </p><dd><p class="Body"><a name="84733"> </a>With the data cache specified, <b class="routine"><i class="routine">cacheClear</i></b><b>( )</b> first pushes dirty data to memory and then invalidates the cache lines, while <b class="routine"><i class="routine">cacheInvalidate</i></b><b>( )</b> just invalidates the lines (in which case any dirty data contained in the lines is lost).</p><dd><p class="Body"><a name="84734"> </a>With the instruction cache specified, both routines have the same result: they invalidate all of the instruction cache. As the instruction cache is a separate cache from the data cache, there can be no dirty entries in the instruction cache, so no dirty data can be lost.</p></dl><dd><font face="Helvetica, sans-serif" size="-1" class="sans"><h5 class="HU"><i><a name="84735">ARM-710A Caches</a></i></h5></font><dl class="margin"><dd><p class="Body"><a name="84736"> </a>The ARM-710A has a combined instruction and data cache. The cache is actually a write-through cache, but the separate write-buffer makes this a copyback cache if the write-buffer is enabled. VxWorks uses the <b class="symbol_UC">USER_D_CACHE_MODE</b> parameter in the <b class="guiLabel"><font face="Helvetica, sans-serif" size="-1" class="sans">Params</font></b> tab under <b class="symbol_UC">INCLUDE_CACHE_MODE</b> (which must be the same as <b class="symbol_UC">USER_I_CACHE_MODE</b>) to determine whether to enable the write buffer.</p><dd><p class="Body"><a name="84737"> </a>With either cache specified, <b class="routine"><i class="routine">cacheClear</i></b><b>( )</b> flushes the write-buffer and invalidates all the ID-cache, while <b class="routine"><i class="routine">cacheInvalidate</i></b><b>( )</b> just invalidates all the ID-cache. As the cache is a combined, writethrough cache, no dirty data can be lost. </p></dl><dd><font face="Helvetica, sans-serif" size="-1" class="sans"><h5 class="HU"><i><a name="84738">ARM-810 Caches</a></i></h5></font><dl class="margin"><dd><p class="Body"><a name="84739"> </a>The ARM-810 has a combined instruction and data cache. Although the ARM-810 cache appears to support a write-through mode, the effect of the write-buffer is to make this effectively a copyback mode, as all writes from the cache are buffered. The <b class="symbol_UC">USER_D_CACHE_MODE</b> parameter in the <b class="guiLabel"><font face="Helvetica, sans-serif" size="-1" class="sans">Params</font></b> tab under <b class="symbol_UC">INCLUDE_CACHE_MODE </b>should not, therefore, be changed from the default setting of <b class="symbol_UC">CACHE_COPYBACK</b>. The ARM-810 also has a Branch Prediction capability, but this feature is not supported in this release. </p><dd><p class="Body"><a name="84740"> </a>The ARM-810 has a copyback, combined instruction and data cache and invalidating a part of the cache is not possible without invalidating other, unintended parts of the cache which might contain dirty data. Before invalidating a cache line, others may need to be pushed to memory.</p><dd><p class="Body"><a name="84741"> </a>With the data cache specified, <b class="routine"><i class="routine">cacheClear</i></b><b>( )</b> has the same effect as for the SA-110: it first pushes dirty data to memory and then invalidates the cache lines. For <b class="routine"><i class="routine">cacheInvalidate</i></b><b>( )</b>, unless <b class="symbol_UC">ENTIRE_CACHE</b> is specified, the behavior is the same as <b class="routine"><i class="routine">cacheClear</i></b><b>( )</b>. If <b class="symbol_UC">ENTIRE_CACHE </b>is specified, the entire ID-cache is invalidated.</p><dd><p class="Body"><a name="84742"> </a>With the instruction cache specified, the behavior of the <b class="routine"><i class="routine">cacheClear</i></b><b>( )</b> and <b class="routine"><i class="routine">cacheInvalidate</i></b><b>( )</b> routines is identical: both just flush the Prefetch Unit, so no dirty data is lost from the ID-cache. </p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H4"><i><a name="84744">Memory Management Unit</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84745"> </a>VxWorks provides two levels of virtual memory support. The basic level is bundled with VxWorks. The full level requires the optional product VxVMI. Both are supported by the ARM SA-110, SA-1100, ARM-710A and ARM-810 processors; the ARM-7TDMI supports neither since it does not have an MMU.</p><dd><p class="Body"><a name="84748"> </a>For detailed information on VxWorks's MMU support, see <a href="c-vm.html#84369"><i class="title">7. Virtual Memory Interface</i></a>. The following subsections augment the information in that chapter.</p></dl></dl><dl class="margin"><dd><font face="Helvetica, sans-serif" size="-1" class="sans"><h5 class="HU"><i><a name="84750">ARM Cache/MMU</a></i></h5></font><dl class="margin"><dd><p class="Body"><a name="84751"> </a>The caching and memory management functions on the ARM are both provided on-chip and are very closely interlinked. In general, caching functions on the ARM require the MMU to be enabled. Consequently, if cache support is configured into VxWorks, MMU support is also included by default. On the SA-110, the instruction cache can be enabled without enabling the MMU, but no specific support for this mode of operation is included in this release.</p><dd><p class="Body"><a name="84752"> </a>Only certain combinations of MMU and cache enabling are valid, and there are no hardware interlocks to enforce this. In particular, enabling the data cache without enabling the MMU can lead to undefined results. Consequently, if an attempt is made to enable the data cache via <b class="routine"><i class="routine">cacheEnable</i></b><b>( )</b> before the MMU has been enabled, the data cache is not enabled immediately. Instead, flags are set internally so that if the MMU is enabled later, the data cache is enabled with it. Similarly, if the MMU is disabled, the data cache is also disabled, until the MMU is reenabled.</p><dd><p class="Body"><a name="84753"> </a>All memory management is performed on "small pages" which are 4 KB in size. No use is made of the ARM concepts of "sections" or "large pages."</p><dd><p class="Body"><a name="84754"> </a>Support is provided for BSPs that include separate static RAM for the MMU translation tables. This support requires the ability to specify an alternate source of memory other than the system memory partition. A global function pointer, <b class="symbol_lc">_func_armPageSource</b> should be set by the BSP to point to a routine that returns a memory partition identifier describing memory to be used as the source for translation table memory. If this function pointer is <b class="symbol_UC">NULL</b>, the system memory partition is used. The BSP must modify the function pointer before calling <b class="routine"><i class="routine">mmuLibInit</i></b><b>( )</b>. The initial memory partition must be large enough for all requirements; it does not expand dynamically or overflow into the system memory partition if it fills. </p><dd><p class="Body"><a name="84755"> </a>Support is also provided for those SA-110/SA-1100 BSPs that provide a special area in the address space to be read, to flush the data cache. All SA-110/SA-1100 BSPs must declare a pointer (<b class="symbol_lc">sysCacheFlushReadArea</b>) to a readable, cached block of address space, used for nothing else. If the BSP has an area of the address space that does not actually contain memory, but is readable, it may set the pointer to point to that area. If it does not, it should allocate some RAM for this area. In either case, the area must be marked as readable and cacheable in the page tables. The declaration can be in the BSP <b class="file">sysLib.c</b> file, for example:</p><dl class="margin"><dd><pre class="Code2"><b><a name="84756">UINT32 sysCacheFlushReadArea[D_CACHE_SIZE/sizeof(UINT32)];</a></b></pre></dl><dd><p class="Body"><a name="84757"> </a>or in the BSP <b class="file">romInit.s</b> and <b class="file">sysALib.s</b> files, for example:</p><dl class="margin"><dd><pre class="Code2"><b><a name="84758">.globl _sysCacheFlushReadArea .equ _sysCacheFlushReadArea, 0x50000000</a></b></pre></dl><dd><p class="Body"><a name="84759"> </a>Note that a declaration in <b class="file">sysLib.c</b> of the form: </p><dl class="margin"><dd><pre class="Code2"><b><a name="84760">UINT32 * sysCacheFlushReadArea = (UINT32 *) 0x50000000;</a></b></pre></dl><dd><p class="Body"><a name="84761"> </a>cannot be used as this introduces another level of indirection, causing the wrong address to be used for the cache flush buffer.</p><dd><p class="Body"><a name="84762"> </a>During certain cache/MMU operations (for example, cache flushing), interrupts must be disabled and BSPs may wish to have control over this. The contents of the variable <b class="symbol_lc">cacheArchIntMask</b> determine which interrupts are disabled. This has the default value <b class="symbol_UC">I_BIT | F_BIT</b>, indicating that both IRQs and FIQs are disabled during these operations. If a BSP requires leaving FIQs enabled, the contents of <b class="symbol_lc">cacheArchIntMask</b> should be changed to <b class="symbol_UC">I_BIT</b>. Use extreme caution when changing the contents of this variable from its default.</p><dd><p class="Body"><a name="84763"> </a>Some systems cannot provide an environment where virtual and physical addresses are the same. (The SA-1100 CPU is an example of this.) This is particularly important for those areas containing page tables. In order to support these systems, the BSP must provide mapping functions to convert between virtual and physical addresses: the global function pointers <b class="symbol_lc">_func_armVirtToPhys</b> and <b class="symbol_lc">_func_armPhysToVirt </b>should be set to point to those functions. If these function pointers are <b class="symbol_UC">NULL</b>, it is assumed that virtual addresses are equal to physical addresses in the initial mapping. The BSP must set the function pointers before either <b class="routine"><i class="routine">mmuLibInit</i></b><b>( )</b> or <b class="routine"><i class="routine">cacheLibInit</i></b><b>( )</b>is called. </p></dl><dd><font face="Helvetica, sans-serif" size="-1" class="sans"><h5 class="HU"><i><a name="84764">ARM Memory Management Units </a></i></h5></font><dl class="margin"><dd><p class="Body"><a name="84765"> </a>On those ARM CPUs with MMUs, you can set a specific configuration for each memory page. The entire physical memory is described by <b class="symbol_lc">sysPhysMemDesc[ ]</b>, which is defined in <i class="textVariable">installDir</i><b class="file">/target/config/</b><i class="textVariable">bspname</i><b class="file">/sysLib.c</b>. This data structure is made up of state flags for each page or group of pages. All the state flags defined in <a href="c-vm5.html#84502"><i class="title">Page States</i></a> are available for virtual memory pages.</p></dl></dl><dl class="margin"><dd><p class="table" callout><table border="0" cellpadding="0" cellspacing="0"><tr valign="top"><td valign="top" width="40"><br><img border="0" alt="*" src="icons/note.gif"></td><td><hr><div class="CalloutCell"><a name="84776"><b class="symbol_UC"><font face="Helvetica, sans-serif" size="-1" class="sans">NOTE: </font></b></a>The <b class="symbol_UC">VM_STATE_CACHEABLE</b> flag listed in <a href="c-vm5.html#84511">Table 7-2</a> sets the cache to copyback mode for each page or group of pages by setting the B and C bits in the page tables. On the ARM-710A only, set the cache to writethrough mode using <b class="symbol_UC">VM_STATE_CACHEABLE_WRITETHROUGH </b>which sets only the C bit in the page tables.</div></td></tr><tr valign="top"><td></td><td><hr></td></tr><tr valign="middle"><td colspan="20"></td></tr></table></p callout><dd><p class="table" callout><table border="0" cellpadding="0" cellspacing="0"><tr valign="top"><td valign="top" width="40"><br><img border="0" alt="*" src="icons/note.gif"></td><td><hr><div class="CalloutCell"><a name="84785"><b class="symbol_UC"><font face="Helvetica, sans-serif" size="-1" class="sans">NOTE: </font></b></a>The <b class="symbol_UC">VM_STATE_BUFFERABLE</b> flag is also available on the ARM. Setting pages to this state using <b class="routine"><i class="routine">vmStateSet</i></b><b>( )</b> results in those pages being bufferable but not cacheable (only the B bit in the page tables is set). Thus writes go through the write buffer, but not the cache. If <b class="symbol_UC">VM_STATE_CACHEABLE_NOT</b> is used, pages are set to neither cacheable nor bufferable (both the B and C bits are clear).</div></td></tr><tr valign="top"><td></td><td><hr></td></tr><tr valign="middle"><td colspan="20"></td></tr></table></p callout></dl><dl class="margin"><dd><font face="Helvetica, sans-serif" size="-1" class="sans"><h5 class="HU"><i><a name="84790">ARM -710A </a></i></h5></font><dl class="margin"><dd><p class="Body"><a name="84791"> </a>The ARM-710a has an MMU Control Register that is not readable. In order to have access to the information, a soft copy is kept in the architecture code. This soft copy is initialized to the symbolic constant <b class="symbol_UC">MMU_INIT_VALUE</b>. In all WRS ARM-710A BSPs, the initialization code sets the MMU Control Register to this value, so that the register and soft copy are in step.</p><dd><p class="Body"><a name="84792"> </a>Writers of other 710a-based BSPs must ensure that the register is set to the initial value of the soft-copy, and that (assuming they use the VxWorks MMU/cache) no discrepancy between the soft copy and the register is allowed to happen.</p></dl><dd><font face="Helvetica, sans-serif" size="-1" class="sans"><h5 class="HU"><i><a name="84793">SA-1100</a></i></h5></font><dl class="margin"><dd><p class="Body"><a name="84794"> </a>The SA-1100 CPU has elements of its physical address map fixed such that it is not possible to run VxWorks on it without enabling the MMU to produce a virtual address map of the standard form (in other words, RAM mapped over the exception vectors). BSPs for this CPU (such as Brutus) select <b class="symbol_UC">INCLUDE_MMU_BASIC</b> for inclusion by default, and use the MMU to implement a standard VxWorks virtual address map.</p><dd><p class="Body"><a name="84795"> </a>The SA-1100 contains extensions to the SA-110 MMU, including a read buffer, process ID mapping, and a minicache. No support is provided for the read buffer or process ID mapping in this release. However, the extra state <b class="symbol_UC">VM_STATE_CACHEABLE_MINICACHE</b> is available on the SA-1100, which is not available on other ARM CPUs. Setting pages to this state using <b class="routine"><i class="routine">vmStateSet</i></b><b>( )</b> results in those pages being cached in the minicache and not in the main data cache. Calling <b class="routine"><i class="routine">cacheInvalidate</i></b><b>( )</b> with the parameters <b class="symbol_UC">DATA_CACHE</b>, <b class="symbol_UC">ENTIRE_CACHE</b> invalidates the minicache and the main data cache.</p></dl></dl><dl class="margin"><dd><p class="table" callout><table border="0" cellpadding="0" cellspacing="0"><tr valign="top"><td valign="top" width="40"><br><img border="0" alt="*" src="icons/warning.gif"></td><td><hr><div class="CalloutCell"><a name="84800"><b class="symbol_UC"><font face="Helvetica, sans-serif" size="-1" class="sans">WARNING: </font></b></a>In all other respects, no support is provided for the minicache and the user is entirely responsible for ensuring cache coherency between the minicache, the main cache, and main memory. If no pages are marked with the flag <b class="symbol_UC">VM_STATE_CACHEABLE_MINICACHE</b>, then cache coherency is handled in the normal fashion, using the standard <b class="routine"><i class="routine">cacheLib</i></b><b>( )</b> routines.<b></b></div>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -