ARMv8 Translation Fault Level 0 During TTBR0_EL1 Switch from Identity Mapping to User Process
The core issue revolves around a translation fault level 0 occurring after switching the TTBR0_EL1 register from an identity mapping to a user process mapping in an ARMv8-based system, specifically on a Raspberry Pi 4B (BCM2711). The fault manifests when attempting to access memory after the switch, even though the MMU setup appears correct. The fault is triggered during the transition from EL1 to EL0, and the memory addresses mapped for the user process become inaccessible. This issue is particularly perplexing because the identity mapping works correctly before the switch, suggesting that the MMU configuration is valid. However, after the switch, the new mapping fails, leading to a translation fault.
The fault is accompanied by specific ESR_EL1 and PAR_EL1 register values, which indicate a translation fault at level 0. The fault occurs even when using JTAG and GDB to inspect the memory, suggesting that the issue is not related to software execution but rather to the hardware translation process. The user has attempted to invalidate the TLB using a sequence of dsb, isb, and tlbi instructions, but the fault persists. This suggests that the issue may lie in the configuration of the translation tables, the TCR_EL1 register, or the MAIR_EL1 register.
Misconfigured TCR_EL1, MAIR_EL1, and Translation Table Descriptors
The root cause of the translation fault can be traced to several potential misconfigurations in the ARMv8 memory management unit (MMU) setup. These include incorrect settings in the TCR_EL1 (Translation Control Register), MAIR_EL1 (Memory Attribute Indirection Register), and the translation table descriptors themselves.
TCR_EL1 Misconfiguration
The TCR_EL1 register controls the translation regime, including the size of the address space, the granularity of the translation tables, and the shareability attributes. In this case, the user initially did not set the IRG (Inner Cacheability), ORG (Outer Cacheability), and SH (Shareability) fields in TCR_EL1. These fields are critical for ensuring that the translation tables are correctly cached and shared across multiple cores. When these fields are not set, the MMU may not be able to correctly interpret the translation tables, leading to translation faults.
MAIR_EL1 Misconfiguration
The MAIR_EL1 register defines the memory attributes for the translation tables. Each entry in MAIR_EL1 corresponds to a specific memory type (e.g., normal memory, device memory) and defines attributes such as cacheability and shareability. If the MAIR_EL1 register is not configured correctly, the MMU may not be able to correctly interpret the memory attributes specified in the translation table descriptors, leading to translation faults.
Translation Table Descriptor Misconfiguration
The translation table descriptors themselves may also be misconfigured. In this case, the user initially set bit #10 (0x400) in the table descriptors, which corresponds to the access flag. However, this bit is not required for table descriptors and may have caused the MMU to misinterpret the descriptors. Additionally, the shareability attributes in the descriptors were set to non-shareable, which may have contributed to the translation fault. The descriptors must be configured to match the memory attributes defined in MAIR_EL1 and the shareability attributes defined in TCR_EL1.
TLB Invalidation Sequence
The sequence used to invalidate the TLB may also be a contributing factor. The user used the following sequence:
dsb ish
isb sy
msr ttbr0_el1, x20
ic iallu
dsb sy
isb sy
tlbi vmalle1
dmb sy
isb sy
While this sequence is generally correct, the order and type of barriers used may need to be adjusted depending on the specific requirements of the system. For example, the dsb ish barrier may not be sufficient to ensure that all previous memory operations are complete before the TLB invalidation. Similarly, the ic iallu instruction, which invalidates all instruction caches, may not be necessary in this context.
Correcting TCR_EL1, MAIR_EL1, and Translation Table Descriptors for Stable Translation
To resolve the translation fault, the following steps should be taken to ensure that the TCR_EL1, MAIR_EL1, and translation table descriptors are correctly configured:
Step 1: Configure TCR_EL1
The TCR_EL1 register should be configured with the correct values for the IRG, ORG, and SH fields. For example:
- IRG: Inner Write-Back, Read-Allocate, Write-Allocate (W-B, R-A, W-A)
- ORG: Outer Write-Back, Read-Allocate, Write-Allocate (W-B, R-A, W-A)
- SH: Inner Shareable
This ensures that the translation tables are correctly cached and shared across multiple cores.
Step 2: Configure MAIR_EL1
The MAIR_EL1 register should be configured with the correct memory attributes. For example:
- MAIR_EL1 = 0xFF040000 (Normal memory, Inner Write-Back, Outer Write-Back, Read-Allocate, Write-Allocate)
This ensures that the MMU correctly interprets the memory attributes specified in the translation table descriptors.
Step 3: Correct Translation Table Descriptors
The translation table descriptors should be corrected to remove unnecessary flags and ensure that the shareability attributes match those defined in TCR_EL1. For example:
- Remove bit #10 (0x400) from the table descriptors.
- Set the shareability attributes to Inner Shareable.
Step 4: Adjust TLB Invalidation Sequence
The TLB invalidation sequence should be adjusted to ensure that all previous memory operations are complete before the TLB is invalidated. For example:
dsb sy
isb sy
msr ttbr0_el1, x20
dsb sy
isb sy
tlbi vmalle1
dsb sy
isb sy
This sequence ensures that all previous memory operations are complete before the TLB is invalidated and that the new translation table is used immediately after the invalidation.
Step 5: Verify Identity Mapping
Before switching to the user process mapping, verify that the identity mapping still works by creating a new copy of the identity mapping table and switching to it. This ensures that the MMU setup is correct and that the identity mapping is still valid.
Step 6: Test User Process Mapping
After verifying the identity mapping, create a new TTBR0 mapping for a single page in the VA range [0, 0x1000) and switch to it. Verify that the translation in this VA range works correctly. This ensures that the new mapping is correctly interpreted by the MMU.
Step 7: Debugging with QEMU
If possible, use QEMU to debug the issue. While QEMU does not provide full emulation for the Raspberry Pi 4B, it does support ARMv8 Virt and Raspberry Pi 3B emulation. This can be useful for isolating the issue and testing different configurations.
By following these steps, the translation fault should be resolved, and the system should be able to correctly switch from identity mapping to user process mapping without triggering a translation fault.
