On 22 Aug 2014, at 14:29, Bruce Ashfield <[email protected]> wrote:
> On 14-08-22 03:37 AM, Chris Tapp wrote: >> >> 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 :-( >> > > ouch. Breaking new ground with that one .. who needs that extra '1' ? Good > luck tracking it down .. you are definitely closer now. Got it! In do_configure() I just needed to: make release DIR=${STAGING_KERNEL_DIR} This creates a .release file to set the version used by the build, based on the top-level makefile of the kernel. That doesn't quite get there though, as this sets KERNELRELEASE in the .release file to 3.10.40-ltsi - this allows do_compile() to run ok, but do_install() then uses 3.10.40-ltsi within the install path, putting the modules in the wrong location. Luckily, 'sed' can be used in do_configure() (after the 'make') to change KERNELRELEASE to the content of kernel-abiversion, which then means do_install() writes to the correct location, the compile still works and there's no '1' missing (so no need to work out why!) ;-) Thanks for all your time and useful pointers :-) Just need to put this somewhere public in case anyone else needs it. > Cheers, > > Bruce > >>> >>> 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 -- _______________________________________________ yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/yocto
