MMU structure and working principle (by wogoyixikexie @ gliet)

Author: wogoyixikexie @ gliet

----------------------------------------------

MMU's name has long been heard, but I have never known how it works. It seems to have been blurred in the last few months. Now it's almost time to finish. In this article, I will cite a lot of English and do not translate it, because I think my English level will misunderstand others. O (∩) O Haha ~

One of the key services provided by an MMU is the ability to manage tasks as indepen-dent programs running in their own private memory space. A task written to run under the control of an operating system with an MMU does not need to know the memory
Requirements of unrelated tasks. This Simpli attributes es the design requirements of individual tasks running under the control of an operating system.

-- Provides independent runtime space for each task.

The MMU Simpli has es the programming of application tasks because it provides the resources needed to enable virtual memory-an additional memory space that is indepen-dent of the physical memory attached to the system. the MMU acts as a translator, which
Converts the addresses of programs and data that are compiled to run in virtual memory to the actual physical addresses where the programs are stored in physical main memory. this translation process allows programs to run with the same virtual addresses while being
Held in different locations in physical memory. -- MMU is used as a converter. The program can run in the same virtual memory, and each program is stored in different physical memory.

We begin with a review of the protection features of an MPU and then present the additional features provided by an MMU. we introduce relocation registers, which hold the conversion data to translate virtual memory addresses to physical memory addresses,
And the translation lookaside buffer (TLB), which is a cache of recent address relocations. We then explain the use of pages and page tables to con should gure the behavior of the relocation registers.

-- Here we will introduce the relocation register, which stores the data converted from the virtual address to the physical address; Introduce the bypass buffer (TLB), which is the cache that stores the latest address relocation information (high-speed cache ); this section describes how to reconfigure the relocation register using pages and page tables.

We then discuss how to create regions by Con login guring blocks of pages in virtualmemory. we end the overview of the MMU and its support of virtual memory by showing how tomanipulate the MMU and page tables to support multitasking.

-- We will discuss how to create a region by configuring the block page table in the virtual memory. The final example shows how to use virtual memory to support and create a multi-task operating system.

___________________________________________________________________________

Now let's take a look at what the MMU has and what the dedicated hardware structure has.

 

-------------------------------------

To permit tasks to have their own virtual memory map, the MMU hardware performs address relocation, translating the memory address output by the processor core before it reaches main memory. the easiest way to understand the translation process is to imagine
A relocation register located in the MMU between the core and main memory. -- address relocation register is actually an address Converter

Figure 14.1 shows an example of a task compiled to run at a starting address of 0x4000000 in virtual memory. the relocation register translates the virtual addresses oftask 1 to physical addresses starting at 0x8000000.
A second task compiled to run at the same virtual address, in this case 0x400000, can be placed in physical memory at any other multiple of 0x10000 (64 KB) and mapped to 0x400000 simply by changing the value in the relocation register.

-- Why is it true that 64 KB is a multiple of the physical memory address? What is the special hardware structure of MMU?

-----------------------------------

A single relocation register can only translate a single area of memory, which is set
The number of bits in the offset portion of the virtual address. This area of virtual memory
Is known as a page. The area of physical memory pointed to by the translation process is
Known as a page frame. -- page and page frame

 

--------------- The above virtual memory conversion process ---------------

The set of relocation registers that temporarily store the translations in an arm MMU
Are really a fully associative cache of 64 relocation registers. This cache is known as
Translation lookaside buffer (TLB). The TLB caches translations of recently accessed pages.

-- The relocation register is a 64-bit relocation register cache, which is called a bypass buffer (TLB) and caches the data converted from the most recent access pages. --I think it is the address data, because arm9-is isolated from the address bus.

In addition to having relocation registers, themmuuses tables inmainmemory to store
The data describing the virtualmemorymaps used in the system. These tables of Translation
Data are known as page tables. an entry in a page table represents all the information needed
To translate a page in virtual memory to a page frame in physical memory.

-- In addition to the relocation register, MMU also uses a table in the primary storage to store data describing the ing of virtual memory. This table is called a page table.

Each sub-table in the page table stores the information required to convert a page to a page frame in the physical storage.

---------------------------------

Apage table entry (PTE) in a page table contains the following information about a virtual
Page: The physical base address used to translate the virtual page to the physical page frame,
The access permission assigned to the page, and the cache and write buffer con resume guration
The page. If you refer to Table 14.1, you can see that most of the region con resume guration data
In an MPU is now held in a page table entry. This means access permission and cache and
Write buffer behavior are controlled at a granularity (granularity) of the page size, which provides handler ner
Control over the use of memory. Regions in an MMU are created in software by grouping
Blocks of virtual pages in memory. -- the MMU area is created by a group of virtual pages in the memory using software.

___________________________________________________________________

Since a page in virtual memory has a corresponding (continuous) entry (entry) in a page table, a block
Virtual Memory pages map to a set of sequential entries in a page table. Thus, a region can
Be de incluned as a sequential set of page table entries.The location and size of a region can be
Held in a software data structure while the actual translation data and attribute information
Is held in the page tables.

Figure 14.3 shows an example of a single task that has three regions: one for text, one
For data, and a third to support the Task Stack. Each region in virtual memory is mapped
To different areas in physical memory. In the same gure, the executable code is located in wrong Ash
Memory, and the data and stack areas are located in Ram. This use of regions is typical
Operating systems that support sharing code between tasks. -- is the operating system designed like this?

With the exception of the master level 1 (L1) page table, all page tables represent 1 MB
Areas of virtual memory. If a region's size is greater than 1 MB or crosses over the 1 MB
Boundary addresses that separate page tables, then the description of a region must also

Include a list of page tables. The page tables for a region will always be derived from
Sequential page table entries in the master L1 page table. However, the locations of the L2
Page tables in physical memory do not need to be located sequentially. page table levels are
Explained more fully in section 14.4.

-- Is the virtual memory size in oemaddresstable in wince a multiple of 1 m and continuous?

Is it from this? (Actually, WinCE can use non-consecutive features, but special skills are required)

The page tables in the physical memory can be non-consecutive. -- The bootloader of youlong has this witness!

Look

 

----------------------------------------

How does MMU implement multi-task scheduling?

--------------

Page tables can reside inmemory and not bemapped tommu hardware. One way to build
Amultitasking system is to create separate sets of page tables, each mapping a unique virtual
Memory space for a task. To activate a task, the set of page tables for the speci between C task and
Its virtual memory space are mapped into use by themmu. The other sets of inactive page
Tables represent dormant tasks. This approach allows all tasks to remain resident in physical
Memory and still be available immediately when a context switch occurs to activate it.

-- The page table can reside in the memory and does not need to be mapped to MMU hardware. One way to build multitasking is to create a batch

Independent page table, each mapped to a unique task space. To activate a task, the group of page tables corresponding to the task

And its virtual memory space is used by MMU. A page table that is not activated represents a sleep task. This method causes all tasks

It can reside in the memory and can be used immediately when context switching occurs.

By activating different page tables during a context switch, it is possible to execute
Multiple tasks with overlapping virtual addresses. The MMU can relocate the execution
Address of a task without the need to move it in physical memory. The task's physical
Memory is simply mapped into virtual memory by activating and deactivating page tables.

-- Activating different page tables during context switching enables multi-task execution at overlapping virtual addresses

Possible. MMU can relocate the task address without moving the task in memory. Task

The physical memory is simply mapped to the virtual memory by activating or not activating the page table.

-- My God! Understand how MMU works !!!!!!!!!

 

--------------------------------------

When the page tables are activated or deactivated, the virtual-to-physical address map-
Pings change. Thus, accessing an address in virtual memory may suddenly translate to
Different address in physical memory after the activation of a page table. As mentioned in
Chapter 12, the ARM processor cores have a logical cache and store cached data in virtual
Memory. When this translation occurs, the caches will likely contain invalid virtual data
From the old page table mapping. To ensure memory coherency, the caches may need
Cleaning and processing ushing. The TLB may also need into ushing because it will have cached old
Translation Data. -- pay attention to clearing and clearing the cache.

--------------------

The effect of cleaning and processing ushing the caches and the TLB will slow system operation.
However, cleaning and processing ushing stale (outdated) code or data from cache and stale translated physical
Addresses from The TLB keep the system from using invalid data and breaking.

-- Although cleaning and clearing the cache and TLB will cause system operation to slow down, it will clear and clear outdated code data in the cache,

Or an outdated physical address can prevent the system from crashing with invalid data.

-------------------------------
During a context switch, page table data is not moved in physical memory; only pointers
To the locations of the page tables change. -- perform the following steps to switch tasks.

To switch between tasks requires the following steps:
1. Save the active task context and place the task in a dormant state.
2. Flush the caches; possibly clean the D-Cache if using a writeback policy.
3. Flush the TLB to remove translations for the retiring task.
4. Con login gure the MMU to use new page tables translating the virtual memory execution
Area to the Awakening task's location in physical memory.
5. Restore the context of the Awakening task.
6. Resume execution of the restored task.

 

Note: to reduce the time it takes to perform a context switch, a writethrough Cache
Policy can be used in the arm9-family. Cleaning the data cache can require hundreds
Writes to CP15 registers. By con using guring the data cache to use a writethrough policy, there is
No need to clean the data cache during a context switch, which will provide better context
Switch performance. Using a writethrough policy distributes these writes over the life
The task. Although a writeback policy will provide better overall performance, it is simply
Easier to write code for small embedded systems using a writethrough policy.

-- The write policy should be used for file systems, which is more efficient.

 

+++ ++ Why is the ing between virtual memory and physical memory fixed? ==============

Typically, page tables reside in an area of main memory where the virtual-to-physical
Address mapping is unsupported xed. By "specified xed," we mean data in a page table doesn' t change
Normal operation, as shown in Figure 14.5. This requires xed area of memory also contains
Operating system kernel and other processes. The MMU, which threads des The TLB shown
In Figure 14.5, is hardware that operates outside the virtual or physical memory space; its
Function is to translate addresses between the two Memory Spaces.

-- Do not change the ing between the two when running the system. Otherwise, errors may occur. wince is like this,

I don't know what Linux is like, as does the bootloader in ads.

---------------- The box contains a fixed ing ------------

References

Arm system developer's Guide: designing and Optimizing System Software
-- Arm system developer's Guide: designing and optimizing system software -- ARM Embedded System Development: the original English version of software design and optimization -- I personally think this is one of the best arm translation books in China, it is a thousand times better than duxx's arm architecture and programming. Although this book talks about software design and optimization, it also talks about a lot of hardware, such as MMU and cache. It is brilliant: I just wanted to write a blog about MMU and cache, and I found it too huge, it seems that this book can only be written after reading it again.
:Http://download.csdn.net/source/904273

ARM920T Technical Reference Manual -- don't talk about it anymore. People who want to know bootloader 2440 and so on must watch this thing. Some coprocessor commands are very detailed.
:Http://download.csdn.net/source/903240

Arm Architecture Reference Manual (2nd edition)-valuable arm books
Http://download.csdn.net/source/901433

 

 

 

 

Reprinted please indicate: The author wogoyixikexie @ gliet. Guilin University of Electronic Science and Technology Department 1 Association of Science and Technology, original address: Workshop.