Documentation/arch/xtensa/mmu.rst
Source file repositories/reference/linux-study-clean/Documentation/arch/xtensa/mmu.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/arch/xtensa/mmu.rst- Extension
.rst- Size
- 8826 bytes
- Lines
- 199
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: documentation
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
=============================
MMUv3 initialization sequence
=============================
The code in the initialize_mmu macro sets up MMUv3 memory mapping
identically to MMUv2 fixed memory mapping. Depending on
CONFIG_INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX symbol this code is
located in addresses it was linked for (symbol undefined), or not
(symbol defined), so it needs to be position-independent.
The code has the following assumptions:
- This code fragment is run only on an MMU v3.
- TLBs are in their reset state.
- ITLBCFG and DTLBCFG are zero (reset state).
- RASID is 0x04030201 (reset state).
- PS.RING is zero (reset state).
- LITBASE is zero (reset state, PC-relative literals); required to be PIC.
TLB setup proceeds along the following steps.
Legend:
- VA = virtual address (two upper nibbles of it);
- PA = physical address (two upper nibbles of it);
- pc = physical range that contains this code;
After step 2, we jump to virtual address in the range 0x40000000..0x5fffffff
or 0x00000000..0x1fffffff, depending on whether the kernel was loaded below
0x40000000 or above. That address corresponds to next instruction to execute
in this code. After step 4, we jump to intended (linked) address of this code.
The scheme below assumes that the kernel is loaded below 0x40000000.
====== ===== ===== ===== ===== ====== ===== =====
- Step0 Step1 Step2 Step3 Step4 Step5
VA PA PA PA PA VA PA PA
====== ===== ===== ===== ===== ====== ===== =====
E0..FF -> E0 -> E0 -> E0 F0..FF -> F0 -> F0
C0..DF -> C0 -> C0 -> C0 E0..EF -> F0 -> F0
A0..BF -> A0 -> A0 -> A0 D8..DF -> 00 -> 00
80..9F -> 80 -> 80 -> 80 D0..D7 -> 00 -> 00
60..7F -> 60 -> 60 -> 60
40..5F -> 40 -> pc -> pc 40..5F -> pc
20..3F -> 20 -> 20 -> 20
00..1F -> 00 -> 00 -> 00
====== ===== ===== ===== ===== ====== ===== =====
The default location of IO peripherals is above 0xf0000000. This may be changed
using a "ranges" property in a device tree simple-bus node. See the Devicetree
Specification, section 4.5 for details on the syntax and semantics of
simple-bus nodes. The following limitations apply:
1. Only top level simple-bus nodes are considered
2. Only one (first) simple-bus node is considered
3. Empty "ranges" properties are not supported
4. Only the first triplet in the "ranges" property is considered
5. The parent-bus-address value is rounded down to the nearest 256MB boundary
6. The IO area covers the entire 256MB segment of parent-bus-address; the
"ranges" triplet length field is ignored
MMUv3 address space layouts.
============================
Annotation
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.