Using an MMU
On a previous occasion, I talked about using an MMU [memory management unit] for a specific, slight esoteric purpose. I thought it might be interesting to consider its more conventional use. Also, it is worth remembering that some devices have no MMU support and many systems are built without one anyway. Having met some engineers recently, who could not conceive of the idea of no MMU, clarification may be necessary …
We need to think in terms of logical addresses, which are what the software deals with, and physical addresses, which are seen by the hardware [the memory system]. If there is no MMU, logical and physical addresses are the same. An MMU changes the mapping between logical and physical addresses.
Obviously, the simplest thing an MMU can do is map the logical addresses straight on to their physical counterparts. Of course, this is pointless without further sophistication and I will come on to that.
A common use of an MMU is to implement an operating system using process model – like Linux. In this case, each task has one or more dedicated areas of memory for its code and data. When a task is made current by the scheduler, the MMU maps these physical addresses onto a logical address area starting from 0. All the physical memory belonging to other tasks [processes] and to the OS itself is hidden from view and, thus, protected. Each process behaves as if it has free use of the entire CPU. Although this mechanism is safe and elegant, it has the drawback that there is an overhead – the MMU remapping – on every context switch.
Another approach is to implement “thread protected mode”. In most RTOSes, an MMU has not been traditionally used [or available] and all memory is visible at all times. If the MMU is set up in the trivial way I mentioned earlier, parts of the mapping may be switched off as each task is scheduled. Thus, no remapping of addresses occurs, but only the memory for the current task, and relevant parts of the OS, is visible at any one time. This provides much of the protection of process model, with a lower overhead on each context switch.
Thread protected mode [which may have other names] is available as an option with a number of popular RTOS products, including Nucleus.
The article is informative with respect to MMU.
But I thought of adding few more points (May be a problem which we encounter without MMU):
When MMU is not present in a system, then its very difficult to protect the memory. As the memory is accessible to all the threads/process, any thread/process can access any part of the memory. Without MMU it will be difficult to set the Protections, though we need to pay for the context switch and address remapping.
Mallikarjun:
You always need to “pay” for a context switch. Without an MMU [of some kind] you do not have any address remapping and memory protection is not possible at all.
I could imagine a very simple MMU which only enables the write access to blocks of memory to be enabled/disabled. This would involve much less overhead on context switch. But I have never seen anything like this implemented.
The MPU (Memory protection Unit) in ARM-Cortex proecssor’s prvoides the simple way of protecting the Memory Regions. But this MPU supports only 12 Memory regions. We have to devide the Memory subsystem into 12 regions and then set the appropriate access permissions.
Yes, the MPU is an attempt at what I was describing, but a little too lightweight/simple IMHO.
I recently has a discussion with someone about the possibility of using an MMU to protect the data structures for the yaffs file system.
The idea was to unlock the MMU when the yaffs code locks and re-locking the MMU when the yaffs code unlocks.
If the application code goes crazy then it can’t write over the yaffs subsystem.
That idea could use MMUs to protect some subsystems within an otherwise MMU-less body of code.
This is an interesting angle Charles. Thanks for the input and food for thought.