On 21 Aug 2014, at 20:30, Bruce Ashfield <[email protected]> wrote:
> On 14-08-21 03:11 PM, Chris Tapp wrote: >> >> On 21 Aug 2014, at 19:28, Bruce Ashfield <[email protected]> >> wrote: >> >>> On 14-08-21 04:17 AM, Chris Tapp wrote: >>>> On 21 Aug 2014, at 05:08, Bruce Ashfield <[email protected]> wrote: >>>> >>>>> On Wed, Aug 20, 2014 at 4:11 PM, Chris Tapp <[email protected]> >>>>> wrote: >>>>>> Hi Bruce, >>>>>> >>>>>> Thanks for the feedback. >>>>>> >>>>>> On 20 Aug 2014, at 03:08, Bruce Ashfield <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> On 2014-08-19, 5:26 PM, Chris Tapp wrote: >>>>>>>> I need to include the kernel driver for the Turbosight TBS6285 DVB >>>>>>>> card in an image. >>>>>>>> >>>>>>>> The official bundle at >>>>>>>> http://www.tbsdtv.com/download/document/common/tbs-linux-drivers_v140707.zip >>>>>>>> includes the drivers and a load of other "stuff" (e.g. a full V4L >>>>>>>> build). >>>>>>>> >>>>>>>> LinuxTV.org have the drivers extracted into a .tar.bz2 at (e.g.) >>>>>>>> http://linuxtv.org/downloads/drivers/linux-media-LATEST.tar.bz2, so I >>>>>>>> plan to use this as the download source. >>>>>> This bit is wrong - I need to use the .tar.bz within the .zip. >>>>>> >>>>>>>> So far I have a recipe which downloads from this URL and extracts the >>>>>>>> files into the work area and ${WORKAREA}/drivers/media includes a >>>>>>>> Makefile and Kconfig. >>>>>>>> >>>>>>>> I've looked at the Yocto documentation, but this doesn't seem to be a >>>>>>>> good match for the "Out of tree" kernel module case. >>>>>>> Hmm. At a glance, I'd say that it does sound like a typical out of >>>>>>> tree module build. >>>>>> Ah, ok - to my (untrained) eye the use-case looked completely different >>>>>> based on the example. >>>>>> >>>>>>> Did you try adopting the meta-skeleton hello-mod recipe and point it >>>>>>> at that source directory ? >>>>>> I have now (with the above change). However, it looks as if something >>>>>> within the build is referencing the host file system when building. >>>>>> >>>>>> I'm building for ValleyIsland 32-bit: >>>>>> >>>>>> 1) If I configure the drivers for 32-bit there is a linker error >>>>>> complaining that elf 32 and elf 64 aren't compatible (host is 64 bit); >>>>> Hmm. The target arch should be used for this build. Are you enabling a >>>>> multi lib config >>>>> as well ? >>>> Not that I know of ;-) >>>> >>>> The build uses a .version file to specify the kernel. The top makefile >>>> creates this using 'uname -r' by default. I can run 'make dir DIR="..." in >>>> do_configure() to specify the path to the yocto kernel files, which seems >>>> to fix this (after modifying another makefile, which prepends "../" to the >>>> DIR path). >>> >>> Definite host contamination there. You likely want the code, but >>> not the build infrastructure in this case. >>> >>>> >>>>> 2) Everything appears to build if I target 64-bit, but the installer >>>>> tries to modify /lib/modules/3.2.0-67/..., which is also part of the host. >>>>> >>>>> Do the Makefile's that come in that archive (I haven't gone to look) >>>>> have a custom >>>>> install rule ? If so, that's likely the problem. If the kernel's build >>>>> system is triggered >>>>> (i.e. the makefile follows the conventions), everything will be >>>>> installed to the proper >>>>> location. >>>> The installer uses DESTDIR to select the installation path - I've not >>>> worked out how this gets set yet or how I can set it from within my recipe. >>>> >>>> Is there a trick I can use to get the kernel's build system to manage >>>> things? >>> >>> In this case, you really need to replace (or patch) the existing Makefile >>> that comes with the package. >>> >>> The hello-mod example I pointed out has makefile that shows the right >>> definitions to allow the kernel's build system to enter the directory, build >>> and install the modules. >> >> I've made some good progress, but still not quite there. >> >> I've got a do_compile() that basically does: >> >> make DIR=${STAGING_KERNEL_DIR} >> >> The appears to build the modules correctly - testing will tell ;-) >> >> I've then got similar in do_install(): >> >> make DIR=${STAGING_KERNEL_DIR} DESTDIR=${D} >> >> That's 99% there - the modules get put in image/lib/modules/3.10.40-ltsi/... >> They should be in image/lib/modules/3.10.40-ltsi-yocto-standard/... - not >> sure yet how to fix this one. >> > > The kernel-abiversion should have all the details to get the mdoules > installed in the right place. See the use of the file in the various > module bbclasses. > > export KERNEL_VERSION = > "${@base_read_file('${STAGING_KERNEL_DIR}/kernel-abiversion')}" Thanks, that helps. Looks like I need to find a bug in the makefiles now - using kernel-abiversion results in a message reporting that 3.10.40-ltsi-yocto-standard will be used, but the installation ends up going to 3.0.40-ltsi-yocto-standard :-( > > Bruce > >> There is also a packaging QA issue causing a build failure (some files >> aren't used), but an INSANE_SKIP installed-vs-shipped fixes that one for now. >> >> -- >> >> Chris Tapp >> [email protected] >> www.keylevel.com -- Chris Tapp [email protected] www.keylevel.com -- _______________________________________________ yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/yocto
