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. <kernelnewbies@xxxxxxxxxxx> wrote: > On Fri, Jun 10, 2011 at 07:30:46AM +0800, Gavin Guo wrote: >> > 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. > >> 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 _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
