• State Accepted Answer
  • Locked Locked
  • Replies 5 replies
  • Subscribers 20 subscribers
  • Views 6562 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

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

Juno MMU setup

armdev

Hi,

I was trying to change my MMU setup from 39bit address space to 40bit address space in Juno.

Previously I was successfully able to map 39bit address space by setting T0SZ=25 and using L1 level page tables.

Now I am trying to enable MMU configuring L0 level page tables but as soon as I write TCR_EL2 and T0SZ=24 I am getting "Bus error on memory operation".

I faced this issue before when I was setting wrong T0SZ value but now I am setting T0SZ=24 which should be the value for 40bit virtual space.

Is it possible in Juno to have MMU with 40bit address space > 512GB ? I read another link (Re: Re: ARMv8 mmu problem)

but it is confusing if it is possible or not as ID_AA64MMFR0_EL1 register show Juno supports 40bit and memory map states upper 512GB reserved based on above link.

I would like to know how to identify then the value of T0SZ as apart from ID register and page table granularity it seems platform memory map has to be considered ?

Another issue is I am mapping my VA -> IPA -> PA all to 39bit address space and not sure if Linux has any restriction that PA/IPA needs to be wider than VA ?

Thanks.

Parents
  • 0 Arm Employee Badge in reply to armdev

    Hi,

    2) Set TCR_EL2 with value (0x80923518) where  T0SZ=24, IRGN0=01, ORGN0=01,SH0=11,TG0=4K granule and PS=40 bits. (I get "Bus error" at this stage)

    This is almost certainly caused by the MMU already being on at the point that you write to TCR_EL2, which in your case is resulting in a virtual address being translated to an invalid physical address because TTBR0_EL2 hasn't been set to the correct value yet. At the entry point to your program, please can you do this to ensure that the MMU is turned off:

    LDR X0, =0x30C50830

    MSR SCTLR_EL2, X0

    This will safely disable the MMU and caches at EL2 while reserving SCTLR_EL2's RES1 bits.

    Yes first entry for L0 table is = ((L1 page table address & 0xfffffffffffff000) | 0x3 ) similar for other block descriptors.

    This is not the correct way to generate a table descriptor. From the ARMv8-A Architecture Reference Manual (DDI 0487A.f) section D4.4.1, the table descriptor at 4KB granularity expects bits [47:m] to be bits [47:m] of the next-level table's physical address. Bits [63:48] of the table descriptor include RES0 bits, some ignored bits, and some table attribute bits such as NSTable, APTable, XNTable, and PXNTable. The code you are using to generate your table descriptor is setting all of these bits to 1, including the RES0 bits [51:48].


    Ash.

Reply
  • 0 Arm Employee Badge in reply to armdev

    Hi,

    2) Set TCR_EL2 with value (0x80923518) where  T0SZ=24, IRGN0=01, ORGN0=01,SH0=11,TG0=4K granule and PS=40 bits. (I get "Bus error" at this stage)

    This is almost certainly caused by the MMU already being on at the point that you write to TCR_EL2, which in your case is resulting in a virtual address being translated to an invalid physical address because TTBR0_EL2 hasn't been set to the correct value yet. At the entry point to your program, please can you do this to ensure that the MMU is turned off:

    LDR X0, =0x30C50830

    MSR SCTLR_EL2, X0

    This will safely disable the MMU and caches at EL2 while reserving SCTLR_EL2's RES1 bits.

    Yes first entry for L0 table is = ((L1 page table address & 0xfffffffffffff000) | 0x3 ) similar for other block descriptors.

    This is not the correct way to generate a table descriptor. From the ARMv8-A Architecture Reference Manual (DDI 0487A.f) section D4.4.1, the table descriptor at 4KB granularity expects bits [47:m] to be bits [47:m] of the next-level table's physical address. Bits [63:48] of the table descriptor include RES0 bits, some ignored bits, and some table attribute bits such as NSTable, APTable, XNTable, and PXNTable. The code you are using to generate your table descriptor is setting all of these bits to 1, including the RES0 bits [51:48].


    Ash.

Children