[meta-freescale] [PATCH] xserver-common: Enable iglx module
Enable iglx module to pass indirect glx rendering test case. Signed-off-by: Neena Busireddy --- .../0016-xserver-common-enable-iglx-module.patch | 30 ++ .../xserver-common/xserver-common_%.bbappend | 10 2 files changed, 40 insertions(+) create mode 100644 recipes-graphics/xserver-common/xserver-common/imx/0016-xserver-common-enable-iglx-module.patch create mode 100644 recipes-graphics/xserver-common/xserver-common_%.bbappend diff --git a/recipes-graphics/xserver-common/xserver-common/imx/0016-xserver-common-enable-iglx-module.patch b/recipes-graphics/xserver-common/xserver-common/imx/0016-xserver-common-enable-iglx-module.patch new file mode 100644 index 000..283a081 --- /dev/null +++ b/recipes-graphics/xserver-common/xserver-common/imx/0016-xserver-common-enable-iglx-module.patch @@ -0,0 +1,30 @@ +From 8ad045e5e664fe2d1bd9f88616d5bf83437aab4e Mon Sep 17 00:00:00 2001 +From: Yang Dong +Date: Wed, 9 Sep 2015 13:08:57 +0800 +Subject: [PATCH] xserver-common: enable iglx module + +Enable iglx module to pass indirect glx rendering test case. + +Upstream-Status: Inappropriate [imx specific] + +Date: Sep 9, 2015 +Signed-off-by Yang Dong +--- + X11/xserver-common | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/X11/xserver-common b/X11/xserver-common +index 4dc48c4..d19b858 100644 +--- a/X11/xserver-common b/X11/xserver-common +@@ -44,6 +44,7 @@ SCREEN_SIZE=`fallback_screen_arg` + export USER=root + export XSERVER_DEFAULT_ORIENTATION=normal + ++INPUT_EXTRA_ARGS="+iglx" + ARGS="-br -pn -nolisten tcp $INPUT_EXTRA_ARGS" + DPI="100" + MOUSE="" +-- +1.9.1 + diff --git a/recipes-graphics/xserver-common/xserver-common_%.bbappend b/recipes-graphics/xserver-common/xserver-common_%.bbappend new file mode 100644 index 000..28d1f7b --- /dev/null +++ b/recipes-graphics/xserver-common/xserver-common_%.bbappend @@ -0,0 +1,10 @@ +# i.MX extra configuration +FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" + +PATCHES_IMX_SPECIFIC = " file://0016-xserver-common-enable-iglx-module.patch \ +" +SRC_URI_append = " \ +${PATCHES_IMX_SPECIFIC} \ +" +PACKAGE_ARCH_mx6 = "${MACHINE_SOCARCH}" +PACKAGE_ARCH_mx7 = "${MACHINE_SOCARCH}" -- 1.9.1 -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] imx-gpu-sdk do_install fails
If none of that helps, can you report back on the contents of the do_install log: /home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/work/armv7at2hf-neon-mx6qdl-fslc-linux-gnueabi/imx-gpu-sdk/2.3.2-r0/temp/log.do_install.15970 What is the actual error? Tom -Original Message- From: Tom Hochstein Sent: Thursday, January 12, 2017 1:19 PM To: 'Otavio Salvador' ; Stepan Salenikovich Cc: meta-freescale@yoctoproject.org Subject: RE: [meta-freescale] imx-gpu-sdk do_install fails Hi Stepan, I was not able to reproduce the problem. I have 3 things for you to try, in order: 1. Clean sstate [1] and rebuild: $ bitbake imx-gpu-sdk -c cleansstate 2. If that doesn't work, we do have a change internally which might at least fix the include file warnings. Please apply the attached patch and rebuild. 3. If that doesn't work, the other fear would be a missing dependency on imx-gpu-viv. Try building imx-gpu-viv separately and then rebuild your image: $ bitbake imx-gpu-viv Tom [1] http://lists.openembedded.org/pipermail/openembedded-core/2012-February/057250.html -Original Message- From: Otavio Salvador [mailto:otavio.salva...@ossystems.com.br] Sent: Thursday, January 12, 2017 7:21 AM To: Stepan Salenikovich ; Tom Hochstein Cc: meta-freescale@yoctoproject.org Subject: Re: [meta-freescale] imx-gpu-sdk do_install fails Hello Tom, could you take a look at this? On Wed, Jan 11, 2017 at 4:37 PM, Stepan Salenikovich wrote: > Hi, > I'm trying to build fsl-image-multimedia-full on current master > for the nitrogen6x with the distro set to fslc-wayland. > > The do_install for imx-gpu-sdk fails with the following error. > There are also many warnings before it about the include and library > paths being set to /usr/include and /usr/lib... so it seems there > is possibly a prefix missing somewhere causing the wrong header > to be included? > > eabi/imx-gpu-sdk/2.3.2-r0/imx-gpu-sdk-2.3.2/DemoFramework/FslBase/obj/Yocto/Release/libFslBase.a > -lIL -lEGL -lGLESv2 -lwayland-cursor -lwayland-client -lm -ldl > -Wl,--library-path=/usr/lib,-rpath-link=/usr/lib > | > /home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/sysroots/x86_64-linux/usr/libexec/arm-fslc-linux-gnueabi/gcc/arm-fslc-linux-gnueabi/6.3.0/ld: > warning: library search path "/usr/lib" is unsafe for cross-compilation > | Installed to: > /home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/work/armv7at2hf-neon-mx6qdl-fslc-linux-gnueabi/imx-gpu-sdk/2.3.2-r0/imx-gpu-sdk-2.3.2/bin/GLES3/E1_1_VBOs > | arm-fslc-linux-gnueabi-g++ -march=armv7-a -mthumb -mfpu=neon > -mfloat-abi=hard > --sysroot=/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/sysroots/nitrogen6x >-O2 -pipe -g -feliminate-unused-debug-types > -fdebug-prefix-map=/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/work/armv7at2hf-neon-mx6qdl-fslc-linux-gnueabi/imx-gpu-sdk/2.3.2-r0=/usr/src/debug/imx-gpu-sdk/2.3.2-r0 > > -fdebug-prefix-map=/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/sysroots/x86_64-linux= > > -fdebug-prefix-map=/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/sysroots/nitrogen6x= > -fvisibility-inlines-hidden -Wall -fPIC -DPIC -std=c++11 -g > -DFSL_ENABLE_GRAPHICS_ES3 -DEGL_API_WL -DEGL_API_FB -pthread > -DFSL_PLATFORM_YOCTO -fno-strict-aliasing -fno-optimize-sibling-calls > -DLINUX -I/usr/include -I/inc > -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/work/armv7at2hf-neon-mx6qdl-fslc-linux-gnueabi/imx-gpu-sdk/2.3.2-r0/imx-gpu-sdk- 2. > 3.2/DemoFramework/FslBase/include > -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/work/armv7at2hf-neon-mx6qdl-fslc-linux-gnueabi/imx-gpu-sdk/2.3.2-r0/imx-gpu-sdk-2.3.2/DemoFramework/FslDemoApp/include > > -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/work/armv7at2hf-neon-mx6qdl-fslc-linux-gnueabi/imx-gpu-sdk/2.3.2-r0/imx-gpu-sdk-2.3.2/DemoFramework/FslDemoAppGLES3/include > > -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/work/armv7at2hf-neon-mx6qdl-fslc-linux-gnueabi/imx-gpu-sdk/2.3.2-r0/imx-gpu-sdk-2.3.2/DemoFramework/FslGraphics/include > > -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/work/armv7at2hf-neon-mx6qdl-fslc-linux-gnueabi/imx-gpu-sdk/2.3.2-r0/imx-gpu-sdk-2.3.2/DemoFramework/FslGraphicsGLES3/include > > -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/sysroots/nitrogen6x/usr/include/glib-2.0 > > -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/sysroots/nitrogen6x/usr/incl ud > e/gstreamer-1.0 > -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/sysroots/nitrogen6x/usr/lib/glib-2.0/include > > -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/sysroots/nitrogen6x/usr/lib/gstreamer-1.0/include > -o obj/Yocto_Wayland/Release/source/DirectMultiSamplingVideoYUV.o -c > source/DirectMultiSamplingVideoYUV.cpp > | cc1plus: warning:
Re: [meta-freescale] [boundary-imx] Enquiry boundary-imx_4.1.15_1.0.0_ga kernel with egalax touch support on sabrelite
This should be fixed in the latest kernel. Waiting on patch to be accepted to update our morty blog post and images. You can update your builds independently to the latest revision here to see the fix: https://github.com/boundarydevices/linux-imx6/commits/boundary-imx_4.1.15_2.0.0_ga On Thu, Jan 12, 2017 at 5:14 AM, Gary Thomas wrote: > On 2017-01-12 14:09, Otavio Salvador wrote: > >> Hello, >> >> On Thu, Dec 29, 2016 at 5:42 AM, Shrikant Bobade >> wrote: >> >>> I used boundary-eval-image-nitrogen6x-krogoth-next.sdcard.gz >>> https://boundarydevices.com/krogoth-next-yocto-release/ on >>> imx6q-sabrelite >>> target along with 10Inch Hannstar LVDS Display connected. >>> >>> Observed the egalax touch is not working out of box. Does anyone else >>> faced >>> similar issue? >>> Is Hannstar LVDS display supported by default? >>> >> >> Do you mind to test with other test images? >> >> http://blink.ossystems.com.br/manufacturer/boundary >> >> Those uses new kernel and provides new boot scripts. It may provide a >> better result. Make sure to also use the latest production release for >> U-Boot provided by them. >> >> > Note that Ian (Boundary Devices) just sent some patches for what > seems to be this problem. It may be easier to just check against > those. > > -- > > Gary Thomas | Consulting for the > MLB Associates |Embedded world > > > -- > ___ > meta-freescale mailing list > meta-freescale@yoctoproject.org > https://lists.yoctoproject.org/listinfo/meta-freescale > -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] imx-gpu-sdk do_install fails
- On Jan 12, 2017, at 2:19 PM, Tom Hochstein tom.hochst...@nxp.com wrote: > Hi Stepan, > > I was not able to reproduce the problem. I have 3 things for you to try, in > order: > > 1. Clean sstate [1] and rebuild: > > $ bitbake imx-gpu-sdk -c cleansstate This worked. Thanks! FYI, I got the issue after building the image, and then doing a 'repo sync' to update everything and trying to build again... > > 2. If that doesn't work, we do have a change internally which might at least > fix > the include file warnings. Please apply the attached patch and rebuild. > > 3. If that doesn't work, the other fear would be a missing dependency on > imx-gpu-viv. Try building imx-gpu-viv separately and then rebuild your image: > > $ bitbake imx-gpu-viv > > Tom > > [1] > http://lists.openembedded.org/pipermail/openembedded-core/2012-February/057250.html > > -Original Message- > From: Otavio Salvador [mailto:otavio.salva...@ossystems.com.br] > Sent: Thursday, January 12, 2017 7:21 AM > To: Stepan Salenikovich ; Tom > Hochstein > Cc: meta-freescale@yoctoproject.org > Subject: Re: [meta-freescale] imx-gpu-sdk do_install fails > > Hello Tom, could you take a look at this? > > On Wed, Jan 11, 2017 at 4:37 PM, Stepan Salenikovich > wrote: >> Hi, >> I'm trying to build fsl-image-multimedia-full on current master >> for the nitrogen6x with the distro set to fslc-wayland. >> >> The do_install for imx-gpu-sdk fails with the following error. >> There are also many warnings before it about the include and library >> paths being set to /usr/include and /usr/lib... so it seems there >> is possibly a prefix missing somewhere causing the wrong header >> to be included? >> >> eabi/imx-gpu-sdk/2.3.2-r0/imx-gpu-sdk-2.3.2/DemoFramework/FslBase/obj/Yocto/Release/libFslBase.a >> -lIL -lEGL -lGLESv2 -lwayland-cursor -lwayland-client -lm -ldl >> -Wl,--library-path=/usr/lib,-rpath-link=/usr/lib >> | >> /home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/sysroots/x86_64-linux/usr/libexec/arm-fslc-linux-gnueabi/gcc/arm-fslc-linux-gnueabi/6.3.0/ld: >> | warning: library search path "/usr/lib" is unsafe for cross-compilation >> | Installed to: >> | >> /home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/work/armv7at2hf-neon-mx6qdl-fslc-linux-gnueabi/imx-gpu-sdk/2.3.2-r0/imx-gpu-sdk-2.3.2/bin/GLES3/E1_1_VBOs >> | arm-fslc-linux-gnueabi-g++ -march=armv7-a -mthumb -mfpu=neon >> -mfloat-abi=hard >> | >> --sysroot=/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/sysroots/nitrogen6x >> | -O2 -pipe -g -feliminate-unused-debug-types >> | >> -fdebug-prefix-map=/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/work/armv7at2hf-neon-mx6qdl-fslc-linux-gnueabi/imx-gpu-sdk/2.3.2-r0=/usr/src/debug/imx-gpu-sdk/2.3.2-r0 >> | >> -fdebug-prefix-map=/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/sysroots/x86_64-linux= >> | >> -fdebug-prefix-map=/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/sysroots/nitrogen6x= >> | -fvisibility-inlines-hidden -Wall -fPIC -DPIC -std=c++11 -g >> | -DFSL_ENABLE_GRAPHICS_ES3 -DEGL_API_WL -DEGL_API_FB -pthread >> | -DFSL_PLATFORM_YOCTO -fno-strict-aliasing -fno-optimize-sibling-calls >> -DLINUX >> | -I/usr/include -I/inc >> | >> -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/work/armv7at2hf-neon-mx6qdl-fslc-linux-gnueabi/imx-gpu-sdk/2.3.2-r0/imx-gpu-sdk-2. >> 3.2/DemoFramework/FslBase/include >> >> -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/work/armv7at2hf-neon-mx6qdl-fslc-linux-gnueabi/imx-gpu-sdk/2.3.2-r0/imx-gpu-sdk-2.3.2/DemoFramework/FslDemoApp/include >> >> -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/work/armv7at2hf-neon-mx6qdl-fslc-linux-gnueabi/imx-gpu-sdk/2.3.2-r0/imx-gpu-sdk-2.3.2/DemoFramework/FslDemoAppGLES3/include >> >> -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/work/armv7at2hf-neon-mx6qdl-fslc-linux-gnueabi/imx-gpu-sdk/2.3.2-r0/imx-gpu-sdk-2.3.2/DemoFramework/FslGraphics/include >> >> -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/work/armv7at2hf-neon-mx6qdl-fslc-linux-gnueabi/imx-gpu-sdk/2.3.2-r0/imx-gpu-sdk-2.3.2/DemoFramework/FslGraphicsGLES3/include >> >> -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/sysroots/nitrogen6x/usr/include/glib-2.0 >> >> -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/sysroots/nitrogen6x/usr/includ >> e/gstreamer-1.0 >> >> -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/sysroots/nitrogen6x/usr/lib/glib-2.0/include >> >> -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/sysroots/nitrogen6x/usr/lib/gstreamer-1.0/include >> -o obj/Yocto_Wayland/Release/source/DirectMultiSamplingVideoYUV.o -c >> source/DirectMultiSamplingVideoYUV.cpp >> | cc1plus: warning: include location "/usr/include" is unsafe for >> | cross-compilation [-Wpoison-system-directories] >> | source/DirectMultiSampli
Re: [meta-freescale] mfgtool-initramfs-image.bbclass conflict with other layers
On Thu, Jan 5, 2017 at 5:22 PM, Mirza Krak wrote: ... > Now looked at fsl-image-mfgtool-initramfs.bb and it does modify IMAGE_CLASSES. > > I changed the following line: > IMAGE_CLASSES = "image_types_uboot" > to > IMAGE_CLASSES += "image_types_uboot" > > And then everything is fine again, no parse error and it starts to build. ... and this is indeed the right fix. Please prepare a patch and send for us so we can apply it. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] imx-gpu-sdk do_install fails
Hi Stepan, I was not able to reproduce the problem. I have 3 things for you to try, in order: 1. Clean sstate [1] and rebuild: $ bitbake imx-gpu-sdk -c cleansstate 2. If that doesn't work, we do have a change internally which might at least fix the include file warnings. Please apply the attached patch and rebuild. 3. If that doesn't work, the other fear would be a missing dependency on imx-gpu-viv. Try building imx-gpu-viv separately and then rebuild your image: $ bitbake imx-gpu-viv Tom [1] http://lists.openembedded.org/pipermail/openembedded-core/2012-February/057250.html -Original Message- From: Otavio Salvador [mailto:otavio.salva...@ossystems.com.br] Sent: Thursday, January 12, 2017 7:21 AM To: Stepan Salenikovich ; Tom Hochstein Cc: meta-freescale@yoctoproject.org Subject: Re: [meta-freescale] imx-gpu-sdk do_install fails Hello Tom, could you take a look at this? On Wed, Jan 11, 2017 at 4:37 PM, Stepan Salenikovich wrote: > Hi, > I'm trying to build fsl-image-multimedia-full on current master > for the nitrogen6x with the distro set to fslc-wayland. > > The do_install for imx-gpu-sdk fails with the following error. > There are also many warnings before it about the include and library > paths being set to /usr/include and /usr/lib... so it seems there > is possibly a prefix missing somewhere causing the wrong header > to be included? > > eabi/imx-gpu-sdk/2.3.2-r0/imx-gpu-sdk-2.3.2/DemoFramework/FslBase/obj/Yocto/Release/libFslBase.a > -lIL -lEGL -lGLESv2 -lwayland-cursor -lwayland-client -lm -ldl > -Wl,--library-path=/usr/lib,-rpath-link=/usr/lib > | > /home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/sysroots/x86_64-linux/usr/libexec/arm-fslc-linux-gnueabi/gcc/arm-fslc-linux-gnueabi/6.3.0/ld: > warning: library search path "/usr/lib" is unsafe for cross-compilation > | Installed to: > /home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/work/armv7at2hf-neon-mx6qdl-fslc-linux-gnueabi/imx-gpu-sdk/2.3.2-r0/imx-gpu-sdk-2.3.2/bin/GLES3/E1_1_VBOs > | arm-fslc-linux-gnueabi-g++ -march=armv7-a -mthumb -mfpu=neon > -mfloat-abi=hard > --sysroot=/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/sysroots/nitrogen6x >-O2 -pipe -g -feliminate-unused-debug-types > -fdebug-prefix-map=/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/work/armv7at2hf-neon-mx6qdl-fslc-linux-gnueabi/imx-gpu-sdk/2.3.2-r0=/usr/src/debug/imx-gpu-sdk/2.3.2-r0 > > -fdebug-prefix-map=/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/sysroots/x86_64-linux= > > -fdebug-prefix-map=/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/sysroots/nitrogen6x= > -fvisibility-inlines-hidden -Wall -fPIC -DPIC -std=c++11 -g > -DFSL_ENABLE_GRAPHICS_ES3 -DEGL_API_WL -DEGL_API_FB -pthread > -DFSL_PLATFORM_YOCTO -fno-strict-aliasing -fno-optimize-sibling-calls > -DLINUX -I/usr/include -I/inc > -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/work/armv7at2hf-neon-mx6qdl-fslc-linux-gnueabi/imx-gpu-sdk/2.3.2-r0/imx-gpu-sdk-2. > 3.2/DemoFramework/FslBase/include > -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/work/armv7at2hf-neon-mx6qdl-fslc-linux-gnueabi/imx-gpu-sdk/2.3.2-r0/imx-gpu-sdk-2.3.2/DemoFramework/FslDemoApp/include > > -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/work/armv7at2hf-neon-mx6qdl-fslc-linux-gnueabi/imx-gpu-sdk/2.3.2-r0/imx-gpu-sdk-2.3.2/DemoFramework/FslDemoAppGLES3/include > > -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/work/armv7at2hf-neon-mx6qdl-fslc-linux-gnueabi/imx-gpu-sdk/2.3.2-r0/imx-gpu-sdk-2.3.2/DemoFramework/FslGraphics/include > > -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/work/armv7at2hf-neon-mx6qdl-fslc-linux-gnueabi/imx-gpu-sdk/2.3.2-r0/imx-gpu-sdk-2.3.2/DemoFramework/FslGraphicsGLES3/include > > -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/sysroots/nitrogen6x/usr/include/glib-2.0 > > -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/sysroots/nitrogen6x/usr/includ > e/gstreamer-1.0 > -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/sysroots/nitrogen6x/usr/lib/glib-2.0/include > > -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/sysroots/nitrogen6x/usr/lib/gstreamer-1.0/include > -o obj/Yocto_Wayland/Release/source/DirectMultiSamplingVideoYUV.o -c > source/DirectMultiSamplingVideoYUV.cpp > | cc1plus: warning: include location "/usr/include" is unsafe for > cross-compilation [-Wpoison-system-directories] > | source/DirectMultiSamplingVideoYUV.cpp: In member function 'virtual void > Fsl::DirectMultiSamplingVideoYUV::Draw()': > | source/DirectMultiSamplingVideoYUV.cpp:321:83: error: 'glTexDirectVIVMap' > was not declared in this scope > | glTexDirectVIVMap(GL_TEXTURE_2D, WIDTH, HEIGHT, GL_ALPHA, > &logical, &yAddr); > | >
Re: [meta-freescale] [Question] Using Linux 4.1.15 with wandboard (on krogoth)
Hi Fabio, Awesome, thanks so much for your help. On Mon, Jan 9, 2017 at 12:54 PM, Fabio Berton wrote: > Hi Amin, > > Linux-wandboard 4.1.15 is also available in morty release, if you can update > to this release. > > Other way, using krogoth release, is create a layer with > linux-wandboard_4.1.15.bb recipe, add this custom layer to your > bblayers.conf file and set PREFERRED_VERSION_virtual/kernel = "4.1.15" in > your local.conf. > > > On Sat, Jan 7, 2017 at 2:47 AM, Amin Bandali wrote: >> >> Hello, >> >> On the latest stable release (krogoth), the Linux kernel version used >> for wandboard is 3.14.28: >> >> https://github.com/Freescale/meta-freescale-3rdparty/blob/krogoth/recipes-kernel/linux/linux-wandboard_3.14.28.bb >> >> Would it be possible to use Linux 4.1.15 instead? >> >> https://github.com/Freescale/meta-freescale-3rdparty/blob/master/recipes-kernel/linux/linux-wandboard_4.1.15.bb >> >> If yes, I would really appreciate some help / directions on how to >> swap out 3.14.28 and use 4.1.15. >> >> Thanks, >> Amin >> -- >> ___ >> meta-freescale mailing list >> meta-freescale@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/meta-freescale > > -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [Question] IMAGE_FSTYPES has no effect on master
No problems. Done! On Mon, Jan 9, 2017 at 7:14 AM, Daiane Angolini wrote: > On Sat, Jan 7, 2017 at 2:08 AM, Amin Bandali wrote: >> Hello Daiane, >> >> Thanks for the reply, that indeed worked! It'd be nice to have this >> change merged upstream. > > Great! > > Can you, please, prepare the patch and send it to review? > > > Daiane >> >> Amin >> >> On Fri, Jan 6, 2017 at 10:30 AM, Daiane Angolini >> wrote: >>> On Thu, Jan 5, 2017 at 9:33 PM, Amin Bandali wrote: Hello, Up until krogoth, I could adjust IMAGE_FSTYPES in my local.conf to generate various types of archives: IMAGE_FSTYPES += "tar.bz2 tar.gz" However, I've noticed that this has no effect on master, and only wic.gz archives are generated. The only relevant piece of information I came across was the following commit: https://github.com/Freescale/meta-freescale-3rdparty/commit/038b0b737f55ebd2cbc29c91c8274fed422142d4 Any thoughts on how I could generate other image types on master, like I used to on krogoth? >>> >>> Please, try to change the code on >>> https://github.com/Freescale/meta-freescale-3rdparty/blob/master/conf/machine/wandboard.conf#L49 >>> >>> Instead of >>> IMAGE_FSTYPES = "wic.gz" >>> >>> use >>> >>> IMAGE_FSTYPES ?= "wic.gz" >>> >>> >>> Keep IMAGE_FSTYPES += "tar.bz2 tar.gz" in your local.conf, give it a >>> try and let us know. >>> >>> Daiane (I need a tar.gz or tar.bz2 so that I can un-tar them with sudo so that all the files and directories have correct permissions. Because the files and folders generated by bitbake in this directory {YOCTO_BUILD_DIR}/tmp/work/wandboard-poky-linux-gnueabi/{IMAGE}/1.0-r0/rootfs are owned by a regular user and when booting over NFS, those permissions cause trouble.) Thanks, Amin -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
[meta-freescale] [3rdparty][PATCH] wandboard: Use "IMAGE_FSTYPES ?=" for softer assignment
As it is, IMAGE_FSTYPES = "wic.gz" doesn't allow appending using "+=". So, use IMAGE_FSTYPES ?= "wic.gz" for providing the default value. Signed-off-by: Amin Bandali --- conf/machine/wandboard.conf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/conf/machine/wandboard.conf b/conf/machine/wandboard.conf index e82f1b4..14e0f21 100644 --- a/conf/machine/wandboard.conf +++ b/conf/machine/wandboard.conf @@ -46,4 +46,4 @@ WKS_FILES ?= "imx-uboot-spl.wks" IMAGE_DEPENDS_wic_append = " virtual/bootloader" -IMAGE_FSTYPES = "wic.gz" +IMAGE_FSTYPES ?= "wic.gz" -- 1.9.1 -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] eCSPI driver not loading
Hi Michael, could you please try moving the following part of your dts: pinctrl_ecspi1_1: ecspi1grp { fsl,pins = < MX6QDL_PAD_KEY_COL1__ECSPI1_MISO0x100b1 MX6QDL_PAD_KEY_ROW0__ECSPI1_MOSI0x100b1 MX6QDL_PAD_KEY_COL0__ECSPI1_SCLK0x100b1 MX6QDL_PAD_KEY_ROW1__GPIO4_IO09 0x8000 >; }; in the "iomuxc => imx6qdl-var-som-mx6" section, let's say just before the pinctrl_ecspi3_1 declaration? In case you are still failing the boot, could you please share a full boot log? Thanks BR Simon Dror On 12/01/2017 14:13, Otavio Salvador wrote: > Hello Michael, > > On Thu, Dec 22, 2016 at 8:07 PM, Michael Brainerd > wrote: >> need some help in getting eCSPI 1 driver loaded on iMX6Q processor on a >> Variscite DART-MX6. >> Attaching .config file. >> >> Boot log of the error: >> >> loop: module loaded >> spi_master spi0: cannot find modalias for >> /soc/aips-bus@0200/spba-bus@0200/ecspi@02008000/ecspi1grp >> spi_master spi0: Failed to create SPI device for >> /soc/aips-bus@0200/spba-bus@0200/ecspi@02008000/ecspi1grp >> spi_imx 2008000.ecspi: probed >> >> >> The following is what I put in the end of 'imx6qdl-var-dart.dtsi' file. >> >> &ecspi1 { >> fsl,spi-num-chipselects = <1>; >> cs-gpios = <&gpio4 9 0>; >> pinctrl-names = "default"; >> pinctrl-0 = <&pinctrl_ecspi1_1>; >> status = "okay"; >> >> chip1: spidev@0 { >>compatible = "spidev"; >>spi-max-frequency = <1200>; >>reg = <0>; >> }; >> /* >> chip2: spidev@1 { >>compatible = "spidev"; >>spi-max-frequency = <2000>; >>reg = <1>; >> }; >> */ >> pinctrl_ecspi1_1: ecspi1grp { >> fsl,pins = < >> MX6QDL_PAD_KEY_COL1__ECSPI1_MISO0x100b1 >> MX6QDL_PAD_KEY_ROW0__ECSPI1_MOSI0x100b1 >> MX6QDL_PAD_KEY_COL0__ECSPI1_SCLK0x100b1 >> MX6QDL_PAD_KEY_ROW1__GPIO4_IO09 0x8000 >> >; >> }; >> }; >> >> Can anyone help? > > I am adding Variscite people on Cc so they can provided some advice. -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] imx-gpu-sdk do_install fails
Yes, building now... -Original Message- From: Otavio Salvador [mailto:otavio.salva...@ossystems.com.br] Sent: Thursday, January 12, 2017 7:21 AM To: Stepan Salenikovich ; Tom Hochstein Cc: meta-freescale@yoctoproject.org Subject: Re: [meta-freescale] imx-gpu-sdk do_install fails Hello Tom, could you take a look at this? On Wed, Jan 11, 2017 at 4:37 PM, Stepan Salenikovich wrote: > Hi, > I'm trying to build fsl-image-multimedia-full on current master > for the nitrogen6x with the distro set to fslc-wayland. > > The do_install for imx-gpu-sdk fails with the following error. > There are also many warnings before it about the include and library > paths being set to /usr/include and /usr/lib... so it seems there > is possibly a prefix missing somewhere causing the wrong header > to be included? > > eabi/imx-gpu-sdk/2.3.2-r0/imx-gpu-sdk-2.3.2/DemoFramework/FslBase/obj/Yocto/Release/libFslBase.a > -lIL -lEGL -lGLESv2 -lwayland-cursor -lwayland-client -lm -ldl > -Wl,--library-path=/usr/lib,-rpath-link=/usr/lib > | > /home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/sysroots/x86_64-linux/usr/libexec/arm-fslc-linux-gnueabi/gcc/arm-fslc-linux-gnueabi/6.3.0/ld: > warning: library search path "/usr/lib" is unsafe for cross-compilation > | Installed to: > /home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/work/armv7at2hf-neon-mx6qdl-fslc-linux-gnueabi/imx-gpu-sdk/2.3.2-r0/imx-gpu-sdk-2.3.2/bin/GLES3/E1_1_VBOs > | arm-fslc-linux-gnueabi-g++ -march=armv7-a -mthumb -mfpu=neon > -mfloat-abi=hard > --sysroot=/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/sysroots/nitrogen6x >-O2 -pipe -g -feliminate-unused-debug-types > -fdebug-prefix-map=/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/work/armv7at2hf-neon-mx6qdl-fslc-linux-gnueabi/imx-gpu-sdk/2.3.2-r0=/usr/src/debug/imx-gpu-sdk/2.3.2-r0 > > -fdebug-prefix-map=/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/sysroots/x86_64-linux= > > -fdebug-prefix-map=/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/sysroots/nitrogen6x= > -fvisibility-inlines-hidden -Wall -fPIC -DPIC -std=c++11 -g > -DFSL_ENABLE_GRAPHICS_ES3 -DEGL_API_WL -DEGL_API_FB -pthread > -DFSL_PLATFORM_YOCTO -fno-strict-aliasing -fno-optimize-sibling-calls > -DLINUX -I/usr/include -I/inc > -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/work/armv7at2hf-neon-mx6qdl-fslc-linux-gnueabi/imx-gpu-sdk/2.3.2-r0/imx-gpu-sdk- 2. > 3.2/DemoFramework/FslBase/include > -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/work/armv7at2hf-neon-mx6qdl-fslc-linux-gnueabi/imx-gpu-sdk/2.3.2-r0/imx-gpu-sdk-2.3.2/DemoFramework/FslDemoApp/include > > -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/work/armv7at2hf-neon-mx6qdl-fslc-linux-gnueabi/imx-gpu-sdk/2.3.2-r0/imx-gpu-sdk-2.3.2/DemoFramework/FslDemoAppGLES3/include > > -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/work/armv7at2hf-neon-mx6qdl-fslc-linux-gnueabi/imx-gpu-sdk/2.3.2-r0/imx-gpu-sdk-2.3.2/DemoFramework/FslGraphics/include > > -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/work/armv7at2hf-neon-mx6qdl-fslc-linux-gnueabi/imx-gpu-sdk/2.3.2-r0/imx-gpu-sdk-2.3.2/DemoFramework/FslGraphicsGLES3/include > > -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/sysroots/nitrogen6x/usr/include/glib-2.0 > > -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/sysroots/nitrogen6x/usr/incl ud > e/gstreamer-1.0 > -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/sysroots/nitrogen6x/usr/lib/glib-2.0/include > > -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/sysroots/nitrogen6x/usr/lib/gstreamer-1.0/include > -o obj/Yocto_Wayland/Release/source/DirectMultiSamplingVideoYUV.o -c > source/DirectMultiSamplingVideoYUV.cpp > | cc1plus: warning: include location "/usr/include" is unsafe for > cross-compilation [-Wpoison-system-directories] > | source/DirectMultiSamplingVideoYUV.cpp: In member function 'virtual void > Fsl::DirectMultiSamplingVideoYUV::Draw()': > | source/DirectMultiSamplingVideoYUV.cpp:321:83: error: 'glTexDirectVIVMap' > was not declared in this scope > | glTexDirectVIVMap(GL_TEXTURE_2D, WIDTH, HEIGHT, GL_ALPHA, > &logical, &yAddr); > | >^ > | source/DirectMultiSamplingVideoYUV.cpp:322:47: error: > 'glTexDirectInvalidateVIV' was not declared in this scope > | glTexDirectInvalidateVIV(GL_TEXTURE_2D); > |^ > | GNUmakefile_Yocto:173: recipe for target > 'obj/Yocto_Wayland/Release/source/DirectMultiSamplingVideoYUV.o' failed > | make: *** [obj/Yocto_Wayland/Release/source/DirectMultiSamplingVideoYUV.o] > Error 1 > | WARNING: exit code 2 from a shell command. > | ERROR: Function failed: do_install (log file is located at > /home/ssaleni
Re: [meta-freescale] imx-gpu-sdk do_install fails
Hello Tom, could you take a look at this? On Wed, Jan 11, 2017 at 4:37 PM, Stepan Salenikovich wrote: > Hi, > I'm trying to build fsl-image-multimedia-full on current master > for the nitrogen6x with the distro set to fslc-wayland. > > The do_install for imx-gpu-sdk fails with the following error. > There are also many warnings before it about the include and library > paths being set to /usr/include and /usr/lib... so it seems there > is possibly a prefix missing somewhere causing the wrong header > to be included? > > eabi/imx-gpu-sdk/2.3.2-r0/imx-gpu-sdk-2.3.2/DemoFramework/FslBase/obj/Yocto/Release/libFslBase.a > -lIL -lEGL -lGLESv2 -lwayland-cursor -lwayland-client -lm -ldl > -Wl,--library-path=/usr/lib,-rpath-link=/usr/lib > | > /home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/sysroots/x86_64-linux/usr/libexec/arm-fslc-linux-gnueabi/gcc/arm-fslc-linux-gnueabi/6.3.0/ld: > warning: library search path "/usr/lib" is unsafe for cross-compilation > | Installed to: > /home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/work/armv7at2hf-neon-mx6qdl-fslc-linux-gnueabi/imx-gpu-sdk/2.3.2-r0/imx-gpu-sdk-2.3.2/bin/GLES3/E1_1_VBOs > | arm-fslc-linux-gnueabi-g++ -march=armv7-a -mthumb -mfpu=neon > -mfloat-abi=hard > --sysroot=/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/sysroots/nitrogen6x >-O2 -pipe -g -feliminate-unused-debug-types > -fdebug-prefix-map=/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/work/armv7at2hf-neon-mx6qdl-fslc-linux-gnueabi/imx-gpu-sdk/2.3.2-r0=/usr/src/debug/imx-gpu-sdk/2.3.2-r0 > > -fdebug-prefix-map=/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/sysroots/x86_64-linux= > > -fdebug-prefix-map=/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/sysroots/nitrogen6x= > -fvisibility-inlines-hidden -Wall -fPIC -DPIC -std=c++11 -g > -DFSL_ENABLE_GRAPHICS_ES3 -DEGL_API_WL -DEGL_API_FB -pthread > -DFSL_PLATFORM_YOCTO -fno-strict-aliasing -fno-optimize-sibling-calls > -DLINUX -I/usr/include -I/inc > -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/work/armv7at2hf-neon-mx6qdl-fslc-linux-gnueabi/imx-gpu-sdk/2.3.2-r0/imx-gpu-sdk- 2. > 3.2/DemoFramework/FslBase/include > -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/work/armv7at2hf-neon-mx6qdl-fslc-linux-gnueabi/imx-gpu-sdk/2.3.2-r0/imx-gpu-sdk-2.3.2/DemoFramework/FslDemoApp/include > > -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/work/armv7at2hf-neon-mx6qdl-fslc-linux-gnueabi/imx-gpu-sdk/2.3.2-r0/imx-gpu-sdk-2.3.2/DemoFramework/FslDemoAppGLES3/include > > -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/work/armv7at2hf-neon-mx6qdl-fslc-linux-gnueabi/imx-gpu-sdk/2.3.2-r0/imx-gpu-sdk-2.3.2/DemoFramework/FslGraphics/include > > -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/work/armv7at2hf-neon-mx6qdl-fslc-linux-gnueabi/imx-gpu-sdk/2.3.2-r0/imx-gpu-sdk-2.3.2/DemoFramework/FslGraphicsGLES3/include > > -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/sysroots/nitrogen6x/usr/include/glib-2.0 > > -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/sysroots/nitrogen6x/usr/incl ud > e/gstreamer-1.0 > -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/sysroots/nitrogen6x/usr/lib/glib-2.0/include > > -I/home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/sysroots/nitrogen6x/usr/lib/gstreamer-1.0/include > -o obj/Yocto_Wayland/Release/source/DirectMultiSamplingVideoYUV.o -c > source/DirectMultiSamplingVideoYUV.cpp > | cc1plus: warning: include location "/usr/include" is unsafe for > cross-compilation [-Wpoison-system-directories] > | source/DirectMultiSamplingVideoYUV.cpp: In member function 'virtual void > Fsl::DirectMultiSamplingVideoYUV::Draw()': > | source/DirectMultiSamplingVideoYUV.cpp:321:83: error: 'glTexDirectVIVMap' > was not declared in this scope > | glTexDirectVIVMap(GL_TEXTURE_2D, WIDTH, HEIGHT, GL_ALPHA, > &logical, &yAddr); > | >^ > | source/DirectMultiSamplingVideoYUV.cpp:322:47: error: > 'glTexDirectInvalidateVIV' was not declared in this scope > | glTexDirectInvalidateVIV(GL_TEXTURE_2D); > |^ > | GNUmakefile_Yocto:173: recipe for target > 'obj/Yocto_Wayland/Release/source/DirectMultiSamplingVideoYUV.o' failed > | make: *** [obj/Yocto_Wayland/Release/source/DirectMultiSamplingVideoYUV.o] > Error 1 > | WARNING: exit code 2 from a shell command. > | ERROR: Function failed: do_install (log file is located at > /home/ssalenikovich/projects/fsl-community-bsp-master/build/tmp/work/armv7at2hf-neon-mx6qdl-fslc-linux-gnueabi/imx-gpu-sdk/2.3.2-r0/temp/log.do_install.15970) > ERROR: Task > (/home/ssalenikovich/projects/fsl-community-bsp-master/sources/meta-freescale-distro/recipes-graphics/imx-gpu-sdk/imx-gpu-sdk_2.3.
Re: [meta-freescale] [GPU] gstreamer-imx G2D Plugins don't work on imx6q
On Wed, Jan 11, 2017 at 9:29 AM, Pierre-Olivier Huard wrote: > Hello, > > I'm trying to make G2D plugins from gstreamer-imx work with my imx6Q. I work > on Yocto, Fido branch, with 3.14.38 kernel. I use a module from Variscite, > the DART-MX6. My kernel is from Variscite Github > (https://github.com/varigit/linux-2.6-imx/tree/imx_3.14.38_6qp_ga_var01), > and my meta is based on the meta-variscite. > > The plugins are from https://github.com/Freescale/gstreamer-imx, I also > posted an issue (n°104) but I don't have any answer. > > When I try to run gst-launch-1.0 imxv4l2videosrc ! imxg2dvideosink I get the > following error : > > g2d_alloc: alloc memory fail with size 16! > ERROR: Pipeline doesn't want to pause. > Setting pipeline to NULL ... > Freeing pipeline .. > > With more debug : > > 0:00:00.540714000 425 0x549400 INFO imxphysmemallocator > phys_mem_allocator.c:62:gst_imx_phys_mem_allocator_init: > initializing physical memory allocator > g2d_alloc: alloc memory fail with size 16! > 0:00:00.556959667 425 0x549400 ERRORimxg2dallocator > allocator.c:59:gst_imx_g2d_alloc_phys_mem: could not > allocate 16 bytes of physical memory > 0:00:00.557108000 425 0x549400 WARN imxphysmemallocator > phys_mem_allocator.c:154:gst_imx_phys_mem_allocator_alloc: > could not allocate memory block with 16 bytes > 0:00:00.557213000 425 0x549400 WARN GST_BUFFER > gstbuffer.c:739:gst_buffer_new_allocate: failed to allocate 16 bytes > > I tried to change the CMA value, already to 320M, but I get the same error. > > a part of my kernel configuration : > > CONFIG_MXC_GPU_VIV=y > > CONFIG_CMA_SIZE_MBYTES=320 > CONFIG_CMA_SIZE_SEL_MBYTES=y > > CONFIG_CMA_ALIGNMENT=8 > CONFIG_CMA_AREAS=7 > > CONFIG_DMA_CMA=y > > CONFIG_DMA_SHARED_BUFFER=y > > I think it would be a kernel misconfiguration. It works on another iMX6 > (DualLite), with nearly the same meta, and a different kernel (3.14.28). Any > thougts about kernel missing configuration? Please try our kernel without meta-variscite and see if it works; or contact their support team. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] mfgtool-initramfs-image.bbclass conflict with other layers
2017-01-05 20:22 GMT+01:00 Mirza Krak : > Hi. > > My first post on this list, be gentle :). > > I am running morty branch and trying to build for "colibri-vf" target. > > Here is my setup: > meta > meta-poky > meta-yocto-bsp= "morty:5aa481dfedfd089f0d6e8a3bae1b84134d5dff4c" > meta-freescale= "morty:6ec09e6a0f09d1cb9c3761b339590c0a0baeeeb3" > meta-fsl-arm = "master:154ccf1e8b08e3d6219bd455b7dfe9ff7ab975b0" > meta-fsl-arm-extra = "morty:69ed94bb781a9c1bfbba4fb3026e4cbf3a194878" > meta-toradex-bsp-common = > "morty-next:ad286efa19257f83985f5f5844a2d500118e40ef" > meta-toradex-nxp = "morty-next:06d4bf9c8b936976d2469b50680a2bbb53cb6f54" > meta-mender-core = "master:10b22602b5a3a8615fcb58b55ae8191712365cf6" > oe-meta-go= "master:fbd51ce7e5acaf1ec298a384f1b3fb791ee7483a" > > And I am running in to a parse error but I can not determain which > layer is to blame. > > In meta-mender-core there is a file called mender-image.bbclass that > does following: > IMAGE_CLASSES += "mender-sdimg mender-artifactimg" > IMAGE_FSTYPES_append = " sdimg mender" > > But when I run "bitbake " I get the following error: > ERROR: > /home/mirzak/project/mender.io/ubifs-support/layers/meta-fsl-arm/recipes-fsl/images/fsl-image-mfgtool-initramfs.bb: > No IMAGE_CMD defined for IMAGE_FSTYPES entry 'mender' - possibly > invalid type name or missing support class > ERROR: > /home/mirzak/project/mender.io/ubifs-support/layers/meta-freescale/recipes-fsl/images/fsl-image-mfgtool-initramfs.bb: > No IMAGE_CMD defined for IMAGE_FSTYPES entry 'mender' - possibly > invalid type name or missing support class > ERROR: Failed to parse recipe: > /home/mirzak/project/mender.io/ubifs-support/layers/meta-fsl-arm/recipes-fsl/images/fsl-image-mfgtool-initramfs.bb > > Now looked at fsl-image-mfgtool-initramfs.bb and it does modify IMAGE_CLASSES. > > I changed the following line: > IMAGE_CLASSES = "image_types_uboot" > to > IMAGE_CLASSES += "image_types_uboot" > > And then everything is fine again, no parse error and it starts to build. > > I thought that this could be a layer priority issue but it seems that > it is in order for me. Pre-mature send. meta-mender-core = 6 and meta-freescale = 5. Any ides on what is to blame? Please let me know if you want me produce more debug output. Best Regards Mirza -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
[meta-freescale] mfgtool-initramfs-image.bbclass conflict with other layers
Hi. My first post on this list, be gentle :). I am running morty branch and trying to build for "colibri-vf" target. Here is my setup: meta meta-poky meta-yocto-bsp= "morty:5aa481dfedfd089f0d6e8a3bae1b84134d5dff4c" meta-freescale= "morty:6ec09e6a0f09d1cb9c3761b339590c0a0baeeeb3" meta-fsl-arm = "master:154ccf1e8b08e3d6219bd455b7dfe9ff7ab975b0" meta-fsl-arm-extra = "morty:69ed94bb781a9c1bfbba4fb3026e4cbf3a194878" meta-toradex-bsp-common = "morty-next:ad286efa19257f83985f5f5844a2d500118e40ef" meta-toradex-nxp = "morty-next:06d4bf9c8b936976d2469b50680a2bbb53cb6f54" meta-mender-core = "master:10b22602b5a3a8615fcb58b55ae8191712365cf6" oe-meta-go= "master:fbd51ce7e5acaf1ec298a384f1b3fb791ee7483a" And I am running in to a parse error but I can not determain which layer is to blame. In meta-mender-core there is a file called mender-image.bbclass that does following: IMAGE_CLASSES += "mender-sdimg mender-artifactimg" IMAGE_FSTYPES_append = " sdimg mender" But when I run "bitbake " I get the following error: ERROR: /home/mirzak/project/mender.io/ubifs-support/layers/meta-fsl-arm/recipes-fsl/images/fsl-image-mfgtool-initramfs.bb: No IMAGE_CMD defined for IMAGE_FSTYPES entry 'mender' - possibly invalid type name or missing support class ERROR: /home/mirzak/project/mender.io/ubifs-support/layers/meta-freescale/recipes-fsl/images/fsl-image-mfgtool-initramfs.bb: No IMAGE_CMD defined for IMAGE_FSTYPES entry 'mender' - possibly invalid type name or missing support class ERROR: Failed to parse recipe: /home/mirzak/project/mender.io/ubifs-support/layers/meta-fsl-arm/recipes-fsl/images/fsl-image-mfgtool-initramfs.bb Now looked at fsl-image-mfgtool-initramfs.bb and it does modify IMAGE_CLASSES. I changed the following line: IMAGE_CLASSES = "image_types_uboot" to IMAGE_CLASSES += "image_types_uboot" And then everything is fine again, no parse error and it starts to build. I thought that this could be a layer priority issue but it seems that it is in order for me. -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [boundary-imx] Enquiry boundary-imx_4.1.15_1.0.0_ga kernel with egalax touch support on sabrelite
On 2017-01-12 14:09, Otavio Salvador wrote: Hello, On Thu, Dec 29, 2016 at 5:42 AM, Shrikant Bobade wrote: I used boundary-eval-image-nitrogen6x-krogoth-next.sdcard.gz https://boundarydevices.com/krogoth-next-yocto-release/ on imx6q-sabrelite target along with 10Inch Hannstar LVDS Display connected. Observed the egalax touch is not working out of box. Does anyone else faced similar issue? Is Hannstar LVDS display supported by default? Do you mind to test with other test images? http://blink.ossystems.com.br/manufacturer/boundary Those uses new kernel and provides new boot scripts. It may provide a better result. Make sure to also use the latest production release for U-Boot provided by them. Note that Ian (Boundary Devices) just sent some patches for what seems to be this problem. It may be easier to just check against those. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] eCSPI driver not loading
Hello Michael, On Thu, Dec 22, 2016 at 8:07 PM, Michael Brainerd wrote: > need some help in getting eCSPI 1 driver loaded on iMX6Q processor on a > Variscite DART-MX6. > Attaching .config file. > > Boot log of the error: > > loop: module loaded > spi_master spi0: cannot find modalias for > /soc/aips-bus@0200/spba-bus@0200/ecspi@02008000/ecspi1grp > spi_master spi0: Failed to create SPI device for > /soc/aips-bus@0200/spba-bus@0200/ecspi@02008000/ecspi1grp > spi_imx 2008000.ecspi: probed > > > The following is what I put in the end of 'imx6qdl-var-dart.dtsi' file. > > &ecspi1 { > fsl,spi-num-chipselects = <1>; > cs-gpios = <&gpio4 9 0>; > pinctrl-names = "default"; > pinctrl-0 = <&pinctrl_ecspi1_1>; > status = "okay"; > > chip1: spidev@0 { >compatible = "spidev"; >spi-max-frequency = <1200>; >reg = <0>; > }; > /* > chip2: spidev@1 { >compatible = "spidev"; >spi-max-frequency = <2000>; >reg = <1>; > }; > */ > pinctrl_ecspi1_1: ecspi1grp { > fsl,pins = < > MX6QDL_PAD_KEY_COL1__ECSPI1_MISO0x100b1 > MX6QDL_PAD_KEY_ROW0__ECSPI1_MOSI0x100b1 > MX6QDL_PAD_KEY_COL0__ECSPI1_SCLK0x100b1 > MX6QDL_PAD_KEY_ROW1__GPIO4_IO09 0x8000 > >; > }; > }; > > Can anyone help? I am adding Variscite people on Cc so they can provided some advice. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [boundary-imx] Enquiry boundary-imx_4.1.15_1.0.0_ga kernel with egalax touch support on sabrelite
Hello, On Thu, Dec 29, 2016 at 5:42 AM, Shrikant Bobade wrote: > I used boundary-eval-image-nitrogen6x-krogoth-next.sdcard.gz > https://boundarydevices.com/krogoth-next-yocto-release/ on imx6q-sabrelite > target along with 10Inch Hannstar LVDS Display connected. > > Observed the egalax touch is not working out of box. Does anyone else faced > similar issue? > Is Hannstar LVDS display supported by default? Do you mind to test with other test images? http://blink.ossystems.com.br/manufacturer/boundary Those uses new kernel and provides new boot scripts. It may provide a better result. Make sure to also use the latest production release for U-Boot provided by them. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale