[meta-ti] State of dylan branch in meta-ti
Dmytriyenko, Denys
denys at ti.com
Fri Oct 25 04:11:23 PDT 2013
Because they don't have to be called that. The only extra thing the new class does is sets up the dependencies. So even when a custom module name is used, it will work fine.
Denys
-----Original Message-----
From: Volker Vogelhuber [v.vogelhuber at DigitalEndoscopy.de]
Received: Friday, 25 Oct 2013, 12:08
To: Dmytriyenko, Denys [denys at ti.com]
CC: meta-ti at yoctoproject.org [meta-ti at yoctoproject.org]
Subject: Re: [meta-ti] State of dylan branch in meta-ti
On 25.10.2013 12:58, Dmytriyenko, Denys wrote:
On 25.10.2013 12:30, Denys Dmytriyenko wrote:
On Fri, Oct 25, 2013 at 12:12:35PM +0200, Volker Vogelhuber wrote:
I just checked out the dylan branch of the yocto core and the
meta-ti repository.
It seems like the state of the meta-ti branch is not yet consistent
to work out of the box.
I currently had to remove the update-modules part from the ti
recipes and had to add
RPROVIDES_${PN} += "kernel-module-dsplinkk" to the ti-dsplink.inc
Did I miss something or the dylan branch just not yet in a consistent state?
It's in great shape - better than ever! What you don't mention is what
platform you are using. You do mention dsplink though, but that is long since
unsupported. As a matter of fact, most of the old DSP related recipes are not
supported [1]. The new replacements are not ready yet. Other than that, it
provides great BSP support for platforms listed in the conf/ directory.
[1] http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-ti/README?h=dylan
Thanks for the link, actually I did not read that notice yet indeed.
I'm currently using a TAO-3530 board from technexion.
We used to work with the denzil branch for some time, but after updating to ubuntu
13.10 there were a lot of errors that I tried to fix with the dylan branch. And indeed after
patching some small problems (next to the patches for the meta-ti branch), it does create
a rootfs image at least, but have to flash it and test if it has some additional problems.
I only wonder why the problem with the kernel-module- package name does only occure with the
dsplink and not with the e.g. libgles modules as they seem to provide wrong package names as well.
What do you mean by the wrong package name?
In the hello-mod_0.1bb script under meta-skeleton within the dylan branch of the yocto repository
there is the following notice:
# Kernel module packages MUST begin with 'kernel-module-', otherwise
# multilib image generation can fail.
#
# The following line is only necessary if the recipe name does not begin
# with kernel-module-.
#
PKG_${PN} = "kernel-module-${PN}"
I guess because there is a new bbclass within dylan called kernel-module-split.bbclass
that has the following lines adding dependencies automatically.
...
if modules:
metapkg = d.getVar('KERNEL_MODULES_META_PACKAGE', True)
d.appendVar('RDEPENDS_' + metapkg, ' '+' '.join(modules))
the do_split_packages method called before that code gets executed seems to automatcally create
a list with kernel modules that all start with kernel-module-%s. I did not check what modules this method recognized. Maybe dsplinkk.ko was the only one and that's why the other modules did not
cause an error. Actually I did not spent to much time digging into the reason for introducing this bbclass at all.
So to answer your question, all the module recipes within the meta-ti repository don't seem to be named with a "kernel-module-" prefix, but only the dsplinkk.ko module result in an error.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-ti/attachments/20131025/a38ea0d6/attachment.html>
More information about the meta-ti
mailing list