aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorWojtek Kosior <kwojtus@protonmail.com>2020-01-14 00:19:37 +0100
committerWojtek Kosior <kwojtus@protonmail.com>2020-01-14 00:19:37 +0100
commitc56bd4c5c7d60c4640031b0d2f2342a10fd2b69d (patch)
tree5fd56961d112f33ba939f9986d9b5387b440ae7c
parent6e24b3246019e7ddca16771b8999f8041bbfde96 (diff)
downloadrpi-MMU-example-c56bd4c5c7d60c4640031b0d2f2342a10fd2b69d.tar.gz
rpi-MMU-example-c56bd4c5c7d60c4640031b0d2f2342a10fd2b69d.zip
start explaining the MMU
-rw-r--r--MMU-explained.txt18
1 files changed, 18 insertions, 0 deletions
diff --git a/MMU-explained.txt b/MMU-explained.txt
new file mode 100644
index 0000000..af350ff
--- /dev/null
+++ b/MMU-explained.txt
@@ -0,0 +1,18 @@
+Here's an explaination of steps we did to enable the MMU and how the MMU works in general.
+
+MMU stands for Memory Management Unit. It does 2 important things:
+1. It allows programs to use virtual memory addressing. Virtual addresses are translated by the MMU to physical addresses with the help of translation table.
+2. It guards against unallowed memory access. Element that only implements this functionality is called MPU (Memory Protection Unit) and is also found in some ARM cores.
+
+Without MMU code executing on a processor sees the memory as it really is. I.e. when it tries to load data from address 0x00AA0F3C it indeed loads data from 0x000A0F3C (of course, this doesn't mean it's address 0x000A0F3C in RAM; RAM can be mapped into the address space in an arbitrary way). MMU can be configured to "redirect" some range of addresses to some other range. Let's assume we configured the MMU to translate address range 0x00A00000 - 0x00B00000 to range 0x00200000 - 0x00300000. Now, code trying to perform operation on address 0x00AA0F3C would have the address transparently translated to 0x002A0F3C, on which the operation would actually take place.
+The translation affects all (stack and non-stack) data accesses as well as instruction fetches, hence an entire program can be made to work as if it was running from some memory address, while it in fact runs from a different one!
+The addresses used by program code are referred to as virtual addresses, while addresses actually used by the processor - as physical addresses.
+
+This aids operating system's memory management in several ways
+1. A program may by compiled to run from some fixed address and the OS is still free to choose any physical location to store that program's code - only a translation of program's required address to that location's address has to be configured. A problem of simultaneous execution of multiple programs compiled for the same address is also avoided in this way.
+2. A consecutive memory region might be required by some program. In a scenerio where due to earlier allocations and deallocactions no big enough (no pun intended) consecutive region of physical memory is free, smaller regions can be mapped to become accessible as a single region in virtual address space, thus avoiding the need for defragmentation.
+
+A given mapping can be made valid for only one execution mode (i.e. region only accessible from privileged mode) or only certain types of accesses (i.e. a memory region can be made non-executable, which guards against accidental jumping there by program code (important for countering buffer-overflow exploits)). An unallowed access triggers a processor exception, which passes control to an appropriate interrupt service routine.
+
+General configuration of the MMU in ARM processors it is present on is done through registers of the appropriate coprocessor (cp15). Translations are managed through translation table. It is an array of 32-bit or 64-bit entries describing how their corresponding memory regions should be mapped. A number of leftmost bits of a virtual address constitutes an index into the translation table to be used for translating it. This way no virtual addresses need to be stored in the table and MMU can perform translations in O(1) time.
+