Please note: We are aware of an issue affecting replies on the Arm Community forums, which may not be loading as expected.

We apologize for any inconvenience and appreciate your patience while we investigate and work to resolve the issue.

Thank you for your understanding.

  • State Suggested Answer
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 348 subscribers
  • Views 4103 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Arm MMU configuration works on (qemu) raspberry(a53) but not on virt(armv7, a53) board

Former Member
Former Member

Now, I’m aware that this is a complex question and might not be resolved here. I am new to embedded/processor programming and I would like to know if there are any major differences between those two boards(cpu wise). I thought that since it is the same CPU (which I think has the same mmu, at least I couldn’t find any information about different versions), my code for the page table config would be universal.

A bit more context, both versions run on exactly the same code, and I am configuring one gigabyte as a section for the boot loaders (which is the current code, the one writing to the page tables) memory.

When I turn on the MMU(after writing the page table to memory and configuring tcr), the next read of the pc causes a “memory, not accessible” exception, but only on the virt board, on the raspi3b board it works just fine.

Best regards Niklas

Parents
  • 0 Arm Employee Badge in reply to Former Member

    Decoding the ESR value (https://developer.arm.com/documentation/ddi0601/2022-06/AArch64-Registers/ESR-EL1--Exception-Syndrome-Register--EL1-?lang=en#fieldset_0-24_0_12):

    EC = 0b100001 = Instruction Abort taken without a change in Exception level.
    IFSC = 0b000100 = Translation fault, level 0.
    EA = 0 = Not an external fault

    So it looks like the MMU table walk is failing early in the process.  Now this could be because you have a L0 table entry marked as "Fault", or because something about the table is invalid as these are also reported as L0 faults.

    It's a while since I had to write MMU set up code, but here is the list of things the Arm ARM lists as causing L0 translation faults:

    R_VZZSZ When one or more of the following apply, a level 0 Translation fault is generated on the relevant translation stage:
    • The IA does not map onto a TTBR_ELx address range.
    • If the IA maps onto the TTBR0_ELx address range and the IA contains any one bits above the configured IA
    size as determined by TCR_ELx.T0SZ.
    • If the IA maps onto the TTBR1_ELx address range and the IA contains any zero bits above the configured
    IA size as determined by TCR_ELx.T1SZ.
    • When a TLB miss occurs, the corresponding TCR_ELx.EPDn field prevents a translation table walk using
    TTBRn_ELx.
    • When FEAT_E0PD is implemented, the corresponding TCR_ELx.E0PDn field prevents unprivileged access
    to an address translated by TTBRn_ELx.
    • When FEAT_SVE is implemented, the corresponding TCR_ELx.NFDy field prevents non-faulting
    unprivileged accesses to an address translated by TTBRy_ELx.

Reply
  • 0 Arm Employee Badge in reply to Former Member

    Decoding the ESR value (https://developer.arm.com/documentation/ddi0601/2022-06/AArch64-Registers/ESR-EL1--Exception-Syndrome-Register--EL1-?lang=en#fieldset_0-24_0_12):

    EC = 0b100001 = Instruction Abort taken without a change in Exception level.
    IFSC = 0b000100 = Translation fault, level 0.
    EA = 0 = Not an external fault

    So it looks like the MMU table walk is failing early in the process.  Now this could be because you have a L0 table entry marked as "Fault", or because something about the table is invalid as these are also reported as L0 faults.

    It's a while since I had to write MMU set up code, but here is the list of things the Arm ARM lists as causing L0 translation faults:

    R_VZZSZ When one or more of the following apply, a level 0 Translation fault is generated on the relevant translation stage:
    • The IA does not map onto a TTBR_ELx address range.
    • If the IA maps onto the TTBR0_ELx address range and the IA contains any one bits above the configured IA
    size as determined by TCR_ELx.T0SZ.
    • If the IA maps onto the TTBR1_ELx address range and the IA contains any zero bits above the configured
    IA size as determined by TCR_ELx.T1SZ.
    • When a TLB miss occurs, the corresponding TCR_ELx.EPDn field prevents a translation table walk using
    TTBRn_ELx.
    • When FEAT_E0PD is implemented, the corresponding TCR_ELx.E0PDn field prevents unprivileged access
    to an address translated by TTBRn_ELx.
    • When FEAT_SVE is implemented, the corresponding TCR_ELx.NFDy field prevents non-faulting
    unprivileged accesses to an address translated by TTBRy_ELx.

Children
No data