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.
Hi ARM experts,
I have a problem in using armv8 mmu in bare-metal system:
When using the 4KB translation granule, level 1 table which use D_Block convert VA to 1GB region PA.
In Armv8 ARM page D4-1744, table lookup starts at level 0.
Is the Level 0 table a essential step to map the PA?
May I bypass the level 0 table and do mmu conversion via level 1 translation table? In other words, directly fill the L1 table address in TTBR0 register.
Thanks!!
Hi Ash,
If the virtual address is smaller than 512G, are there any limitations for using level 0 table?
For example: the virtual address is 512G, the first 8M bytes space is "Normal Memory", and others are "Device", uses 4KB granularity table, i tried the MMU table like following:
1 The first entry (512G space) of level 0 translation table is a table entry, point to level 1 table, other entries of level 0 are valid;
2 The first entry (1G space) of level 1 table is a table entry, point to the level 2 table, other entries are all block entries with "Device" attribute;
3 The first 4 entries (2M * 4 space) of level 2 table is block entries with "Normal Memory" attribute while other entries are "Device" attribute.
I met system hang after enabling MMU if pushed the base address of level 0 table to TTBR0, while system work well if pushed the level 1 table base address. I am tracking now but did still not find the root cause till now.
Does any limitation exist? Thanks!
Hi,
If you've set TCR_EL1.T0SZ in such a way that your virtual address space is configured to be 512GB, then what you are describing is most likely the expected behaviour. As outlined in my earlier reply, doing this at 4KB granularity will cause translations to start at L1, in other words, the translation table pointed to by TTBR0_EL1 will be interpreted as an L1 table, rather than an L0 table. This means that the first entry in your L0 table is actually mapping only 1GB, not 512GB like you think it is, because the L0 table is being interpreted as an L1 table. If all other entries in the table are fault descriptors then you'll be getting a First Level Translation Fault.
We can confirm this by looking at the value of the ESR_EL1 register. Please can you single step the write to SCTLR_EL1 that is enabling the MMU, and then provide the value of ESR_EL1?
Ash.
Ash,
Thanks for your reply, it is very helpful!!
I think I misunderstood the processing of "walk" of translation tables before. I missed the T0SZ affection to translation table walk. As my understanding now, the number of T0SZ identifies the virtual address space, and the virtual address space also determines from which level the init lookup start. In case that T0SZ >= 25 (virtual address space <= 512G), like you said above, "doing this at 4KB granularity will cause translations to start at L1".
Correct
And to go even further, at 4KB granularity, setting T0SZ to be >= 34 (so that the virtual address space is <= 1 GB) will cause translations to start at L2, because a single L2 table at 4KB granularity maps 1GB (512 entries * 2MB per entry).
Got it, many thanks! Ash.