A Memory Management Unit is a hardware feature that controls virtual to physical address
translation, access permissions, and memory attributes. The MMU is configured by system
control registers and translation tables stored in memory.
A device can contain any number of MMUs. If a device has cascaded MMUs, then the
output address of one MMU is used as the input address to another MMU. A given
translation depends on the context in which it occurs and the set of MMUs that it passes
For example, a processor that implements the ARMv7A hypervisor extensions, such
as Cortex-A15, includes at least three MMUs. Typically one is used for hypervisor
memory, one for virtualization and one for normal memory accesses within an OS. When in
hypervisor state, memory accesses pass only through the hypervisor MMU. When in normal
state, memory accesses pass first through the normal MMU and then through the
virtualization MMU. For more information see the ARM Architecture Reference Manual.
provides visibility of MMU translation tables for some versions of the ARM Architecture.
To help you debug MMU related issues, DS-5 Debugger enables you
Convert a virtual address to a physical address.
Convert a physical address to a virtual address.
View the MMU configuration registers and override their values.
View the translation tables as a tree structure.
View the virtual memory layout and attributes as a table.
You can access these features using the MMU view in the graphical debugger or
using the MMU commands from the command line.
Cache and MMU data in DS-5 Debugger
In some specific circumstances, DS-5 Debugger cannot
provide a fully accurate view of the translation tables due to its limited
visibility of the target state.
The MMU hardware on the target performs a translation table walk by doing one
or more translation table lookups. These lookups require accessing memory by
physical address (or intermediate physical address for two stage translations).
However, to read or modify translation table entries, the CPU accesses memory by
virtual address. In each of these cases, the accessed translation table entries are
permitted to reside in the CPU's data caches. This means that if a translation table
entry resides in a region of memory marked as write-back cacheable and the CPU's
data cache is enabled, then any modification to a translation table entry might not
be written to the physical memory immediately. This is not a problem for the MMU
hardware, which has awareness of the CPU's data caches.
To perform translation tables walks, DS-5 Debugger must also
access memory by physical address. It does this by disabling the MMU. Because the
MMU is disabled, these memory accesses might not take into account the contents of
CPU's data caches. Hence these physical memory accesses might return stale data.
To avoid stale translation tables entries in DS-5 Debugger:
When walking translation tables where the debugger has data cache awareness,
you can enable cache-aware physical memory accesses. Use the command:
set mmu use-cache-for-phys-reads true
If you think that the translation table entries contain stale data, then you
can use the debugger to manually clean and invalidate the contents of the
CPU caches. Use the command:
NoteFlushing large caches might take a long time.