So, in practice, should we start using these new layers immediately? Also, will new work/changes only be done in these new/renamed layers?

I just verified this on my SabreLite which has OV5642 & OV5640_MIPI installed. With the 3.10.53 kernel built in July, both sensors are found and function. With the 3.14.28 kernel built today, only the

Exactly the same. I'm not sure where I got that, sorry. I was definitely using the above commit.

The checkout defaults to master: gthomas@Zeus:/tmp/meta-fsl-arm$ git branch -a * master remotes/origin/1.4_M3 remotes/origin/1.4_M5 remotes/origin/HEAD -> origin/master remotes/origin/daisy remotes/or

I tried forcing this via: gst-launch-1.0 playbin uri=file:///some_file.mp4 It starts up, then fails with: Setting pipeline to PAUSED ... Pipeline is PREROLLING ... [INFO] Product Info: i.MX6Q/D/S [INF

Sadly, I'm not sure how to make this happen when the command in question is hiding behind various wrappers (e.g. gtk-play)

All I know is that it does work correctly on other platforms, e.g. a native x86 (intel-corei7-64), as well as when there are no i.MX plugins installed, so it's definitely tied to the FSL plugin.

Thanks for the explanation, perhaps it can help someone fix this. My guess is that the FSL plugin doesn't handle those dynamic elements and thus is not equipped to set up the render in the appropriate

Sadly, that doesn't work: | make[3]: *** No rule to make target `arch/arm/boot/dts/imx6dl-riotboard.dtb'. Stop. | make[2]: *** [imx6dl-riotboard.dtb] Error 2 | make[1]: *** [sub-make] Error 2 | make:

Duplicating your steps pointed out my problem - I was building with some additional layers, one of which had a stale/old version of u-boot.inc. I've sorted this now and can build as you suggested. Tha

Is this recipe truly *machine* dependent, or *SOC* dependent? e.g. I have a target which is roughly the same as the ls1021atwr which could use this and the way this recipe is written, I'd have to writ

Did you mean to make this change or perhaps failed to send this last patch file?

I think this should be PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-myproj" there's a difference between "-" and "_". Also, you could add PREFERRED_VERSION_linux-yocto-myproj = "3.10%"

It looks like you booted from mmc1 but the kernel is waiting for mmc0

This now works. I can't tell if it's using the Vivante - the display is pretty slow... Also, I get continuous errors/warnings running the demo: QWSLock::down(): Invalid argument QWSLock::up(): Invalid

I've worked past this error (in my distribution layers) and am building the QTE image from scratch. This takes quite a while - I'll report what I find when it's complete.

Agreed, it works fine with gstreamer, just not mplayer which works great on all of my other platforms :-(

Why didn't you make the branch adjustable for u-boot-fslc? I for one use that as well, but not the same branch/rev.

BTW, the patch has been applied to OE-core master, but not the dora branch.

I've used this successfully on the i.MX6 git://github.com/boundarydevices/imx_usb_loader.git Just to make sure - what were you looking to do with the tool?