On Tue, Feb 12, 2013 at 3:37 PM, Otavio Salvador <[email protected]> wrote: > On Tue, Feb 12, 2013 at 10:54 AM, Thomas Senyk > <[email protected]> wrote: >> Hi, >> >> I tried the patch-set today and had several issues/problems. >> Some (most?) of them are due to my own limited knowledge or my unusual setup. > > This patchset is driving me crazy so don't worry ;-) > >> This time I applied all patches of the patch-set :) >> ... but not the upstream openembedded-core patches as I'm building without >> X11, if this is in anyway a potential cause of errors: please let me know. >> (How do I find the right openembbeded patches if I'm not on their mailing- >> list? .. I guess I should be? ;) > > You might use patchwork http://patches.openembedded.org/project/oe-core/list
Sent it too soon ... but patchwork is not updated so it is a nightmare to find the patches. >> 1. Generally importing patch-set from mailing-lists. >> >> How do you do this? For me it's always troublesome and error-prone to >> manually >> copy the patches from mail to files and apply them >> ... I'm sure there must be a better way of doing it? It is horrible indeed. I save them using e-mail and it is boring to do... but it is how we can do for now. I asked OE people to setup a patchwork for us, so it'll be easier. >> 2. >> recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q/0001-change-header-path- >> to-HAL.patch >> didn't apply anymore for me with following error: Yes; the patch were send based on 12.09.01; I did update it here ... will resend. >> NOTE: Applying patch '0001-change-header-path-to-HAL.patch' (../sources/meta- >> fsl-arm/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q/0001-change-header- >> path-to-HAL.patch) >> ERROR: Command Error: exit status: 1 Output: >> Applying patch 0001-change-header-path-to-HAL.patch >> patching file usr/include/gc_vdk_types.h >> Hunk #1 FAILED at 26. >> 1 out of 1 hunk FAILED -- rejects in file usr/include/gc_vdk_types.h >> Patch 0001-change-header-path-to-HAL.patch does not apply (enforce with -f) >> >> >> I changed the patch to: >> --#include "gc_hal_eglplatform.h" >> -+#include <HAL/gc_hal_eglplatform.h> >> +-#include "gc_hal_eglplatform_type.h" >> ++#include <HAL/gc_hal_eglplatform_type.h> >> >> ... now it's building, but not sure if this was the right modification? I think so; same as I did. >> 3. I got a different md5-hash for gc_vdk.h >> I got a LIC_FILS_CHKSUM error pointing me to another hash. >> I could verify this by manually running/extracting gpu-viv-bin-mx6q-1.1.0.bin >> and doing: >> .../gpu-viv-bin-mx6q-1.1.0/usr/include/ head -11 gc_vdk.h|md5sum >> c831981a5cbb2673318b77fb2f07014c - Same here. >> ... I do get the felling I got a different version of the drivers then the >> rest of the people :D but it does look right: >> >> .../oe-yocto/fsl-community-bsp/downloads/ sha1sum gpu-viv-bin-mx6q-1.1.0.bin >> e17d9fc743245fc270309903f5863b480ab08e71 gpu-viv-bin-mx6q-1.1.0.bin >> >> .../temp/ wget >> http://download.ossystems.com.br/bsp/freescale/source/gpu-viv-bin-mx6q-1.1.0.bin >> .../temp/ sha1sum gpu-viv-bin-mx6q-1.1.0.bin >> e17d9fc743245fc270309903f5863b480ab08e71 gpu-viv-bin-mx6q-1.1.0.bin it has changed indeed. >> 4. I build without X11 in DISTRO_FEATURES >> ... never the less I get: >> root@imx6qsabrelite:/usr/lib# ls libGAL* libEGL* -alh >> -rw-r--r-- 1 root root 83.8K Feb 12 10:00 libEGL-x11.so >> lrwxrwxrwx 1 root root 13 Feb 12 11:22 libEGL.so -> libEGL- >> x11.so >> -rw-r--r-- 1 root root 807.1K Feb 12 10:00 libGAL-x11.so >> lrwxrwxrwx 1 root root 13 Feb 12 11:22 libGAL.so -> libGAL- >> x11.so >> >> >> their is a patch for that which never got "rebased & resend": >> http://permalink.gmane.org/gmane.linux.embedded.yocto.meta-freescale/1160 >> >> ... he might just wait for 'patch v3' to land I have it locally as well ... I will send a v3 tomorrow with all this. >> 5. A similar problem within to sysroot, >> Their is no libEGL.so anymore (same for libGAL.so) >> ... so far Qt always linked against those. >> >> The above mentioned patch takes care about this as well by rm *-x11.so and >> letting the default symlinks (libEGL.so -> libEGL-fb.so) as they are >> ...for the not-x11 case (the x11 solution looks strange though). We need to get recipes to link explicitly to fb or x11 backends or we'll be in a nightmare. We need to patch Qt Embedded to use the fb one. >> >> 6. uname -a >> Linux imx6qsabrelite 3.0.35-1.1.0+yocto+gc27cb38 #1 SMP PREEMPT Mon Feb 11 >> 17:07:57 CET 2013 armv7l GNU/Linux >> >> Their is a patch-set for switching to a newer 3.7 based kernel. >> Can anyone clarify about the different kernels, how and why/why not switch? >> ... should 3.7 be default or is 3.0.35 the right one for now? 3.7 is for people wishing to use mainline but it lacks many features so I think you need 3.0.35 for now. >> 7. I still got the shader errors: >> vertex shader compilation error: >> fragment shader compilation error: >> program link error: No vertex shader attached. >> >> ... those might be caused by one of the errors/mistakes above? I hope not. How do you get this errors? So I might give it a try here. -- Otavio Salvador O.S. Systems E-mail: [email protected] http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br _______________________________________________ meta-freescale mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-freescale
