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

[Thomas Senyk <thomas.senyk@pelagicore.com>]

On Wed, February 13, 2013 19:11:59 Otavio Salvador wrote:
> On Wed, Feb 13, 2013 at 3:44 PM, Thomas Senyk
> 
> <thomas.senyk@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@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.

This sounds rather unconventional ;)
I've never seen any platform were libEGL-something.so is the EGL target to 
link to.

In general one should define the default flavor of the GPU-driver
   ... which is setting the libEGL.so symblink.

In relation to the "link by mistake"-argument:
a) You have a fb-only setup: there will be no x11-things.
b) You have a x11 setup: the default is libEGL-x11.so and theirfor no problem.
    ... if on a x11 setup a application want to explicitly link against 
libEGL-fb.so it can do anyway, but at least the default on is set.
c) You have a dfb setup: the default link goes to libEGL-dfb.so

How do applications within the yocto build link against libEGL?
There are generally no .pc file for GPU-drivers
   ... are there internal variables to reference?

> 
> > 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.

Because of the above or because the way I set the symlinks is wrong?

> 
> > 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 already use the yocto toolchain and sysroot ... I think? ;)
I'll checkout what does '-c populate_sdk' as soon as I find some time (I guess 
week after next week)

> 
> I hope it works :)

Me too ;)

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