I'll give it a try (will be a while as I've moved to the 5.0.1 release and the build has just started!). Thanks for the suggestion :-) Chris Tapp opensource@... www.keylevel.com

I asked Sarah Sharp if she had any thoughts, she responded in part: One thing I might suspect is a problem with the host controller going into suspend. I think 2.6.34 didn't have support for USB

I haven't seen this merged yet, been a week. Is there a concern with the series, or maybe it just got lost in the mix? Thanks, Darren -- Darren Hart Intel Open Source Technology Center Yocto

Aha. We've seen similar things here over the years. At least this doesn't sound like it caused too much pain. Cheers, Bruce

Looks like this is just a kernel load order issue. The USB storage device seems to cause the sound device to initialise earlier in the boot so it's ready when ALSA loads. Without it, it's not

Right, but it doesn't work and isn't exactly user-friendly: COMMERCIAL_LICENSE := "${@oe_filter_out('emgd-driver-bin', '${COMMERCIAL_LICENSE}',

Tom, I thought we talked about using the oe_filter mechanism here instead of a flat override, since this will bring in other COMMERCIAL_LICENSED content. Sau!

'%' can be used only at the end and it's expected to produce only 1 match like 1.0+git% if there is only one version starting '1.0+git' and we just don't know exact SRCPV/SRCREV

We can get away from it without setting preferred version by either the default preference scheme, or by virtue of removing the default preferred version from poky.conf. I'm working on the latter

It is a wildcard .. I tried briefly to get it to match the point release. I had the same problem here, and didn't get the right combination to match the point release. I'll look at it more today as

Maybe the extra load isn't a big deal, but at least the SRCREVs can change most of the time without breaking everything like this does. It would be great not to have to set the preferred version at

I'm running on a platform using the Vortex86DX SoC which includes a CM119 USB audio interface. I've got a kernel configuration that recognizes and initializes this ok (dmesg reports it as an ALSA

and 3.0.3 is out... Don't forget the -rt variant, it is still at 3.0. It makes a lot more sense to me to specify the kernel to use in the machine config and not allow whatever recipe claim

Another thought on this is that we follow up on the discussion that we had when I first had to force some boards back to 2.6.37. We drop all the preferred version manipulations and control this

I made this change due to some other explicit requests about the kernel version not being obvious. I don't really see this as a big deal, I'm already updating SRCREVs, we are already updating

We have just rolled out PREFERRED_VERSION="3.0+git%", and these now fail with messages like: NOTE: preferred version 3.0+git% of linux-yocto not available (for item virtual/kernel) I could patch

with latest poky git pull, did "bitbake -c fetchall world" just for fun and got: NOTE: Resolving any missing task queue dependencies NOTE: Preparing runqueue ERROR: Multiple .bb files are due to be

Thanks, but please don't speed too much time on it if 'standard' isn't going to work. This is only a research project at the moment and I can patch my defconf easily enough for now (especially as it

That's what I was trying to say ;-) I am. Sounds like a plan. Where can I find a list of the branches in the 4.0.1 meta data? I'm using the following to select one at the

Alright, sounds like a bigger project to get it out of the layer.conf and probably something we need to get into the documentation somewhere. This series looks fine to me otherwise. -- Darren