[yocto] Building a Kernel Module that uses /lib/modules/<version>/build/Makefile

[Ronald Oakes]

I seem to have been able to solve my own problem by doing a bit more
poking around:

It looks like the makefile I'm looking for is found in
${STAGING_KERNEL_DIR}, which appears in the Makefile as
$(KERNEL_PATH).

At least once I replaced the setting that was hard coded to
/lib/modules/$(KERNEL_VERSION/build with $(KERNEL_PATH), I'm getting a
build.  (I'm still getting some issues with the fact that my third
party source doesn't want to build wtih either kernels 4.1.18 or 4.4.x
as they are both too new, so I may have to patch it's linux_common.h
to accept 4.1.18 instead of 4.1.1, but that is a minor issue in
comparison)

Thank you
  Ron Oakes

On Tue, Sep 6, 2016 at 11:11 AM, Ronald Oakes <ronaldo at brc2.com> wrote:
> I'm trying to integrate a 3rd party kernel module for some hardware
> that we are using as part of our project.  Following the directions
> that work on the native Linux installation for building it doesn't
> quite work for a number of reasons, so I'm now modifying the generated
> Makefile.
>
> However, it appears that the bulk of the work is done by a standard
> makefile located in /lib/modules/$(KERNEL_VERSION)/build (which was
> actually hard-coded by the configure before I started modifying the
> makefile).  But, I'm not able to locate this in the files that Yocto
> has produced when building the embedded kernel and the other kernel
> modules.
>
> I've not booted the target and looked there - but I'd rather not build
> this on the target.  Ideally, I'd like to have everything built on my
> development system (not that we won't have the horsepower to build on
> the target, but I'd rather not be putting the compilers there, nor
> have to be having a module build as part of bring up each time - we
> won't have any non-volitate memory so everything will have to be
> loaded each time we boot.
>
> Similarly, building the binary and just including that may be
> difficult as our build system is running a much older kernel than our
> target (3.10 versus 4.4), so we'd still be in a cross-target situation
> and the 3rd party supplier assumes that one is building for the system
> one is running on and provides limited support otherwise in their
> documentation (I've not contacted them for assistance yet)
>
> Any suggestions/recomendations?
>
> Ron Oakes