[meta-freescale] [meta-fsl-arm][PATCH v4 0/9] iMX6Q BSP 1.1.0 upgrade

Otavio Salvador otavio at ossystems.com.br
Wed Feb 13 13:11:59 PST 2013


On Wed, Feb 13, 2013 at 3:44 PM, Thomas Senyk
<thomas.senyk at pelagicore.com> wrote:
>
> On Tue, February 12, 2013 19:59:45 Otavio Salvador wrote:
> > On Tue, Feb 12, 2013 at 7:58 PM, Otavio Salvador
> >
> > <otavio at ossystems.com.br> wrote:
> > > Hello,
> > >
> > > This patch series upgrades the iMX6Q BSP to 1.1.0; it also try to fix
> > > the DRI support for it.
> > >
> > > Please give it a try as this is a huge upgrade and we might have
> > > regressions and pending issues still unkown. This series depends on a
> > > cuple of patches I sent to OpenEmbeeded-Core mailing list for
> > > xserver-xorg and mesa, please apply them before playing with this
> > > series.
> >
> > I've created a bundle for this series:
> >
> > OE-Core/Poky patches:
> >
> > http://patches.openembedded.org/bundle/otavio/oe-core-dri-patches/
> >
> > Meta-FSL-ARM patches:
> >
> > http://patches.openembedded.org/bundle/otavio/bsp-1.1.0-update/
>
> Nice thanks for the bundle.
>
> Most of my issues got fixed in v4! good job! :)
>
> The left overs:
>
> 1. After applied the upstream patches I got:
>
> ERROR: No recipes available for:
>   /home/tsenyk/projects/oe-yocto/fsl-community-bsp/sources/meta-fsl-
> arm/recipes-graphics/mesa/mesa-dri_9.0.1.bbappend
> ERROR: Command execution failed: Exited with 1
>
> ... their is probably just some patch missing or something .. I just deleted
> it and it was good ;)
> I don't care that much about this one :) (I just wanted to report this)


Yes. I will check if we need to keep the bbappend or it is safe to drop it.

>
> 2. The deploy and symlinks in the image look very good now:
> lrwxrwxrwx 1 root root       12 Feb 13 17:49 libEGL.so -> libEGL-fb.so
> -rw-r--r-- 1 root root   803326 Feb 13 17:33 libGAL-fb.so
> lrwxrwxrwx 1 root root       12 Feb 13 17:49 libGAL.so -> libGAL-fb.so
>
> nice!


Not that nice; in fact we shoudln't have the symlinks or X11 things
might end linking against framebuffer libraries by mistake.

>
> Also the deploy in the sysroot looks good (only libEGL-fb.so and non of the
> others are present) .... so the file-split is working, but there are no
> symblinks.
>
> I tried to fix this by creating symlinks manually in do_install:
>
> diff --git a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc b/recipes-
> graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
> index 9818c72..af6dc82 100644
> --- a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
> +++ b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
> @@ -91,6 +91,20 @@ do_install () {
>         ${D}${libdir}/libGAL.so \
>         ${D}${libdir}/libVIVANTE.so
>
> +    if [ "${KEEP_XLIBS}" = "yes" ]; then
> +        ln -s ${D}${libdir}/libEGL-x11.so ${D}${libdir}/libEGL.so
> +        ln -s ${D}${libdir}/libGAL-x11.so ${D}${libdir}/libGAL.so
> +        ln -s ${D}${libdir}/libVIVANTE-x11.so ${D}${libdir}/libVIVANTE.so
> +    elif [ "${KEEP_DFBLIBS}" = "yes" ]; then
> +        ln -s ${D}${libdir}/libEGL-dfb.so ${D}${libdir}/libEGL.so
> +        ln -s ${D}${libdir}/libGAL-dfb.so ${D}${libdir}/libGAL.so
> +        ln -s ${D}${libdir}/libVIVANTE-dfb.so ${D}${libdir}/libVIVANTE.so
> +    else
> +        ln -s libEGL-fb.so ${D}${libdir}/libEGL.so
> +        ln -s libGAL-fb.so ${D}${libdir}/libGAL.so
> +        ln -s libVIVANTE-fb.so ${D}${libdir}/libVIVANTE.so
> +    fi
> +
>      find ${D}${libdir} -type f -exec chmod 644 {} \;
>      find ${D}${includedir} -type f -exec chmod 644 {} \;
>  }

Read obove...

> I have absolutely NO idea if this is in anyway the right thing to do!
> I had errors, bitbake complaining about .so files not part of the -dev package
> ... but for some reason I don't get those anymore after I removed all of my
> other changes and just kept the 'ln -s'-lines ... so:
> If you think it the right way, just take it and submit v5 and/or commit it
> after v4 is merged.

No; it is not.

> 3. I still got the following errors when starting any Qt5 application:
>
> vertex shader compilation error:
> fragment shader compilation error:
> program link error: No vertex shader attached.

> My setup: I do a image of my own, the main(!) contents of the image is:
> inherit core-image
> IMAGE_INSTALL += "libpng tslib libudev gpu-viv-bin-mx6q"
> IMAGE_FEATURES += "ssh-server-openssh tools-debug"
> DEPENDS = "gpu-viv-bin-mx6q libpng"
>
> Then I compile Qt5 git from outside of yocto, my configure line:
> ../qt5/configure -opensource -confirm-license -make libs -device imx6 -device-
> option CROSS_COMPILE=~/projects/oe-yocto/fsl-community-bsp/imx6-
> build-10/tmp/sysroots/x86_64-linux/usr/bin/armv7a-vfp-neon-poky-linux-
> gnueabi/arm-poky-linux-gnueabi- -sysroot ~/projects/oe-yocto/fsl-community-
> bsp/imx6-build-10/tmp/sysroots/imx6qsabrelite -prefix /opt/pelagicore/Qt5.0-
> yocto-imx6-10 -opengl es2 -no-pch -v

This might be the cause of the problem. We need to build it using
Yocto toolchain so it links with proper library names or we raise the
errors we need to deal with. Can you give it a try?

> This way I've compiled Qt5 against yocto builds for a while now.
> The only related problem I had in the past was the '#define mediump vs.
> heighp' which I could solve a patching Qt.
> This isn't helping anymore ... but I'm still investigating.

Please check if you can build against the toolchain. To generate the
toolchain for your image do:

bitbake <image> -c populate_sdk

I hope it works :)

--
Otavio Salvador                             O.S. Systems
E-mail: otavio at ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br



More information about the meta-freescale mailing list