[yocto] Kernel driver for Turbosight TBS6285 DVB card

Fri Aug 22 12:57:37 PDT 2014

On 22 Aug 2014, at 14:29, Bruce Ashfield <bruce.ashfield at windriver.com> wrote:

> On 14-08-22 03:37 AM, Chris Tapp wrote:
>> 
>> On 21 Aug 2014, at 20:30, Bruce Ashfield <bruce.ashfield at windriver.com> wrote:
>> 
>>> On 14-08-21 03:11 PM, Chris Tapp wrote:
>>>> 
>>>> On 21 Aug 2014, at 19:28, Bruce Ashfield <bruce.ashfield at windriver.com> wrote:
>>>> 
>>>>> On 14-08-21 04:17 AM, Chris Tapp wrote:
>>>>>> On 21 Aug 2014, at 05:08, Bruce Ashfield <bruce.ashfield at gmail.com> wrote:
>>>>>> 
>>>>>>> On Wed, Aug 20, 2014 at 4:11 PM, Chris Tapp <opensource at keylevel.com> wrote:
>>>>>>>> Hi Bruce,
>>>>>>>> 
>>>>>>>> Thanks for the feedback.
>>>>>>>> 
>>>>>>>> On 20 Aug 2014, at 03:08, Bruce Ashfield <bruce.ashfield at windriver.com> 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
opensource at keylevel.com
www.keylevel.com