This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

ARM DS-5 with imx28 EVK gator driver module load failed

Note: This was originally posted on 15th May 2012 at http://forums.arm.com

Hello all,

We are currently evaluating the ARM DS-5 tool for  performance analysis requirements for our application/driver software.
Our target system is a freescale imx28 Evaluation board.

We have installed the trial version of the DS-5 tool and downloaded & build the gator driver module and the gator daemon.
When we try and load the gator driver module in our target board, we are facing this following issue.

root@freescale /lib/modules/2.6.35.3-571-gcca29a0/kernel/drivers$ insmod gator.ko
gator: disagrees about version of symbol module_layout
insmod: can't insert 'gator.ko': invalid module format


We have cross-checked that the driver module is build against the kernel version that we are running in the target board which the 2.6.35 Linux kernel.

Also, we are able to connect to the target board using the 'Remote systems explorer' view of the DS-5 tool and able to see the remote file system.
But since the gator driver module and the daemon is needed for profiling the applications, we couldn't proceed further.

Any help would be highly appreciated.
  • Note: This was originally posted on 16th May 2012 at http://forums.arm.com


    We have cross-checked that the driver module is build against the kernel version that we are running in the target board which the 2.6.35 Linux kernel.


    Nonetheless, I think it's most likely that there is some target-build mismatch either of the kernel or the gator.ko.

    Try comparing the output of 'uname -r' on the target to the contents of include/config/kernel.release in the sources.

    Try comparing the length and md5sum of gator.ko on the target and the one you built.
  • Note: This was originally posted on 30th June 2012 at http://forums.arm.com

    To add to scott's message, it is not sufficient simply to build a module against a kernel of the same version. The only guarantee is to build the module against the exact kernel running.