http://infocenter.arm.com/help/topic/com.arm.doc.dui0056d/ch07s05s01.html

this provide the additional info that cache store virtual addresses,
and since different processes may have same virtual address, but
different physical address, u have to beware!

On Sat, Jun 11, 2011 at 2:45 PM, Peter Teoh [off-list ref] wrote:

For ARM, MMU info can be found here:

http://infocenter.arm.com/help/topic/com.arm.doc.ddi0333h/Babbhigi.html

That is the theory behind MMU in ARM....but if u want the high level API, look
?under the arch/arm/mm directory lots of examples there. ? Otherwise u
might try the following steps as proposed by "Marco Wang" - google for
it. ? To quote:

phys_to_virt() only works with directly mapped physical address. I
don't think using phys_to_virt() is the best idea, anyway. Usually you
do this in several steps in a device driver:

1. Call request_mem_region() to request virtual memory region;
2. Call ioremap() to map physical address to virtual address;
3. Read/write mapped virtual address by using iowriteXX() /
ioreadXX(), etc. Here XX can be 8, 16, or 32 for example, represents
bit width.
4. Call iounmap() and release_mem_region() to release memory mapping;

Thanks,
Marco Wang

On Fri, Jun 10, 2011 at 3:46 PM, Micha M. [off-list ref] wrote:

quoted

On Fri, Jun 10, 2011 at 07:30:46AM +0800, Gavin Guo wrote:

quoted

quoted

So maybe I have to explain some more. There is some code located in the
pysical address space and I need to call it from a kernel module. The
problem is, that the code must be run from that location it is stored (it
contains absolute jumps). So I'd like to be able to run that code in that
address space, or to "tell" the keeernel to ignore page faults/memory
protection on a certain address range, so that I can jump there run the
code and return to the caller (kernel module)

What is the architecture do you use? ex: x86, arm, mips,...

ARM.

quoted

I know in some platform like andes, it is possible to turn off the
virtual memory.
Then you can jump to the physical address. After doing what you want, turning on
virtual memory again. Finally, system return to the normal operation.
However, the
code is a little tricky. Before turning off the virtual memory, you
must lock the
code jumping to physical address in cache. Otherwise, behaviors, after
turning off
the cache, is unpredictable.

Gavin Guo

--
Regards,
Peter Teoh

-- 
Regards,
Peter Teoh