0

I am trying to write a android arm kernel module in which I need to use a virt_to_phys translation of a memory var allocated using _kmalloc. I do know that I can use the macro virt_to_physc to do this task. However, I dont have the specifically full kernel source, and beacuse virt_to_physc is a macro I can't get a function address reading kallsyms to use in my module , so I would like to find another way to do this task. I've been trying to do it using MMU (registers ATS1Cxx and PAR) to perform V=>P as Iam working in an ARMv7 proccessor but I couldnt make it work.

That's my test code...

int hello_init_module(void) {

    printk("Virtual MEM:0x%X \n", allocated_buf);
    //Trying to get the physc mem
    asm("\t mcr p15, 0, %[value], c7, c8, 2\n"
        "\t isb\n"
        \t mrc p15, 0, %[result], c7, c4, 0\n" : [result]"=r" (pa) : [value]"r" (allocated_buf));

    printk("Physical using MMU : %x\n", pa );

    //This show the right address, but I wanna do it without calling the macro.
    printk("Physical using virt_2_physc: 0x%X",virt_to_phys((int *) allocated_buf);)

}

What Iam actually doing is developing a module that is intended to work in two devices with the same 3.4.10 kernel but different memory arquitectures, I can make the module works as they have the same VER_MAGIC and functions crc, so the module load perfectly in both devices. The main problem is that because of diferences in their arquitecture, PAGE_OFFSET and PHYS_OFFSET actually change in both of them. So, I've wondering if there is a way to make the translation without define this values as constant in my module.That's what I tried using MMU to perform V=>P , but MMU hasnt worked in my case, it always returns 0x1F. According to cat /proc/cpuinfo . Iam working with a 

Processor   : ARMv7 Processor rev 0 (v7l)
processor   : 0
Features    : swp half thumb fastmult vfp edsp neon vfpv3 tls 
CPU implementer : 0x51
CPU architecture: 7

If it's not possible to do it using MMU as alternative way of using virt_to_phys. Does somebody know other way to do it?

David A
  • 763
  • 1
  • 9
  • 22
  • how about just repeating virt_to_phys realization ? http://lxr.free-electrons.com/source/arch/arm/include/asm/memory.h#L278 – Alex Hoppus Jul 21 '15 at 05:26
  • And what does it mean you have no full kernel sorce? Why? – Alex Hoppus Jul 21 '15 at 05:55
  • @Alex_Hoppus. I've thought in repeating the macro but in order to do it, I need to know PAGE_OFFSET and PHYS_OFFSET which actually I dont know as I dont have the kernel source, is there any other way to retrieve this values?. – David A Jul 21 '15 at 17:13
  • @Notlikethat: I mean that as virt_to_phys is a macro it's implicit in code so I can't get its symbol address because it's not in fact a function like printk for example. What I'm doing is trying to avoid implicit constant such as PAGE_OFFSET and PHYS_OFFSET (virt_to_physc) in my code in order to make it portable between my devices without recompiling it. I edited my question in order to make it clear, please would you mind to look at it again?. – David A Jul 21 '15 at 17:14
  • Ah, that does explain the situation better. Leaving aside the "how the hell are you building a kernel module without the necessary kernel source to compile it against" issue, since this clearly isn't some platform-specific thing, why do you need the physical address of the buffer? What will you do with it once you have it? – Notlikethat Jul 21 '15 at 19:00
  • 1
    possible duplicate of [Find the physical address of exception vector table from kernel module](http://stackoverflow.com/questions/19275718/find-the-physical-address-of-exception-vector-table-from-kernel-module); just use the assembler there `asm("\t mcr p15, 0, %0, c7, c8, 2\n\t isb\n\t mrc p15, 0, %0, c7, c4, 0\n" : "=r" (pa) : "r" (virt));` – artless noise Jul 21 '15 at 19:27
  • @ Notlikethat Thanks for your fast answer. 1-I built the kernel module using the source code of the device #1, the other(device #2) is the one which I dont have the source, but as I said before, as they are both in 3.4.10, the kernel magic match and it works perfectly in device#2 although the differences in memory arquitecture. why do you need the physical address of the buffer? What will you do with it once you have it? 3-I need to make a SCM call in order to exchange data with the secure world that's what I need the physc add. – David A Jul 21 '15 at 19:28
  • @artlessnoise I've already read that article before doing the question but the way propose there doesn't actually work for me. I need the phys add of the allocated buffer with kmalloc and I havent made it work using MMU. Please look at the code example that I wrote , it's almost the same but it always return 0x1F. – David A Jul 21 '15 at 19:31
  • 1
    If that doesn't work then your CPU doesn't support **PAR** and then my answer applies; so it is still a duplicate. Ie, you have to do a table walk. I have used the assembler (in the duplicate) on a Cortex-a5 in the kernel (super space) and it was fine and worked. – artless noise Jul 21 '15 at 19:33
  • @artlessnoise, I'm working according to cat /proc/cpuinfo in an ""ARMv7 Processor rev 0 (v7l) Features: swp half thumb fastmult vfp edsp neon vfpv3 tls"" . It's a Snapdragon S4 Plus actually. In case that it doesn't support PAR , what I'm looking for is other way to do it , if it is possible. Could you suggest me something please? – David A Jul 21 '15 at 19:42
  • 1
    Qualcomm does a custom implementation of the ARMv7; it is not the same HDL as a from ARM itself, so something like the **PAR** could be missing or altered. Also, you might be executing in some sort of security environment. You can get the MMU table base and parse/decode it; that is a table walk. That will work no matter what. There are also some TLB debug registers. TLB debug is highly CPU specific; a table walk is the most generic. Possibly there is some kernel function to do a table walk in some version of Linux somewhere. – artless noise Jul 22 '15 at 16:15

0 Answers0