Bruce, Thanks for the response. See my answers interleaved below.
--Hernan > -----Original Message----- > From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com] > Sent: Tuesday, August 29, 2017 7:11 AM > To: Gutierrez, Hernan Ildefonso (Boise R&D, FW) > <hernan_gutier...@hp.com>; linux-yocto@yoctoproject.org > Subject: Re: [linux-yocto] Kernel modules and vermagic > > 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. Thanks! > > > > > 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. > I will look into externalsrc recipe and see how it goes. That sounds like what I want to achieve. > > > > 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). > Correct. I made a kernel recipe after looking at multiple examples, but pulling from our repos, and massage a bit the directory structure to match what yocto expects. Then I leave Yocto run its standard make infrastructure. I had to point yocto to our .config file, which is embedded inside the our repo in a particular location, other than that I leave yocto take over... and it all worked fine. > But you are actually deploying the kernel image from another build that > you've done (i.e. your existing workflow). > Yes, our current workflow kicks builds of the kernel on a separate automated system. Ultimately the code built is the same as the one Yocto builds. We might use yocto to also build the kernel, but we're evaluating if that's worth doing as more kernel driver developers will have to be exposed to yocto usage... We're evaluating productivity here. > > > > 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 found my problem last night. I had in my recipe two variables defined: SCMVERSION = "y" and LOCALVERSION = "_1.0.0_hgv " I looked into yocto recipes for kernel build and after some google searches found how they play into forming the utsrelease.h file, which ultimately gives the uname -r to the kernel. I found that changing SCMVERSION = 'n' , it will remove the sha from the git repo which was showing in the vermagic of my modules. I, never observed the LOCALVERSION definition I had above in my recipe, which was exactly the other part of the string in vermagic. Once I changed SCMVERSION = 'n' and LOCALVERSION = "", I rebuild my image and all modules match the right vermagic as my separately kernel built, and they were automatically loaded by systemd when I have KERNEL_MODULE_AUTOLOAD += "hello" defined in them. > > > > > 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 > I will thanks for the advice > > > > 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
