Calling function from address

Peter Teoh htmldeveloper at gmail.com
Sat Jun 11 03:45:40 EDT 2011


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 at mail.i88.de> 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



More information about the Kernelnewbies mailing list