Viewing page tables and some other questions regarding the MMU
Leo Barnes
barnes.leo at gmail.com
Tue Mar 30 09:56:55 EDT 2010
Hello!
I am trying to understand how the ARM MMU works and have a few
questions that I have so far not been able to find any good answers
for. My test rigs are a Nokia N810 (ARM1136) and a Nokia N900 (ARM
Cortex-A8). They are both running Maemo Linux, with my experimentation
software being loaded as kernel modules so that I can run in
privileged mode.
1. The first thing I would like to do is to view/modify the MMU
translation tables. I know that the physical addresses of the
translation tables can be retrieved from the control co-processor, but
how do I get access to the tables themselves? I hypothesize that in
order to view or modify the translation tables, the MMU has to be
disabled. After reading the ARM documentation, I tried first disabling
and then enabling the MMU by doing the following:
@Disable MMU
MRC p15, 0, r2, c1, c0, 0
BIC r2, r2, #0x1
MCR p15, 0, r2, c1, c0, 0
@Read Translation Table Base Register 0
MRC p15, 0, r1, c2, c0, 0
@Load first entry in TTBR0 into r3
LDR r3, [r1]
@Enable MMU again
MRC p15, 0, r2, c1, c0, 0
ORR r2, r2, #0x1
MCR p15, 0, r2, c1, c0, 0
This crashed the device immediately. Am I missing something
fundamental? The device crashed even when not doing a read from the
translation table. Must I invalidate the TLBs and d/i caches or
similar when re-enabling the MMU?
What I am really after is some way to copy the translation tables into
a region of memory that is accessible when the MMU is enabled again,
preferably without using any Linux functions since I want to
understand how the OS does it at the lowest level.
2. Does ARM Linux store the translation tables in the format described
in the ARM reference manuals? I saw some mention about Linux storing
the translation tables slightly differently than described in the
manuals, but the forum thread didnt really go into any details. Which
version of the translation tables are used? Pre v6 or v6?
3. I notice that there exists a function called ioremap_cached which
supposedly creates a second, cached, mapping to a physical address.
How does this work? From what I have read in the ARM manuals, it
seemed that having two maps to the same physical address with
different memory attributes was illegal, but this seems to be exactly
what ioremap_cached does.
Hope someone can help!
Best regards,
//Leo
More information about the linux-arm
mailing list