[yocto] Yocto Kernel Module Workflow Question
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? Any feedback would be appreciated . . . thanks! -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] Fix gitsm.py bug that prevents fetching submodules within submodules.
Previous versions of the gitsm.py fetcher did not anticipate
submodules themselves having additional submodules. This fix
adds a recursive option so all nested submodules are fetched as
well.
---
bitbake/lib/bb/fetch2/gitsm.py | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/bitbake/lib/bb/fetch2/gitsm.py b/bitbake/lib/bb/fetch2/gitsm.py
index c125cff..f89839d 100644
--- a/bitbake/lib/bb/fetch2/gitsm.py
+++ b/bitbake/lib/bb/fetch2/gitsm.py
@@ -109,8 +109,7 @@ class GitSM(Git):
runfetchcmd("sed " + gitdir + "/config -i -e
's/bare.*=.*true/bare = false/'", d)
os.chdir(tmpclonedir)
runfetchcmd(ud.basecmd + " reset --hard", d)
-runfetchcmd(ud.basecmd + " submodule init", d)
-runfetchcmd(ud.basecmd + " submodule update", d)
+runfetchcmd(ud.basecmd + " submodule update --init --recursive", d)
self._set_relative_paths(tmpclonedir)
runfetchcmd("sed " + gitdir + "/config -i -e
's/bare.*=.*false/bare = true/'", d)
os.rename(gitdir, ud.clonedir,)
@@ -131,6 +130,5 @@ class GitSM(Git):
submodules = self.uses_submodules(ud, d)
if submodules:
runfetchcmd("cp -r " + ud.clonedir + "/modules " +
ud.destdir + "/.git/", d)
-runfetchcmd(ud.basecmd + " submodule init", d)
-runfetchcmd(ud.basecmd + " submodule update", d)
+runfetchcmd(ud.basecmd + " submodule update --init --recursive", d)
--
1.9.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to use Git sub-module fetcher (gitsm://) in a recipe?
I noticed a "new" fetcher recently that appears to support fetching Git sub-modules from within a Git project. Unfortunately, I cannot find any examples of how it's used from within a recipe. There is a GitHub project I'd like my fetcher to clone that contains a submodule. Obviously I'd like the fetcher to grab both the main project and recursively sub-modules it contains. Can someone illustrate how this is done, e.g. SRC_URI = "git://github.com/fluendo/gst-plugins-bad.git;protocol=git;branch=sdk-0.10.23-hls" SRC_URI +="gitsm://?" This repo contains a "common" folder which is a Git sub-module. Thanks . . . ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] OPKG configuration questions
> > On 17 October 2013 11:20, Glenn Schmottlach wrote: >> > Just out of curiosity, is it possible that you added "package-management" >> > to IMAGE_FEATURES after you already had a successful full build? Or is >> > it possible that you had already done a full build with "package_rpm" or >> > "_deb" before switching to "package_ipk"? >> > >> >> I added "package-management" after a successful build. > > In that case, if you have the time, I would delete your tmp, > sstate-cache, and cache directories, as well as your bitbake.lock and > pseudodone files and rebuild. Does that make any difference? > Unbeknownst to me, the "init" script on the target platform was mounting a tmpfs (ramdisk) filesystem over the top of "/var" thereby hiding the fact that the opkg database had indeed been installed. So, once I realized this it was clear why I wasn't see these files when the target booted. >> > The reason I ask is (although I never confirmed this definitively but) when >> > I was playing with this stuff a while back I was sure that this package >> > stuff >> > would only get generated after adjusting these configurations when a full, >> > clean build was performed (i.e. removing and ). > >> After manually copying the /var/lib/opkg to my target the opkg-cl >> command now seems to "work". Unfortunately I'm running into difficulty >> specifying a a new ipkg repo that is mounted via NFS from my >> development machine. How would I make it scan there as well? > > I've never tried that before. But maybe if you created a file (on the > target) called, for example, /etc/opkg/nfs.conf which contained: > > src/gz nfs /path/to/nfs > > maybe that would work? Don't forget to perform an "# opkg update" > after creating that file. > After some trial-and-error (and remembering to call opkg-cl update as you suggested) I was able to get my alternative feed to work. So at this point, I *think* I have it all figured out ;-) Thanks to those on the list who offered their suggestions! > There's also a remote chance adding this new repository doesn't appear > to work because your target filesystem is full. I've noticed that in > the past, and opkg doesn't provide much in the way of feedback if/when > this happens. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] OPKG configuration questions
See my feedback/comments below . . .
Thanks for your help . . .
On Wed, Oct 16, 2013 at 5:10 PM, Nicolas Dechesne
wrote:
> On Wed, Oct 16, 2013 at 10:17 PM, Glenn Schmottlach
> wrote:
>> 1) I'm having difficulty getting the /var/lib/opkg directory to be created
>> and populated with a list of installed packages.
>
> i use that routinely. so there must be something wrong in your config ;-)
> you didn't mention which release and layer set you are using, btw.
>
]] I'm using Dylan-9.0.0 with several custom layers for an i.MX6
Nitrogen6x board.
>>
>> 2) I can't figure out (e.g. can find no documentation) that describe what
>> the "lists_dir ext /var/lib/opkg" option in the opkg.conf file does. Does
>> this point to where the list of installed packages should be found?
>
> yes, i think so. so that you can eventually control where they are.
> e.g. if they need to be on a specific folder/file system. also, note
> that the 2nd arg is simply ignored, see
> https://code.google.com/p/opkg/issues/detail?id=73
>
>>
>> 3) What is the best/preferred approach (e.g. patch, *bbappend, new recipe,
>> etc...) to tailor or modify the opkg.conf file (specifically the opkg source
>> (src) paths) that are appended to /etc/opkg/opkg.conf file by the
>> opkg-collatoral.bb recipe.
>
> yes. .bbappend and provide 'src' file in your layer.
]] That makes the most sense. Thanks for the suggestion,
>>
>> This is what I have done to prepare my image to include package management:
>>
>> 1) My image recipe inherits from core-image
>
> i do that too.
>
>>
>> 2) I've configured ONLINE_PACKAGE_MANAGEMENT = "full" and confirmed that is
>> it set correctly via "bitbake-env -r image-nitrogen6x
>> ONLINE_PACKAGE_MANAGEMENT"
>
> that's the only thing I don't do... i don't think this is required,
> looking throughout the sources, that shouldn't be needed, but that
> shouldn't explain the error you gave neither..
>
>>
>> 3) I've confirmed that IMAGE_FEATURES = "debug-tweaks package-management"
>
> did you get that with bitbake -e? also note that IMAGE_FEATURE *must*
> be set before you inherit core-image, so either in a .conf file
> (local.conf, distro.conf, ...) or if you do it in your image recipe,
> you need to do it before. so even if bitbake -e seems right, it might
> be wrong...
>
]] I confirmed that with bitbake -e. It's configured in my local.conf file.
> one way to check is to get the value of the following vars:
>
> ROOTFS_BOOTSTRAP_INSTALL
>
> as it is set in image.bbclass like this:
>
> ROOTFS_BOOTSTRAP_INSTALL = "${@base_contains("IMAGE_FEATURES",
> "package-management", "", "${ROOTFS_PKGMANAGE_BOOTSTRAP}",d)}"
>
>
]] That variable isn't defined in my environment. All I see is the following:
bitbake -e image-nitrogen6x | grep ROOTFS_BOOTSTRAP_INSTALL
# "${IMAGE_INSTALL} ${LINGUAS_INSTALL} ${NORMAL_FEATURE_INSTALL}
${ROOTFS_BOOTSTRAP_INSTALL}"
# " ${IMAGE_INSTALL} ${LINGUAS_INSTALL} ${NORMAL_FEATURE_INSTALL}
${ROOTFS_BOOTSTRAP_INSTALL}"
# $ROOTFS_BOOTSTRAP_INSTALL
# "${IMAGE_INSTALL} ${ROOTFS_BOOTSTRAP_INSTALL} ${FEATURE_INSTALL}"
# "${IMAGE_INSTALL} ${ROOTFS_BOOTSTRAP_INSTALL} ${FEATURE_INSTALL}"
]] In my "image" recipe I inherit from core-image. Do I also need to
also inherit from "image" as well to get this expanded?
>>
>> 4) PACKAGE_CLASSES = "package_ipk" is configured and I see packages in my
>> /build/tmp/deploy/ipk directory
>
> looks ok.
>
>>
>> The target boots fine and I have the appropriate opkg applications installed
>> (e.g. opkg, opkg-cl, opkg-key). I also have the default /etc/opkg/opkg.conf
>> and /etc/opkg/arch.conf installed.
>>
>> There is *no* /var/lib/opkg directory and thus "opkg-cl list-installed"
>> returns with an error because the "opkg" directory is missing. If I manually
>> create it the program run successfully but doesn't list anything (which is
>> obvious since it is empty).
>>
>> I read this post
>> https://lists.yoctoproject.org/pipermail/yocto/2013-June/016324.html
>>
>> and confirmed that my setting are correct for IMAGE_FEATURES and
>> ROOT_POSTPROCESS_CMD (= "run_intercept_scriptlets; license_create_manifest;
>> ssh_allow_empty_password; rootfs_update_timestamp ;")
>>
>> Can anyone offer any suggestions, recommendations, or answers to my
>> questions above?
>
> if you can pastebin the entire content of bibtake -e ,
[yocto] OPKG configuration questions
I have several questions regarding configuring the OPKG package management support in my target image. 1) I'm having difficulty getting the /var/lib/opkg directory to be created and populated with a list of installed packages. 2) I can't figure out (e.g. can find no documentation) that describe what the "lists_dir ext /var/lib/opkg" option in the opkg.conf file does. Does this point to where the list of installed packages should be found? 3) What is the best/preferred approach (e.g. patch, *bbappend, new recipe, etc...) to tailor or modify the opkg.conf file (specifically the opkg source (src) paths) that are appended to /etc/opkg/opkg.conf file by the opkg-collatoral.bb recipe. This is what I have done to prepare my image to include package management: 1) My image recipe inherits from core-image 2) I've configured ONLINE_PACKAGE_MANAGEMENT = "full" and confirmed that is it set correctly via "bitbake-env -r image-nitrogen6x ONLINE_PACKAGE_MANAGEMENT" 3) I've confirmed that IMAGE_FEATURES = "debug-tweaks package-management" 4) PACKAGE_CLASSES = "package_ipk" is configured and I see packages in my /build/tmp/deploy/ipk directory The target boots fine and I have the appropriate opkg applications installed (e.g. opkg, opkg-cl, opkg-key). I also have the default /etc/opkg/opkg.conf and /etc/opkg/arch.conf installed. There is *no* /var/lib/opkg directory and thus "opkg-cl list-installed" returns with an error because the "opkg" directory is missing. If I manually create it the program run successfully but doesn't list anything (which is obvious since it is empty). I read this post https://lists.yoctoproject.org/pipermail/yocto/2013-June/016324.html and confirmed that my setting are correct for IMAGE_FEATURES and ROOT_POSTPROCESS_CMD (= "run_intercept_scriptlets; license_create_manifest; ssh_allow_empty_password; rootfs_update_timestamp ;") Can anyone offer any suggestions, recommendations, or answers to my questions above? Thanks for you help . . . ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] IPK naming oddity for ipkg's containing archived ${PN}-dev files
I've run across what appears to be a naming inconsistency (not sure if it's
intentional or a bug) that seems to impact the name given to the ipk file
for recipe's "dev" files.
Let me be more clear. My recipe produces a shared object library called:
libtts_engine.so
This shared library is deployed in /usr/lib and the package-split directory
structure looks like the following in my recipe workdir:
package-split/tts-sdk-dev
package-split/tts-sdk-dev/usr
package-split/tts-sdk-dev/usr/lib
package-split/tts-sdk-dev/usr/lib/libtts_engine.so
package-split/tts-sdk-dev/usr/include
package-split/tts-sdk-dev/usr/include/tts.h
So, when Yocto generates my ipk archive I would expect it to be named
something like:
tts-sdk-dev_${PV}_${PACKAGE_ARCH}.ipk
Instead, Yocto is generating the following name for the "dev" ipk:
libtts_engine-dev_${PV}_${PACKAGE_ARCH}.ipk
This is *not* consistent with how the other ipk are named by Yocto, e.g.
tts-sdk_${PV}_${PACKAGE_ARCH}.ipk
tts-sdk-doc_${PV}_${PACKAGE_ARCH}.ipk
tts-sdk-dbg_${PV}_${PACKAGE_ARCH}.ipk
In the poky class file (package_ipk.bbclass) I looked at the
do_package_ipk() python function and see that there is an explicit query
for the following variable to determine the base name of the ipk file:
pkgname = localdata.getVar('PKG_%s' % pkg, True)
In most cases, this look-up returns the expected name, e.g. tts-sdk-doc,
tts-sdk-dbg, etc But for some reason, the "dev" package name is
remapped from tts-sdk to libtts_engine. My only counter-measure to correct
this is to add the following explicit assignment in my recipe:
PKG_${PN}-dev = "${PN}-dev"
This seems to "correct" the name. Can anyone explain to me the behavior I
am observing? Is there some reason the "dev" package (and only the "dev"
package) is named differently when the ipk is created. Am I breaking an
expected behavior by forcing it to use the more consistent
tts-sdk-dev_${PV}_${PACKAGE_ARCH}.ipk name? I can't find any documentation
that answers this question.
Thanks . . .
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Syntax for specifying multiple URI's in a PREMIRRORS statement?
I'm trying to figure out the syntax for specifying more than one URI in a single PREMIRROR statement, e.g. PREMIRRORS_append = "git://.*/.* file://toplevel/premirror ftp://ftp.acme.com/pre_mirror/foo \n" So for all "git" fetches I want it to *first* look in a local premirror directory and if the file is not found there then try to fetch from an FTP server. How do you separate the two destination URIs to search? I tried a space ' ' and semi-colon but neither appear to work. Is the syntax documented somewhere. Can anyone provide a suggestion? ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Is there still a Yocto dependency on bash (versus dash)?
I recall a while back that OE/poky had issues with Ubuntu's dash shell (Ubuntu's replacement for bash) which required the the shell to be linked to bash rather than dash. Is this (bash) still a requirement for Yocto/Poky or does it work with dash now. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Creating a meta-layer for a third-party GCC-based binary tool-chain - how?
I'm trying to create a meta-layer for a third-party GCC-based proprietary tool-chain. I need to be able to select this tool-chain on a per-recipe basis while other recipes may either the standard Yocto native/cross-tool-chain. This proprietary tool chain is divided into a host-tool part (where all the cross-tools are located, e.g. arm-unknown-nto-qnx6.5.0-gcc/ar/g++ etc...) and the associated target sysroot that includes common headers and target (arm, mips, ppc, sh4, x86) specific libraries. This tool-chain on my system is sitting in /opt outside of the Yocto environment and is not re-distributable in a third-party SDK (e.g. you have to license it from the manufacturer and install it separately). I seem to have come across two approaches to this problem. One solution appears to be recommended by the OE community and it is described here: http://www.openembedded.org/wiki/Adding_a_secondary_toolchain This approach *seems* to offer the ability to selectively (per recipe) enable/disable a secondary tool-chain. What is not clear is whether Yocto supports this approach. The second approach seems to be the one used by Linaro and CodeSourcery and involves setting the TCMODE/TCLIB variables and may be more extensive. What's not clear is whether the Linaro/CodeSourcery tool-chain can selectively be turned on/off per recipe. I've done some prototyping with both approach but I've had mixed success . . . partly due to my in-experience with BitBake/Yocto. So I hope someone can take pity on me and answer a few questions: 1) Is the OE approach of adding a secondary tool-chain work-able under Yocto? Is the Yocto (TCMODE/TCLIB) approach more acceptable (e.g. recommended) and does it allow the recipe itself (or some other white/black listing approach) to decide which recipes are compiled with the alternate tool-chain? If so, how does a recipe specify the tool-chain that should be used? It's not clear by examining the meta-layers provided by those tool-chains. 2) Since my proprietary tool-chain has it's own sysroot outside Yocto, I believe the recommended approach is to copy this sysroot into the a Yocto generated sysroot. If so, where do I do that? Do create a second recipe to do that? Is it done in the meta-toolchain .conf files or .bbclass files? How do I make sure these system files are copied to the Yocto sysroot before building the recipes that depend on it? 3) What will be the name of the sysroot where I should copy the external binary tool-chain to? I can't figure out who/how that name is generated and used . . . is it based off the tool-chain prefix (e.g. arm-unknown-nto-6.5.0)? Is it something I can specify? 4) The external tool-chain has a non-e/glibc based C library (it's Dinkumware based). Do I have to do anything special to keep it from linking against the one created/used by Yocto? 5) Ultimately, the target machine and OS is not Linux but very similar (e.g. posix based). At this point I'm not concerned about building a boot-able image but rather just building individual recipes and packing the resulting libraries/applications into a convenient tarball (or opkg archive). So I'm thinking I just need to specify a very rudimentary/simple "machine" in order to specify the CPU architecture so the right external cross-tool is selected. Is there any such meta-layer available . . . a very minimal machine? I could accept a QEMU based machine (if necessary) because the OS I'm targeting can be run under QEMU. Of course the question may be whether I really need to specify a machine/distro for my use-case? At this time, I just want to use my tool-chain meta-layer to help me port/build/package several middle-ware and library components using an external (non-distributable) binary tool-chain. In this sense, I'm only using Yocto to do half of it's customary job which (usually) results in a Linux image for a target. This request for assistance is long. Any answers that could be provided (even if they don't address all of my questions) would be extremely helpful. Links to previous discussions would be useful as well. Thanks for your time and consideration . . . ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Trying to Integrate QNX's Neutrino 6.5.0 toolcain into OE/Yocto as a foreign (external) tool-chain
The company I work for tends to do a fair amount of work in both Linux and QNX. Primarily we use the Bitbake/OpenEmbedded/Yocto build framework to build individual recipes (packages, e.g. libraries, apps, etc...) and ultimately Linux BSP images for several HW platforms and CPUs. As I understand it the OpenEmbedded framework supports external (binary) tool-chains (e.g. like those provided with QNX's Linux host tools which are gcc based) so my thoughts have been focused on integrating the QNX tool-chain into the OpenEmbedded/Yocto framework. Ideally, with suitable recipes and the layering system provided by the framework, it seems plausible that I *should* be able to generate QNX executables/libraries/images using this build framework on a Linux host. Has anyone out there attempted this? Is this even feasible since OE/Yocto tends to be so Linux focused. I suspect it could be a great option for people (like myself) who must do development under both platforms and want to create a common build/packaging processes. For my first attempt, I'm not as interested in a full QNX image as selectively building several middle-ware components that are very portable (mostly 'C' code only - no strict Linux dependencies). So far I've examined the Linaro and Code Sourcery toolchain meta-layers. I've tried to to implement my own QNX tool-chain but it's not clear if it's possible to selectively apply this to specific recipes. I've found instructions here for OE: http://www.openembedded.org/wiki/Adding_a_secondary_toolchain but these seems significantly different from the approaches I've seen implemented for Linaro and Code Sourcery. Which one is the correct approach . . . will they both work under Yocto? Also, QNX is *not* eglibc based (it uses Dinkumware C/C++ libraries) so I'm not sure how that might impact the layer. Likewise there are no Linux headers, etc... Also, it's not real clear on how to "enable" this external tool-chain and if it can be done selectively per recipe. I've been racking my brain on this topic. Any helpful guidance would be appreciated. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
