ARM MMU Theory and Practice

In his blog “Turning on an ARM MMU” Andrew Murry listed the schemes: a memory manager would use in their combination form:

  • Split the entire virtual range into pages and point them all to one same physical page. This is often used as zero-pages, and copy on write.
  • Map multiple areas of physical memory into the same virtual area, but only one at a time.
  • Don’t map the virtual address to anything, just use it. This is known as demand paging.
  • Map the entire virtual address range to the entire physical address range.

Some references are mentioned in his blog. Those are good sources of ARM.

  • ARM System Developer’s Guide, Elsevier, 2004, by A.N. Sloss, D. Symes, C. Wright – This book provides a very good introduction to the ARM archiecture from a software perspective. It includes information, with very good examples, on how to utilise things like exceptions, caches, MMUs, etc.
  • ARM Architecture Reference Manual, ARM, ddi0100e, 2000 [Available online] – This reference manual provides the authoritative description of the ARM archiecture.

Then Andrew goes a further step to show us how to turn on a MMU in great detail.

 

Advertisements

About minghuasweblog

a long time coder
This entry was posted in All, C/C++, Hardware and tagged , , , , , , , , . Bookmark the permalink.

2 Responses to ARM MMU Theory and Practice

  1. sumi says:

    The blog links “Turning on an ARM MMU” and “how to turn on a MMU” by Andrew Murry are not opening now.Can you please send me the html pages if you have them?Thanks in advance.

  2. Turning on an ARM MMU and Living to tell the Tale: Some Theory
    http://www.embedded-bits.co.uk/2011/mmutheory/

    the link is working. some of the text is pasted below.

    In my last post I wrote some bare metal code which ran on a BeagleBoard xM as an MLO – I’d like to extend this by running this code with the MMU switched on. I want to write the absolute minimum amount of code required to turn on an ARM MMU and to come out the other side in one piece. This post describes the basic principles of operation of an MMU – we’ll come on to writing code in my next post.

    One of the most fundamental tasks of an MMU is to translate virtual addresses into physical addresses. How virtual addresses map onto physical addresses is entirely a matter of software design – the ARM MMU design provides great flexibility for helping you in this area. Just to illustrate this and to demonstrate the capability of these MMUs, I’ve come up with some perfectly valid schemes (though some of which at first may seem nonsensical):

    Split the entire virtual address range into 1KB areas (let’s call these areas ‘pages’) which all point to the same 1KB of physical memory, i.e. a many-to-one mapping
    Map multiple areas of physical memory to the same area of virtual memory – but only map one of them at a time.
    Don’t map a set of virtual address space to anything – but use it anyway
    Map the entire virtual address range to the entire physical address range – in other words an identity mapping – a type of one-to-one mapping,

    However strange these schemes or mappings may sound – most operating systems use a combination of these schemes to form the basis of some complex performance optimisations. For example consider the first scheme. Quite often there is a need to access memory that is all zeroed (in other words memset to 0) – this is often the case when allocating memory for users – it’s important not to give users previously used memory which may contain data that is sensitive or represents security concerns. However memsetting memory can be time consuming. And this is where the MMU comes in – when user’s request memory the MMU creates a set of mappings specifically for the user which points as many pages of virtual memory as the user requires to the single physical page of zeroed memory (sometimes called the zero page). The obvious flaw here is that if the user writes to this memory all the other pages in their mapping (and other user’s mappings) will all change. Fortunately the MMU also allows us to set permissions (amongst other attributes) which allow us to make these regions of virtual memory read-only – when the user tries to write, the operating system copies the zero page somewhere else in physical RAM and updates the mappings. This technique is sometimes called ‘copy on write‘. More generally this type of many-to-one mapping is also used to support things like shared libraries and the fork system call – but we can come onto these another time.

    The second mapping scheme illustrates that mappings can change on the fly. Most operating systems give the illusion that each process has the entire virtual address space – and indeed applications depend on this as they are often linked to run at specific memory addresses. In order to support this each time the scheduler let’s your process run – it maps in that processes image into virtual address in place of the last process. Without this processes would either have to be built as position independent or would have to have prior knowledge of where in memory they will live and how much memory they can use.

    The third mapping scheme is also used by operating systems to improve performance. When something tries to access a virtual address that has no corresponding physical page (or the permissions are invalid) a page fault occurs. The operating system can provide a handler for this and act accordingly. This can be very useful – for example when you execute a process in Linux it doesn’t bother to load the image into RAM prior to starting it – it will just jump to the place in RAM where it should be. Of course when it does this a page fault occurs – it’s only then that the page is actually loaded into RAM! This provides a performance boost as not all the pages in a process are always used and certainty not straight away. This technique is known as demand paging – it’s also used to support page swapping (virtual memory) – i.e. allowing a process to use more RAM than is physically available.

    And finally the last mapping is what we intend to implement – a very simple mapping where the conversion between virtual and physical addresses can be expressed by a formula (e.g. va = pa) – in other words an identity mapping.

    About Andrew Murray
    Andrew has more than 5 years of relevant commercial experience, a first class degree in Software Engineering and is the founder of Embedded Bits Limited. His day-to-day role fulfils his passion for learning and provides him with plenty of embedded Linux experience including kernel and embedded applications development on a wide variety of platforms. He loves to talk about boot time reduction and has performed a number of presentations on the topic at technical conferences – he has also been successful in achieving sub-second cold boot on Linux based products. Feel free to drop him an email at amurray@embedded-bits.co.uk

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s