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.looijm...@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/
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto