Sign In
Forgot Password?
Sign In | | Create Account

Using an MMU

Colin Walls

Colin Walls

Posted May 17, 2010

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.

Nucleus Kernel, MMU, Nucleus, memory management unit, Linux

More Blog Posts

About Colin Walls Follow on Twitter

Colin WallsI have over thirty years experience in the electronics industry, largely dedicated to embedded software. A frequent presenter at conferences and seminars and author of numerous technical articles and two books on embedded software, I am a member of the marketing team of the Mentor Graphics Embedded Systems Division, and am based in the UK. Away from work, I have a wide range of interests including photography and trying to point my two daughters in the right direction in life. Learn more about Colin, including his go-to karaoke song and the best parts of being British: Visit The Colin Walls Blog

More Posts by Colin Walls

Comments 6

Post a Comment
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 Bidari
8:28 AM Jun 1, 2010

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.

Colin Walls
8:49 AM Jun 1, 2010

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.

Mallikarjun Bidari
9:22 AM Jun 1, 2010

Yes, the MPU is an attempt at what I was describing, but a little too lightweight/simple IMHO.

Colin Walls
1:30 PM Jun 1, 2010

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.

8:34 PM Nov 27, 2010

This is an interesting angle Charles. Thanks for the input and food for thought.

Colin Walls
3:24 PM Nov 28, 2010

Add Your Comment

Please complete the following information to comment or sign in.

(Your email will not be published)


Online Chat