Hi Bruce, I sent the note below back in August and you nicely point me to the external source recipe workflow. Just before the Dec break, I ran into this nice tutorial from the yocto project which covers the topic in detail.
https://www.yoctoproject.org/sites/default/files/kernel-lab-1.5.pdf This doc is a bit dated but great information in it! Are you (or anybody aware) if there is a more recent version of this doc compared to more recent yocto branches? Is information basically mostly applicable to more recent yocto branch versions? Thanks, --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. > > > > > 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
