Re: Yocto Kernel Module Workflow Question

[Mike Looijmans <mike.looijmans@topic.nl>]

On 15-01-15 22:51, Glenn Schmottlach wrote:
> I am developing a codec kernel driver/module for the BeagleBone Black
> and have a question about the recommended work-flow for developing
> this module in the context of the Yocto/poky environment. Currently
> I'm working with the Daisy release using the meta-ti layer and the
> linux-ti-staging_3.14 kernel sources.
>
> The codec driver, at this point, is just an very minimal
> implementation. It follows closely the instructions described here:
>
> http://processors.wiki.ti.com/index.php/Sitara_Linux_SDK_Audio_DAC_Example
>
> The work involves a dummy (platform independent) ALSA driver for the
> DAC and then code modifications to the ALSA machine layer driver
> (sound/soc/davinci/davinci-evm) and the BeagleBone Black device tree
> to knit all of these pieces together.
>
> There seems to be two approaches for developing the codec driver. The
> first approach is to build the codec driver externally from the kernel
> sources (e.g. as described in working with "out-of-tree" modules in
> the Yocto Kernel Development Guide). With this model I can represent
> the codec driver as a separate Yocto/Bitbake recipe and simply include
> the resulting package in my target image.
>
> Unfortunately, the codec driver also requires changes to the kernel
> sources in the ALSA machine layer driver and device tree. My approach
> here is the create a linux-ti-staging_3.14.bbappend file that contains
> a series of patches to the kernel for the machine layer driver and
> device tree. In this scenario, the kernel sources do *not* explicitly
> know about this new codec since there are no changes to the
> sound/soc/codec Makefile and associated Kconfig's that describe the
> dependencies of the codec driver. This means of course that menuconfig
> won't show the codec as a build-able option. So the ALSA machine
> driver (davinci-evm) knows the name of the codec driver but nothing
> more other than it's association with a particular device tree
> configuration node (e.g. dtc_id). This may not be ideal for someone
> configuring the kernel since this codec doesn't appear as an option
> and the dependencies (as described in the Kconfig) are not clear.
>
> The work-around, albeit clumsy, is to bundle the changes to the
> Makefile/Kconfig's and the codec source itself as a set of patches
> referenced from the linux-ti-staging_3.14.bbappend file. Now building
> the kernel modules also builds the codec (e.g. no separate codec
> Bitbake recipe is required).  This works but now my codec sources
> exist as a "patch" and stored directly in the recipe. Assuming I want
> to do iterative development with this module, every change to the
> codec sources require me to update the codec "patch". Also, the codec
> source must then effectively be version-controlled within the
> *.bbappend recipe itself (as a *.patch file or possibly as a naked
> codec.c that is copied into the destination kernel sources during the
> patch step of bitbake).
>
> Ideally, I'd like to maintain my codec driver outside of the kernel
> tree (since it is not dependent on the BeagleBone Black) and just
> maintain the *.bbappend to make the necessary platform-specific
> machine-layer/device-tree patches. I want the codec to be built with
> the kernel sources but not treated as a Yocto "out-of-tree" module. Is
> there a way for the *.bbappend to fetch the codec sources from another
> repo and place them in the kernel sound/soc/codecs directory before
> the kernel is built? Can anyone suggest a better/alternative work-flow
> that accommodates keeping the codec sources in a separate repo (much
> like the "out-of-tree" modules) while allowing seamless integration
> into the kernel sources. Fundamentally, I don't want the codec sources
> to be version controlled directly *inside* the *.bbappend recipe as
> either a patch or as a raw source file. Is there an alternative
> work-flow that works better with Yocto?
>

Obvious alternative is to fork the kernel and manage it in your own repo. 
Using git "rebase" you can keep your changes on top, and git format-patch can 
generate patches for when you want your recipe to go out into the big bad world.

The kernel source dir is a git repository, so you can us that as your 
repository for making changes too. Instead of pushing your work, use git 
format-patch to output the patches (into the bitbake recipe path). When you 
build the kernel, the git repo will contain your patches as commits.




Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax:  (+31) (0) 499 33 69 70
E-mail: mike.looijmans@topic.nl
Website: www.topic.nl

Please consider the environment before printing this e-mail

Topic zoekt gedreven (embedded) software specialisten!
http://topic.nl/vacatures/topic-zoekt-software-engineers/