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

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

On Tue, February 26, 2013 14:39:18 Otavio Salvador wrote:
> On Tue, Feb 26, 2013 at 2:25 PM, Thomas Senyk
> 
> <thomas.senyk@pelagicore.com> wrote:
> > On Fri, February 15, 2013 16:23:42 Otavio Salvador wrote:
> >> On Fri, Feb 15, 2013 at 3:10 PM, Thomas Senyk
> >> 
> >> <thomas.senyk@pelagicore.com> wrote:
> >> > 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.
> >> 
> >> For this the alternatives system might be a solution for the target.
> >> The problem is what to do during the build of applications. Think in
> >> 
> >> such case:
> >>  - gpu-viv is build
> >>  - app-fb is build
> >>  - app-x11 is build
> >> 
> >> If we have libEGL.so how we manage to link each to the right one?
> > 
> > Why would you support this anyway?
> > Having two EGL versions on your system/sysroot at the same time sounds
> > wrong doesn't it?
> 
> At runtime, I agree but not at build time.
> 
> > I'd say it depends on your DISTRO_FEATURES and you need to choice either
> > linuxfb, directfb or x11.
> > 
> >  ...and the rules are something like:
> >   - is x11 in your DISTRO_FEATURES? => x11 version of drivers
> >   - if not, is directfb in your DISTRO_FEATURES? => egl version of drivers
> >   - if not: linuxfb version of drivers
> 
> But distro features does not mean "enforce X11 use" but "allow X11
> use" so it seems we should support fb use even with X11 feature
> enabled.
> 
> > <side note>
> > Besides that: You need to solve the "link to the right one" anyway, if you
> > have libEGL.so or not. (Although I admit it's more likely to cause
> > problems if you have it)
> > <\side note>
> > 
> >> > 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
> >> 
> >> This works well for runtime and I fully agree.
> >> 
> >> I am concerned about how we will manage it at *build* time. Bear on
> >> mind that app-fb and app-x11 can be build in parallel so change the
> >> link during the build is not going to work.
> > 
> > again: why support 2 build targets in the same sysroot?
> 
> Read above.
> 
> >> > 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?
> >> 
> >> You may need to patch the application to link to one or another. Or
> >> play with LDFLAGS...
> > 
> > That sounds intense...this would mean that one HW-layer (meta-fsl-arm)
> > tries to invent/enforce a new way of building application for
> > everybody(?)? Not sure this will thrive ;)
> 
> Well, the "right" way of deal with it is to have a library which loads
> the right backend libraries depending if you're running in X11 or not.
> Besides it is not new way but a explicit build flag ... not that bad.
> 
> >> >> > 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?
> >> 
> >> Your code is right the problem is the concurrent build as explained
> >> above.
> >> 
> >> >> > 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-linu
> >> >> > x-
> >> >> > 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)
> >> 
> >> Right; if I find the need time I will try to play with it as well.
> 
> Did you try the sdk?

A colleague did and said he has the same results is with the "normal" 
toolchain/sysroot.