Compile own Driver Module
Hello, is it possible to compile your own userspace driver module for emteria?
I have a driver that worked nicely when cross compiled for rpi lineageos 14.2 and other embedded androids but I can't find the right kernel headers / version for the latest emteria version.
Tried with 4.9.79+ from the raspberrypi/linux git repos but missing a "-v7":
hellomod: version magic '4.9.79-v7+ SMP preempt mod_unload ARMv7 p2v8 ' should be '4.9.79+ SMP preempt mod_unload ARMv7 p2v8 '
and when forcing the insmod getting:
hellomod: Unknown symbol __aeabi_unwind_cpp_pr1 (err 0)
I am rather new to the linux kernel, so I might just be missing something obvious.
Thanks, Dominik
Comments
Hi Dominik,
This should definitely be possible. If it isn't yet, we will adjust our project accordingly. Using the
raspberrypi/linux
git repo is the correct way. I'll check if "-v7" was removed in our configuration and re-apply it, if it helps you to achieve your goal.Hi kalkov, thanks for coming back. Actually I just figured it out myself.
My "work-around":
1. I am overriding the vermagic in the module so it matches with MODULE_INFO(..)
2. My .config had CONFIG_ARM_UNWIND=y where the emteria kernel does not.
Even if it works now, a follow-up question would be if there is a way to get the original emteria config from somewhere? I can't find it in /proc .
Well, it seems to be a good idea to comply to the official magic anyways, so I'll check it for the next release and add the "-v7" suffix. The config file is automatically generated from a set of different config files (official, oem, emteria, android) during the build process and we don't keep the result (as it can be easily re-generated). Please feel free to contact me directly and we will find a way to make it possible for your application. Since including CONFIG_ARM_UNWIND=y shouldn't affect the performance, we can also include it in our config by default to make your life easier.
Thanks, I am good with the current situation for the moment.
Some closing notes:
1. The suffix match would be nice. I'll check with the next release.
2. It's kind of you to offer the addition of the config switch, but I wouldn't want you to start adding every config switch that someone has set differently, even if you don't foresee negative consquences. I'd rather have the information available how I need to configure my kernel to build driver modules for it.
You can close this issue. Thanks.