How to integrate a Linux kernel module in LS2088ARDB?

[andreasr]

Hello,

I try to integrate a Linux kernel module in the LS2088ARDB using 'insmod', but I get the error message  

"disagrees about version of symbol module_layout. insmod: ERROR: could not insert module ...: Invalid module format"

The Linux kernel version used on the board is 4.1.35-rt41.

I obtained the exact version of the kernel sources (including patch rt41) and compiled my kernel module against them. 

I also used the config file from the LS2088ARDB (obtained from /proc/config.gz) to build the kernel.

Do I have to use another version of the kernel or am I missing something else?

Thank you!

[iuro]

Hi everyone!

I am trying to update with SDK v2.0-1703 because, I am building a module kernel (currently with Cache: QorIQ Linux SDK v2.0 PPCE6500 Yocto) and I get a message error when I do an insmod MyModule.ko.

[ 2022.496533] MyModule: disagrees about version of symbol device_destroy
[ 2022.502025] MyModule: Unknown symbol device_destroy (err -22)
[ 2022.506759] MyModule: disagrees about version of symbol device_create
[ 2022.512157] MyModule: Unknown symbol device_create (err -22)

Also, I can not download from Git address: git://git.freescale.com/ppc/sdk/linux.git because it does not working.

Any ideas please???

PS: If I build and insmod in SDK 1.8 it works correctly.

[yipingwang · Accepted solution]

Hello Andreas Rollbühler,

Linux Kernel 4.1.35-rt41 should be from SDK 2.0 1703 release, you could downloaded ISOs from Linux® SDK for QorIQ® Processors|NXP ,  you could download the pre-built image ISO for AARCH64, please boot up the system with uImage, and rootfs filesystem provided in this ISO, Kernel modules are integrated into filesystem in /lib/modules/4.1.35-rt41/kernel/drivers/.

If you want to build your own Kernel module, you could download Kernel source from the following git address.

Git address: git://git.freescale.com/ppc/sdk/linux.git

Commit ID: 1ae843c08261402b2c35d83422e4fa1e313611f4

Please use the same Kernel configuration file to your kernel module as the running Kernel.

Please check whether Makefile options used in your module Makefile is same as Linux Kernel.

In addition, your also could get the standalone GCC Toolchain in the pre-built image ISO.

If it still fails to insert your built module, please get more information from /var/log/messages.

Have a great day,
TIC

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[andreasr]

Hello Yiping,

now I try to achieve the same with the LX2160ARDB. It runs with the linux kernel version 4.9.62.

Is there also a git repository with the appropriate kernel sources for this board? 

Best regards,

Andreas

[andreasr]

Ok, it finally worked by using the kernel sources from the freescale git repository instead the sources from kernel.org

Thank you very much for that hint!

What's interesting: 

Vermagic of the module now says '4.1.35-rt41-176865-g1ae843c SMP mod_unload modversions aarch64' while vermagic of the built in drivers says '4.1.35-rt41 SMP mod_unload modversions aarch64'.

Anyway insmod doesn't complain about a different module version.

[jopado]

Do a modinfo on your .ko file and see how the version compares with uname -r.

[andreasr]

Output of modinfo:

vermagic:       4.1.35-rt41 SMP mod_unload modversions aarch64

Output of uname -a:

Linux ls2088ardb 4.1.35-rt41 #1 SMP Thu Mar 30 01:18:48 CST 2017 aarch64 GNU/Linux

[jopado]

I had a similar issue but I was using the Layerscape SDK. It looks like you are on the QorIQ SDK but fix should be similar. When your insmod fails, there should be an entry in the syslog similar to this:
    modulename: version magic 'xyz' should be 'abc'

You will have to make your version match exactly the kernels (abc). In my case the kernel version magic included modversions but MOD_VERSIONS was not configured in the kernel builds generated autoconf.h. This is a bug in nxp's distro somewhere as I was building my module against a pre-built kernel. I simply modified the autoconf.h adding the line: #define CONFIG_MODVERSIONS 1

I then rebuilt my module and all was good. Here are a couple of good references on this issue. This should help you resolve your problem.

https://linux.die.net/lkmpg/x380.html
http://billauer.co.il/blog/2013/10/version-magic-insmod-modprobe-force/
https://stackoverflow.com/questions/22368264/compiling-out-of-tree-kernel-module-against-any-kernel-...

Let me know how you make out. I have some modules that I will be porting to a QorIQ SDK platform soon so I can provide more relevant data to you if needed.

[andreasr]

Actually there is no entry in the syslog similar to "modulename: version magic 'xyz' should be 'abc'". All I get are the error messages I posted above.

I assume this isn't the problem, since I use the exact same kernel version. There's no difference in the version strings at all.

I also checked the autoconfig.h, but the line '#define CONFIG_MODVERSIONS 1' already exists.

I am not using any SDK, just compiling the kernel module with a simple makefile. Could this be part of the problem?

I got the kernel sources from kernel.org. 

What I read about and might be a problem:

Often people state, that they have to use the Module.symvers file from the running kernel to build their kernel module.

The problem is, that I don't find any Module.symvers file on the LS2088 Linux. On my host this file can be found under /lib/modules/$(uname -r)/build for example.

[jopado]

Hmm. Have a look at these options of modprobe: --force --force-vermagic

--force-modversion. As described in manpage, use of these can be risky but

it might get you able to load and test your module until the build issue

can be resolved.

Back to the build issue...there is more to to the kernel version than uname

-r. What you really need to look at is the vermagic string of the running

kernel so that you can match that up with the vermagic string of your

module. You can try running this to get the running kernels vermagic:

sudo stap -g -e 'probe begin { log ( %{ VERMAGIC_STRING /* string */ %} )

exit() }'

3.10.0-693.2.2.el7.x86_64 SMP mod_unload modversions

Seems like there should be an easier way to get this as not all systems

have stap. Alternatively, look at the file ./include/linux/vermagic.h.

Those will define vermagic string components that should be in your kernels

vermagic.

One more thing - look at the modinfo output from a module that does run on

your kernel. That will give you evidence of what your module's vermagic

should look like.