• State Suggested Answer
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 351 subscribers
  • Views 3312 views
  • Users 0 members are here
Options
Related
How was your experience today?
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