Viewing page tables and some other questions regarding the MMU

Leo Barnes barnes.leo at
Tue Mar 30 09:56:55 EDT 2010


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,

More information about the linux-arm mailing list