On 08/28/2017 06:46 PM, Gutierrez, Hernan Ildefonso (Boise R&D, FW) wrote:
Hi,
I am new to this dist-list and I am not sure if this is the right forum.
My apologies beforehand if this is not the right list.
This one is as good as any for this question.
Problem statement:
I am evaluating Yocto for a project. We have a workflow where linux
kernel is built from a local git repo separately from the root file system.
I made a recipe to build rootfs using yocto to our target, I deployed
both images (Kernel built from our git repo + rootfs generated by Yocto)
… all this works great.
Now I want to add a couple of kernel modules provided by a third party
vendor. If the module is built along with our kernel build system (and
deployed to target), they work fine.
Is there a way to build kernel modules with Yocto and point them to the
includes of our git kernel repo just to satisfy the kernel dependencies?
Investigate setting your kernel up as an externalsrc recipe. In that
workflow you setup/configure your kernel as you normally do and have
a recipe that points the build system at the source (local to the build
machine). The build system won't configure or otherwise modify your
kernel tree, but will use it as the kernel provider.
As such the modules, etc, will build against the artifacts from that
kernel build and everything will match.
In attempts to explore options, I made a yocto kernel recipe to build a
kernel from our internal git repo.
I made also yocto recipes to build the kernel modules which resolve
dependencies for kernel header files with above yocto kernel recipes.
So I'm clear, in this configuration you have a standard format kernel
recipe that is building your kernel tree (fetched from your repo) and
then the modules are built as they normally would (i.e. the build
system takes care of everything).
But you are actually deploying the kernel image from another build
that you've done (i.e. your existing workflow).
All above builds fine, I can deploy the rootfs which includes the .ko
files I need, I even ask yocto to autoinitialize the modules on boot.
Rootfs fails to load the modules like this:
[FAILED] Failed to start Load Kernel Modules.
See 'systemctl status systemd-modules-load.service' for details.
When I try to insmod the module manually it fails with a vermagic error
like this:
# insmod hello-mod.ko
hello: version magic *'4.9.13_1.0.0_hgv+g68f8dea22b* SMP preempt
mod_unload ARMv7 p2v8 ' should be '4.9.13 SMP preempt mod_unload ARMv7
p2v8 '
insmod ERROR: could not insert module hello.ko: Invalid module format
I’ve read enough and it seems like this is because the kernel image
deployed generated with our separate workflow has a uname as *4.9.13*
and it seems like yocto adds the string _*1.0.0_hgv+g68f8dea22b* to the
vermagic… of the kernel modules, which seems to come from the kernel
recipe I generated to satisfy the dependencies to build the module.
Correct.
You could jump through some hoops to force the build system to not
modify the version string. Alternatively, you could turn off modversions
checking in your kernel build.
But in the end, either of those could cause you issues down the road
since we are circumventing a check that is there to save subtle issues
that could creep into the kernel -> modules interfaces.
I want to know if there is a way to keep building our kernel separately
from the root file system and kernel modules with yocto.
Have a closer look at externalsrc, it may help here.
Bruce
This is just because our workflows are separate for the project we’re
working on. If we build the kernel with yocto, the internal workflows
will change and we are evaluating the options we have.
Thanks, I’ll appreciate any help and if this is not the right dist-list,
please let me know where it’s best to get help.
--Hernan
--
_______________________________________________
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
