Kernel driver for Turbosight TBS6285 DVB card

Kernel driver for Turbosight TBS6285 DVB card

[Chris Tapp]

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.

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.

How should I proceed from here? Is there another driver I can use as a starting point?

--

Chris Tapp
opensource@keylevel.com
www.keylevel.com

Re: Kernel driver for Turbosight TBS6285 DVB card

[Bruce Ashfield]

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.
>
> 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.

Did you try adopting the meta-skeleton hello-mod recipe and point it
at that source directory ?

Bruce

>
> How should I proceed from here? Is there another driver I can use as a starting point?
>
> --
>
> Chris Tapp
> opensource@keylevel.com
> www.keylevel.com
>
>
>
>

Re: Kernel driver for Turbosight TBS6285 DVB card

[Chris Tapp]

Hi Bruce,

Thanks for the feedback.

On 20 Aug 2014, at 03:08, Bruce Ashfield <bruce.ashfield@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);
  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.

Looks like I need a patch ;-) Any pointers to where I should be looking would be appreciated as this isn't my normal area...

--

Chris Tapp
opensource@keylevel.com
www.keylevel.com

Re: Kernel driver for Turbosight TBS6285 DVB card

[Bruce Ashfield]

On Wed, Aug 20, 2014 at 4:11 PM, Chris Tapp <opensource@keylevel.com> wrote:
> Hi Bruce,
>
> Thanks for the feedback.
>
> On 20 Aug 2014, at 03:08, Bruce Ashfield <bruce.ashfield@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 ?

>   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.

Bruce

>
> Looks like I need a patch ;-) Any pointers to where I should be looking would be appreciated as this isn't my normal area...
>
> --
>
> Chris Tapp
> opensource@keylevel.com
> www.keylevel.com
>
>
>
>
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: Kernel driver for Turbosight TBS6285 DVB card

[Chris Tapp]

On 21 Aug 2014, at 05:08, Bruce Ashfield <bruce.ashfield@gmail.com> wrote:

> On Wed, Aug 20, 2014 at 4:11 PM, Chris Tapp <opensource@keylevel.com> wrote:
>> Hi Bruce,
>> 
>> Thanks for the feedback.
>> 
>> On 20 Aug 2014, at 03:08, Bruce Ashfield <bruce.ashfield@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).

>  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?

> 
> Bruce
> 
>> 
>> Looks like I need a patch ;-) Any pointers to where I should be looking would be appreciated as this isn't my normal area...
>> 
>> --
>> 
>> Chris Tapp
>> opensource@keylevel.com
>> www.keylevel.com
>> 
>> 
>> 
>> 
>> --
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
> 
> 
> 
> -- 
> "Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end"

--

Chris Tapp
opensource@keylevel.com
www.keylevel.com

Re: Kernel driver for Turbosight TBS6285 DVB card

[Bruce Ashfield]

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

Bruce

>
>> Bruce
>>
>>> Looks like I need a patch ;-) Any pointers to where I should be looking would be appreciated as this isn't my normal area...
>>>
>>> --
>>>
>>> Chris Tapp
>>> opensource@keylevel.com
>>> www.keylevel.com
>>>
>>>
>>>
>>>
>>> --
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>> -- 
>> "Thou shalt not follow the NULL pointer, for chaos and madness await
>> thee at its end"
> --
>
> Chris Tapp
> opensource@keylevel.com
> www.keylevel.com
>
>
>
>

Re: Kernel driver for Turbosight TBS6285 DVB card

[Chris Tapp]

On 21 Aug 2014, at 19:28, Bruce Ashfield <bruce.ashfield@windriver.com> wrote:

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

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@keylevel.com
www.keylevel.com

Re: Kernel driver for Turbosight TBS6285 DVB card

[Bruce Ashfield]

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

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@keylevel.com
> www.keylevel.com
>
>
>
>

Re: Kernel driver for Turbosight TBS6285 DVB card

[Chris Tapp]

On 21 Aug 2014, at 20:30, Bruce Ashfield <bruce.ashfield@windriver.com> wrote:

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

> 
> 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@keylevel.com
>> www.keylevel.com

--

Chris Tapp
opensource@keylevel.com
www.keylevel.com

Re: Kernel driver for Turbosight TBS6285 DVB card

[Bruce Ashfield]

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

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@keylevel.com
>>> www.keylevel.com
>
> --
>
> Chris Tapp
> opensource@keylevel.com
> www.keylevel.com
>
>
>
>

Re: Kernel driver for Turbosight TBS6285 DVB card

[Chris Tapp]

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

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