Electronics Guide

Physical vs. Virtual Addresses

In systems without an MMU, the addresses generated by the processor correspond directly to physical memory locations. When the CPU requests data at address 0x1000, the memory controller accesses physical location 0x1000. This direct mapping is simple and deterministic but limits flexibility.

With an MMU enabled, the processor generates virtual addresses that the MMU translates to physical addresses before memory access occurs. A virtual address of 0x1000 might map to physical address 0x50001000, or any other physical location the system configures. This indirection enables powerful capabilities that would be impossible with direct physical addressing.

The translation process occurs transparently to most software. Application code references virtual addresses without awareness of underlying physical memory organization. Only privileged system software configuring the MMU needs knowledge of the physical memory layout.

Address Space Concepts

Virtual memory creates separate address spaces for different software components. Each process or task can have its own virtual address space, providing the illusion of exclusive access to memory resources. The operating system's address space typically maps differently from application spaces, with privileged regions inaccessible to user code.

The size of virtual and physical address spaces need not match. A 32-bit processor might support 4 GB of virtual address space per process while the physical system contains only 256 MB of RAM. Conversely, systems with Physical Address Extension (PAE) or similar features can address more physical memory than a single virtual address space allows. Arm's Large Physical Address Extension (LPAE), for example, lets a 32-bit core address up to 40 bits of physical memory through a three-level page table format.

In embedded systems, address space sizes are typically smaller than in desktop systems, and the relationship between virtual and physical spaces is often simpler. Many embedded MMUs support 32-bit virtual addresses with direct mapping of most physical memory, reserving virtual memory features for specific protection and isolation needs.

Benefits in Embedded Systems

Virtual memory provides several key benefits that justify its complexity in embedded applications:

• Memory protection: The MMU prevents processes from accessing memory outside their allocated regions. A malfunctioning or malicious task cannot corrupt the operating system or other tasks, dramatically improving system reliability and security.
• Address space isolation: Each task operates in its own virtual address space, simplifying software development. Different tasks can use identical virtual addresses without conflict, enabling position-independent code and simplifying memory allocation.
• Efficient memory utilization: Virtual memory enables flexible physical memory allocation. Non-contiguous physical memory regions can appear contiguous in virtual space. Memory can be allocated on demand, and unused physical pages can be reclaimed.
• Hardware abstraction: Software can be developed independently of physical memory layout. The same binary can run on systems with different memory configurations, with only the page tables requiring customization.

Page-Based Translation

Most MMUs divide memory into fixed-size pages, typically 4 KB in size. Virtual and physical address spaces are partitioned into pages, and the MMU maintains mappings between virtual and physical pages. This granularity balances translation table size against flexibility.

A virtual address conceptually divides into two parts: the virtual page number (VPN) identifies which page contains the address, while the page offset specifies the location within that page. The MMU translates the VPN to a physical page number (PPN) while preserving the page offset, producing the physical address.

For a 4 KB page size with 32-bit addresses, the lower 12 bits form the page offset (2¹² = 4096), and the upper 20 bits form the virtual page number. Translation involves looking up the VPN in page tables to find the corresponding PPN, then concatenating the PPN with the unchanged page offset.

Page Table Structure

Page tables store the mappings between virtual and physical pages. The simplest organization uses a single-level page table with one entry per virtual page. For a 32-bit address space with 4 KB pages, this requires 2²⁰ entries, consuming several megabytes of memory even before considering multiple processes.

Multi-level page tables reduce memory requirements by organizing mappings hierarchically. A two-level system divides the virtual page number into two parts: the first indexes into a page directory that points to page tables, and the second indexes into the page table to find the physical page number. Unused regions of virtual address space require no page table storage, as their page directory entries simply indicate no mapping exists.

Arm processors commonly use two-level page tables with configurable page sizes. The first-level (L1) table contains entries pointing to second-level (L2) tables or directly mapping large sections (1 MB) and supersections (16 MB). This flexibility allows efficient handling of both large contiguous regions and fine-grained mappings.

Modern 64-bit processors use three, four, or five levels to cover their much larger virtual address spaces, though embedded applications rarely require the full addressing capability. AArch64 with a 4 KB granule walks four levels to reach a 48-bit virtual address, and each table occupies one page holding 512 sixty-four-bit descriptors. Larger granules trade table depth for page size: a 64 KB granule reaches the same 48-bit space in three levels, because each table then holds 8,192 descriptors.

Depth is a direct cost. A four-level walk that misses in every cache costs four dependent memory reads before the original access can even begin, which is why processors cache intermediate descriptors in dedicated page-walk caches and why embedded designers favor large mappings for regions that never change.

Page Table Entries

Each page table entry contains more than just the physical page number. Additional fields control access permissions, caching behavior, and other attributes:

• Valid bit: Indicates whether the mapping exists. Accessing an invalid entry triggers a page fault exception.
• Permission bits: Control read, write, and execute access. Separate bits may govern user-mode and kernel-mode permissions.
• Cache attributes: Specify how the processor should cache memory accesses to this page. Options typically include cacheable, write-through, write-back, and non-cacheable.
• Access flags: Record whether the page has been accessed or modified, supporting operating system memory management decisions.
• Domain or ASID: Associate the mapping with a specific address space or security domain, enabling efficient context switching.

Translation Example

Consider translating virtual address 0x00401234 in a system with 4 KB pages and two-level page tables. The address breaks down as follows:

• Virtual address: 0x00401234
• L1 index (upper 12 bits of VPN): 0x004
• L2 index (lower 8 bits of VPN): 0x01
• Page offset: 0x234

The MMU uses the L1 index to access entry 0x004 in the L1 page table, obtaining a pointer to an L2 page table. It then uses the L2 index to access entry 0x01 in that L2 table, retrieving the physical page number. If the physical page number is 0x80010, the resulting physical address is 0x80010234.

This translation occurs in hardware for every memory access, making efficiency critical. The TLB, discussed later, caches recent translations to avoid repeated page table walks.

Two-Stage Translation for Virtualization

Embedded systems that consolidate several workloads on one system-on-chip, such as an automotive domain controller running a Linux infotainment stack alongside a safety-certified RTOS, need translation that a guest operating system cannot subvert. Architectures with hardware virtualization support solve this with two stages of translation chained together.

In stage 1 the guest operating system translates a virtual address to an intermediate physical address using page tables it controls. In stage 2 the hypervisor translates that intermediate physical address to a real physical address using a second set of tables the guest cannot modify. A guest can therefore map anything it likes within the memory the hypervisor granted it, and nothing outside. Arm names the two levels stage 1 and stage 2 and adds a virtual machine identifier (VMID) that tags TLB entries per guest, alongside the ASID that tags them per process. The RISC-V hypervisor extension follows the same two-stage pattern, naming its second stage G-stage translation.

The cost is walk depth. A stage-1 walk that misses in the TLB must itself be translated by stage 2 at every level, so a four-level stage-1 walk nested inside a four-level stage-2 walk can require on the order of twenty memory accesses in the worst case. Hypervisors on real-time platforms mitigate this by pinning guest memory, using large stage-2 block mappings, and avoiding stage-2 faults during critical execution.

Access Permission Levels

Page table entries specify what types of access are permitted for each memory page. Common permission combinations include:

• No access: Any access attempt triggers a fault. Used for unmapped regions and guard pages.
• Read-only: Read access permitted; write attempts fault. Protects code and constant data.
• Read-write: Both read and write access permitted. Used for data regions.
• Execute: Instruction fetch permitted. Combined with read-only for code sections.
• No-execute: Instruction fetch prohibited even if readable. Prevents code execution from data regions, mitigating certain security attacks.

These permissions often apply differently based on processor privilege level. Kernel-mode code might have full access to a page that user-mode code can only read, or cannot access at all.

Privilege Levels and Domains

Processors define privilege levels that govern access capabilities. Arm processors distinguish between user mode and various privileged modes. The MMU can enforce different permissions based on the current privilege level, allowing the kernel to access all memory while restricting user processes.

Some architectures provide memory domains that group mappings with common access characteristics. In the Armv7-A short-descriptor format, a four-bit domain field in each first-level descriptor, whether that descriptor maps a 1 MB section or points to a second-level table, assigns the mapping to one of 16 domains. The domain access control register (DACR) then holds a two-bit field per domain, so writing one register can revoke or restore access to an entire memory region without touching a single page table entry. Armv8-A drops domains in favor of a more flexible permission and attribute model, and the Armv7-A long-descriptor (LPAE) format drops them as well.

Security extensions add a layer of protection that page tables cannot override. Arm TrustZone partitions the system into secure and non-secure worlds, and the hardware refuses non-secure accesses to secure memory regardless of what the non-secure page tables say. The two worlds keep separate translation regimes, so a non-secure operating system cannot even construct a mapping that reaches secure memory.

Fault Handling

When a memory access violates configured permissions, the MMU generates a fault exception. The processor saves its current state and transfers control to the operating system's fault handler, which must determine the cause and take appropriate action.

Common fault responses include:

• Terminate the offending process: For protection violations that indicate bugs or malicious behavior.
• Demand paging: Valid accesses to not-yet-loaded pages trigger loading from storage.
• Copy-on-write: Write faults to shared pages trigger page copying for process isolation.
• Stack growth: Accesses near stack boundaries may trigger stack expansion.

In embedded systems, fault handling is often simpler than in general-purpose operating systems. Demand paging is uncommon due to the absence of disk storage, and faults typically indicate software errors requiring logging and possibly a system reset.

Fault reporting hardware makes diagnosis practical. Arm cores latch the faulting address in a fault address register and a coded reason, such as translation fault, permission fault, or external abort, in a fault status register. RISC-V places the faulting address in the supervisor trap value register and distinguishes instruction, load, and store page faults by trap cause. Recording the faulting address, the fault cause, and the return address in the handler turns an otherwise opaque reset into a traceable defect.

System MMUs and Device Isolation

A core MMU protects memory only from the core. A DMA-capable peripheral issues its own bus transactions, and a misprogrammed descriptor list or a compromised firmware image on a smart peripheral can write anywhere in physical memory. System MMUs, generically called input/output memory management units (IOMMUs), close this gap by translating and checking the addresses that devices emit.

An IOMMU gives each device, or each stream of traffic from a device, its own translation tables. The device is programmed with addresses that are meaningless outside its assigned mapping, so a runaway transfer faults instead of corrupting the kernel. Arm specifies this function as the System MMU (SMMU), which supports the same descriptor formats and two-stage translation as the core MMU; RISC-V standardizes an equivalent IOMMU specification. In practice the same hardware also simplifies drivers, because a scatter-gather list of physically fragmented pages can be presented to the device as one contiguous address range.

The trade-offs mirror those of the core MMU. Device translations are cached in the IOMMU, so a stream with poor locality can stall on table walks, and invalidation after remapping must be synchronized with in-flight transfers. Cost-sensitive microcontrollers usually omit the IOMMU entirely and rely on simpler bus-level filters that restrict each master to a fixed address window.

Memory Protection Units

Some embedded processors include Memory Protection Units (MPUs) rather than full MMUs. An MPU provides access control without address translation, protecting memory regions through a simpler mechanism that requires less hardware and software complexity.

MPUs define a limited number of protection regions, commonly 8 or 16, with configurable base addresses, sizes, permissions, and memory attributes. The region descriptors live in processor registers rather than in memory, so there are no page tables to walk and no TLB to miss: every access is checked against the region set in a fixed number of cycles. That determinism is the MPU's main appeal.

The region model constrains software in ways page tables do not. In the Armv7-M MPU each region must be a power-of-two size, at least 32 bytes, and aligned to its own size, which forces linker scripts to pad and align every protected object. The Armv8-M MPU relaxes this to base and limit addresses with 32-byte granularity, removing most of the alignment pain. Either way, the region count is small, so a context switch reprograms the region registers to describe the incoming task's stack and data rather than swapping an address space.

Many Arm Cortex-M and Cortex-R processors include MPUs, and safety-certified kernels use them to isolate tasks and catch stack overflows at the hardware level. What an MPU cannot do is give two tasks the same virtual addresses, relocate code after link time, or over-commit memory. When those capabilities matter, only a full MMU will serve.

Cache Architecture Overview

Caches store recently accessed memory contents close to the processor for fast retrieval. Level 1 (L1) caches provide the fastest access, typically split into separate instruction and data caches. Level 2 (L2) and sometimes Level 3 (L3) caches offer larger capacity at slightly higher latency. Caches operate on cache lines, typically 32 to 64 bytes, loading and storing memory in these fixed-size units.

Cache behavior depends on memory type attributes specified in page table entries. Cacheable memory can be stored in caches, improving performance for frequently accessed data. Non-cacheable memory bypasses caches entirely, ensuring every access reaches main memory. Write-through caches immediately write modified data to memory, while write-back caches defer writes until cache lines are evicted.

Virtual vs. Physical Caching

Caches can index and tag using virtual addresses (VIVT), physical addresses (PIPT), or hybrid schemes (VIPT). Each approach presents different trade-offs:

• Virtually indexed, virtually tagged (VIVT): Fast lookup without waiting for address translation, but the cache must be flushed on context switch to avoid aliasing problems. Rarely used in modern designs.
• Physically indexed, physically tagged (PIPT): No aliasing problems, as physical addresses are unique. However, lookup must wait for MMU translation, adding latency. Common in L2 and L3 caches.
• Virtually indexed, physically tagged (VIPT): Enables parallel cache lookup and address translation when index bits come entirely from the page offset. Combines fast lookup with reliable operation. Common in modern L1 caches.

Understanding the cache architecture is essential for embedded systems developers, as it affects both performance optimization and correctness when dealing with DMA and multiprocessor coherency.

DMA and Cache Coherency

Direct Memory Access (DMA) controllers transfer data between peripherals and memory without processor involvement. Since DMA operates on physical addresses and bypasses processor caches, coherency problems arise when cached and DMA-accessible memory regions overlap.

When setting up DMA transfers, software must ensure coherency through one of several approaches:

• Cache maintenance operations: Before DMA reads memory that might be cached, software must clean (write back) affected cache lines. Before the processor reads DMA-written memory, software must invalidate affected cache lines. This approach works but adds overhead and complexity.
• Non-cacheable buffers: Allocating DMA buffers in non-cacheable memory regions eliminates coherency concerns. Page table attributes mark these regions as non-cacheable. The performance impact depends on access patterns.
• Hardware coherency: Some systems include hardware that maintains coherency between caches and DMA. Coherent interconnects snoop cache contents during DMA transfers, eliminating software cache maintenance. This approach simplifies software but requires appropriate hardware support.

Embedded systems designers must carefully choose coherency strategies based on hardware capabilities, performance requirements, and software complexity trade-offs.

Multiprocessor Coherency

Systems with multiple processor cores face additional coherency challenges. When cores have private caches, modifications by one core must become visible to others accessing the same memory locations. Cache coherency protocols ensure consistent memory views across cores.

Common coherency protocols include:

• MESI protocol: Cache lines exist in Modified, Exclusive, Shared, or Invalid states. State transitions occur based on local and remote accesses, maintaining coherency through snooping or directory-based mechanisms.
• MOESI protocol: Adds an Owned state, allowing one cache to supply data to others without writing back to memory first. Reduces memory bandwidth requirements.

The MMU works with coherency hardware to ensure correct operation. Page table attributes may need to specify shareability, indicating whether a page might be accessed by multiple cores and thus requires coherency protocol participation.

Software memory ordering requirements become complex in multiprocessor systems. Memory barriers ensure operations complete in expected order, and proper synchronization primitives prevent race conditions. Understanding the memory model of the target architecture is essential for correct multiprocessor software.

TLB Organization

TLBs cache page table entries, storing the virtual-to-physical mapping along with permission and attribute information. When the processor needs to translate a virtual address, it first checks the TLB. A TLB hit provides the physical address immediately, while a TLB miss requires a page table walk.

TLB organization varies by processor architecture:

• Unified vs. split: Some processors use separate instruction and data TLBs (like split L1 caches), while others use a unified TLB. Split TLBs can serve simultaneous instruction and data accesses but require more hardware.
• Fully associative vs. set-associative: Fully associative TLBs can store any translation in any entry, maximizing hit rates but requiring parallel comparison of all entries. Set-associative designs reduce comparison hardware at some cost in hit rate.
• Multiple levels: Like data caches, TLBs may have multiple levels. A small, fast L1 TLB handles most translations, with a larger L2 TLB catching misses.

TLB sizes are typically small compared to data caches, ranging from tens to hundreds of entries. The high associativity and large page sizes make this sufficient for most workloads.

TLB Miss Handling

When a TLB miss occurs, the system must walk the page tables to find the required translation. This process can be handled in hardware or software:

• Hardware page table walks: The MMU itself traverses page tables and loads the TLB entry. This approach is faster and transparent to software but requires page tables in a hardware-defined format. Most modern processors use hardware walks.
• Software TLB miss handling: A TLB miss generates an exception, and software loads the appropriate entry. This provides flexibility in page table format but adds overhead and latency. Classic MIPS processors used software-managed TLBs.

TLB miss latency significantly impacts performance when miss rates are high. Page table organization affects walk time, as does placement of page tables in cacheable memory. Prefetching and other techniques can hide some TLB miss latency in pipelined processors.

TLB Management

Operating systems must manage TLB contents as address mappings change. Key operations include:

• TLB invalidation: When page table entries change, corresponding TLB entries must be invalidated to prevent use of stale translations. Architectures provide instructions to invalidate specific entries or the entire TLB.
• Context switching: When switching between processes with different address spaces, the OS must handle TLB entries from the old process. Options include flushing the entire TLB (simple but hurts performance) or using address space identifiers.
• Address Space Identifiers (ASID): Many processors tag TLB entries with ASIDs identifying the address space. Entries from different address spaces can coexist in the TLB, with only entries matching the current ASID considered for hits. This dramatically improves context switch performance.

Embedded systems typically have simpler TLB management requirements than general-purpose operating systems. With fewer processes and less frequent context switches, aggressive TLB flushing may be acceptable. However, understanding TLB behavior remains important for performance-critical applications.

TLB Performance Optimization

Several techniques improve TLB performance in embedded systems:

• Large pages: Using larger page sizes (64 KB, 1 MB, or larger) reduces TLB pressure by covering more memory with fewer entries. This works well for large code or data regions but may waste memory for smaller allocations.
• TLB locking: Some processors allow locking critical translations in the TLB, preventing eviction. This guarantees fast access to important memory regions but reduces effective TLB size for other translations.
• Memory layout optimization: Arranging code and data to maximize TLB reuse improves hit rates. Keeping hot code paths within a few pages and organizing data structures for spatial locality reduces TLB misses.
• Superpages: Some systems promote a run of adjacent small pages into a single larger mapping when the allocation is contiguous and uniformly attributed. The optimization is transparent to applications but requires operating system support and the ability to demote the mapping again when permissions diverge.

Architectures also provide hints that let hardware fold several entries into one without changing the page size. An AArch64 descriptor carries a contiguous bit marking it as one of an aligned run of identical mappings, which permits the TLB to hold a single entry for the whole run, and the RISC-V Svnapot extension serves the same purpose. These mechanisms deliver much of the benefit of large pages while keeping the fine-grained page tables that memory allocators prefer.

Measurement should drive the choice. Most application-class cores expose performance counters for instruction and data TLB misses and for page-walk cycles. Profiling those counters under a representative workload shows whether translation is a real bottleneck before any effort goes into restructuring the memory map.

MMU Initialization

MMU initialization typically occurs during system boot and follows a specific sequence:

1. Create initial page tables: Before enabling the MMU, software must create page tables mapping at least the code and data required for continued operation. These tables must reside in physical memory accessible without translation.
2. Configure MMU registers: Set up translation table base registers pointing to page tables, configure domain access controls, and establish default memory attributes.
3. Enable the MMU: Setting the enable bit in the system control register activates address translation. Code immediately following this instruction executes with virtual addressing.

A critical consideration is ensuring the code enabling the MMU is identity-mapped, meaning virtual and physical addresses match. Otherwise, the instruction fetch following MMU enable would fail as the program counter still contains a physical address.

After initial enablement, the operating system typically builds more complete page tables and switches to them, establishing the full virtual memory configuration.

Page Table Management

Operating systems maintain page tables throughout execution, modifying them as processes are created, memory is allocated, and address space configurations change. Key operations include:

• Creating address spaces: New processes require new page tables. The operating system allocates page table memory and initializes entries for kernel mappings (often shared across all processes) and initial user mappings.
• Memory allocation: When allocating virtual memory, the OS finds free virtual address ranges and creates page table entries mapping them to physical pages. Entries include appropriate permissions and attributes.
• Permission changes: Memory protection modifications require updating page table entry permission bits and invalidating affected TLB entries to ensure the new permissions take effect.
• Unmapping: Releasing memory involves clearing page table entries and potentially freeing page table memory when entire tables become empty.

Page table operations must be performed carefully to maintain system stability. Races between table modifications and ongoing memory accesses can cause subtle bugs. Proper synchronization and TLB maintenance prevent such issues.

Context Switching

When the operating system switches between processes, it must also switch address space configurations. The context switch procedure includes:

• Save processor context: Register contents, including the ASID if used, are saved to the outgoing process's context structure.
• Switch page tables: The translation table base register is updated to point to the incoming process's page tables.
• Update ASID: If using ASIDs, the current ASID register is updated to match the incoming process.
• TLB maintenance: Without ASIDs, the TLB must be flushed. With ASIDs, this step can be skipped unless the ASID has been reused.
• Restore processor context: Register contents are restored from the incoming process's context structure.

Minimizing context switch overhead is important for system responsiveness. ASID usage dramatically reduces overhead by eliminating TLB flushes. Sharing kernel page tables across processes also helps, as kernel mappings remain valid after switching.

Real-Time Considerations

MMU operation introduces timing variability that challenges real-time requirements. TLB misses, page table walks, and fault handling all add unpredictable latency to memory accesses. Embedded real-time systems address these challenges through several approaches:

• TLB locking: Locking translations for time-critical code and data eliminates TLB miss latency for these accesses.
• Static memory allocation: Avoiding runtime memory allocation eliminates page faults during critical sections.
• Minimal page table depth: Using large pages and section mappings reduces page table walk time.
• Cache locking: Combined with TLB locking, cache locking provides fully deterministic memory access timing.
• Worst-case analysis: Real-time analysis must account for worst-case TLB and cache behavior, not just the average case.

Some safety-critical systems disable the MMU entirely to achieve maximum timing determinism, accepting the loss of memory protection. Others use MPUs instead, gaining protection without the timing variability of virtual memory. A third approach keeps the MMU but constrains it: build every mapping at initialization, never modify a descriptor after startup, and use block or section mappings large enough that the working set of translations fits in the TLB. Translation then becomes a fixed cost that worst-case execution time analysis can bound.

Certification adds its own pressure. Standards for airborne and automotive software expect evidence that partitions cannot interfere with one another, and MMU or MPU enforcement is the usual argument. The evidence must cover the configuration code as well, since a page table built incorrectly is indistinguishable from no protection at all.

Arm MMU

Arm processors are ubiquitous in embedded systems, and their MMU implementations have evolved across architecture versions:

• Armv7-A: Features two-level page tables with 4 KB (small page), 64 KB (large page), 1 MB (section), and 16 MB (supersection) mappings. Supports 16 memory domains. ASID support with 8-bit identifiers enables efficient context switching. The system control coprocessor (CP15) manages MMU configuration. The Large Physical Address Extension (LPAE) adds an optional three-level format for physical addresses beyond 32 bits.
• Armv8-A: Introduces 64-bit addressing with up to four-level page tables for a 48-bit virtual address. Supports 4 KB, 16 KB, and 64 KB translation granules. Replaces domains with a more flexible permission and memory-attribute model, in which each descriptor selects one of eight attribute encodings held in the MAIR register. Separate TTBR0_EL1 and TTBR1_EL1 registers translate the low and high halves of the address space, so kernel and user mappings need not share a table. Two stages of translation support virtualization. ASIDs may be 8 or 16 bits wide, an implementation choice reported and selected through the translation control register.

Arm implementations may optionally manage the access flag and dirty state in hardware, setting those bits in the descriptor when a page is first read or first written rather than trapping to software. The feature simplifies operating system page reclamation, but the resulting descriptor writes are extra memory traffic at unpredictable moments, which is a consideration for hard real-time workloads. Where the feature is absent or disabled, the first access to a page with the flag clear raises a fault and software updates the descriptor.

RISC-V MMU

RISC-V, increasingly popular in embedded applications, defines several virtual memory modes selected through the SATP register:

• Sv32: 32-bit virtual addresses with two-level page tables and 4 KB pages, mapping to 34-bit physical addresses. Suitable for embedded systems with moderate memory requirements.
• Sv39, Sv48, and Sv57: 39-bit, 48-bit, and 57-bit virtual addresses for larger address spaces, using three, four, and five page table levels respectively.

RISC-V uses the SATP (Supervisor Address Translation and Protection) register to control virtual memory, specifying the translation mode, the physical page number of the root page table, and the active ASID. Setting the mode field to Bare disables translation entirely, which is how a machine-mode boot loader runs before page tables exist. Because the architecture does not require hardware to snoop page table writes, software must execute an SFENCE.VMA instruction after modifying tables so the implementation discards stale cached translations; the instruction can be narrowed to a single address, a single ASID, or both.

Two related mechanisms round out the RISC-V memory model. Physical Memory Protection (PMP) is a machine-mode facility that restricts what supervisor and user code may reach in physical memory, serving the role an MPU plays elsewhere and remaining useful on cores that have no MMU at all. The optional Svnapot extension lets a run of naturally aligned, power-of-two page table entries advertise itself as one larger mapping, so a single TLB entry can cover 64 KB instead of sixteen separate 4 KB entries. The RISC-V hypervisor extension adds the second translation stage described earlier.

PowerPC and Other Architectures

Other processor architectures appear in specialized embedded applications:

• PowerPC: Used in automotive, aerospace, and networking applications. Classic PowerPC implementations feature hash-based page tables and segment registers providing additional address space control. Book E variants common in embedded systems use software-managed TLBs with more conventional page tables.
• MIPS: Historically significant in embedded systems, featuring software-managed TLBs that provide flexibility but require careful software design. Later MIPS variants added hardware page table walkers.

Understanding the specific MMU features of the target architecture is essential for effective system design. Architectural reference manuals provide detailed specifications, while vendor-provided examples demonstrate practical implementation.

RTOS Virtual Memory Support

Real-time operating systems increasingly support MMU-based memory protection. Examples include:

• FreeRTOS with MPU support: The FreeRTOS-MPU ports run tasks unprivileged and confine each one to the MPU regions it declares at creation, on Armv7-M and Armv8-M Cortex-M devices. FreeRTOS does not implement virtual memory, so protection here is region-based rather than page-based; workloads that need separate address spaces require a different kernel.
• Zephyr: Supports both MPU and MMU configurations, providing memory protection suitable for various embedded processors. User-mode support enables running untrusted code with restricted permissions.
• QNX: A microkernel RTOS with full virtual memory support, widely used in automotive and medical applications where memory protection is essential.
• VxWorks: Provides optional MMU support with real-time performance, supporting both flat and virtual memory models.

RTOS implementations typically offer simplified virtual memory models compared to general-purpose operating systems. Static allocation and fixed mappings are common, avoiding the complexity and timing variability of demand paging.

Linux Virtual Memory

Embedded Linux provides full virtual memory capabilities, making it suitable for complex applications where sophisticated memory management justifies the overhead:

• Process isolation: Each process has a private virtual address space, with the kernel enforcing protection between processes and from user space to kernel space.
• Demand paging: Memory is allocated and mapped only when accessed, supporting systems where virtual memory exceeds physical memory.
• Memory-mapped files: Files can be mapped into process address spaces, providing convenient and efficient file access.
• Shared memory: Multiple processes can share memory regions for efficient inter-process communication.

For real-time embedded applications, Linux's PREEMPT_RT patches and careful system configuration can provide reasonable latency bounds, though not as deterministic as specialized RTOSs. Understanding virtual memory behavior helps optimize real-time Linux systems.

Bare-Metal MMU Programming

Some embedded applications program the MMU directly without operating system abstraction. This approach provides maximum control and minimal overhead but requires careful implementation:

• Page table construction: The application builds page tables at boot time, typically with static mappings determined at compile time or from configuration data.
• Protection configuration: Memory regions are configured with appropriate permissions to protect critical code and data from corruption.
• Cache management: The application explicitly manages cache and TLB operations when memory mappings or attributes change.

Vendor-provided startup code and examples often include MMU configuration for their evaluation boards. These serve as starting points for custom implementations.

Common Issues

Several categories of problems commonly arise with MMU usage:

• Page faults: Unexpected faults indicate missing mappings, incorrect permissions, or software bugs accessing invalid addresses. Fault handler logging of the faulting address and access type helps diagnosis.
• Cache coherency failures: Symptoms include corrupted data, DMA failures, and multiprocessor synchronization issues. These often manifest intermittently, making diagnosis difficult.
• TLB inconsistency: Failure to invalidate TLB entries after page table modifications causes unpredictable behavior, as stale translations may or may not be used depending on TLB contents.
• Permission errors: Code that works with the MMU disabled may fail when protection is enabled, revealing bugs that previously caused silent corruption.

Debugging Tools and Techniques

Several approaches assist in debugging MMU issues:

• JTAG debuggers: Hardware debuggers can display TLB contents, page table entries, and MMU register values. They can also catch fault exceptions for detailed analysis.
• Exception handlers: Well-instrumented exception handlers log essential information including fault address, access type, processor state, and call stack for post-mortem analysis.
• Systematic testing: Testing with the MMU disabled can isolate whether issues stem from MMU configuration or other causes. Incremental enablement of MMU features helps identify which aspect causes problems.
• Memory mapping visualization: Tools that dump and display page table contents help verify correct configuration. Some debuggers provide graphical views of address space mappings.

Best Practices

Following established practices reduces MMU-related problems:

• Start simple: Begin with identity mappings and minimal protection, adding complexity incrementally.
• Use proven code: Leverage vendor-provided or well-tested MMU initialization code rather than writing from scratch.
• Document mappings: Maintain clear documentation of the intended memory map and protection scheme.
• Consistent cache management: Establish and follow consistent rules for cache maintenance, particularly around DMA operations.
• Test thoroughly: Include MMU-specific tests in validation suites, including fault injection and boundary conditions.