On 25.10.2013 13:11, Dmytriyenko, Denys wrote:
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.

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.

Well then I don't understand why compiling the dsplink module causes an error during creation of the
RootFS when not adding the RPROVIDES_${PN} += "kernel-module-dsplinkk" to ti-dsplink.inc

Error log follows:

 Some packages could not be installed. This may mean that you have
| requested an impossible situation or if you are using the unstable
| distribution that some required packages have not yet been created
| or been moved out of Incoming.
| The following information may help to resolve the situation:
|
| The following packages have unmet dependencies:
|  ti-dsplink : Depends: kernel-module-dsplinkk but it is not installable
| E: Unable to correct problems, you have held broken packages.

Or is that error by design to avoid people using the dsplink module within dylan?
As mentioned, I did not test the resulting firmware image yet, so maybe there is indeed a problem with the modules, although I can't imagine why it shouldn't work as the used kernel is still the same.