Re: [meta-freescale] [meta-fsl-arm] Memory leak in graphic application (dora)
Hi Vincent, Sorry, but I can’t really advise as I’m not familiar with those drivers. Chris > On 1 May 2017, at 11:00, Vincent DEHORS <vincent.deh...@smile.fr> wrote: > > Hi, > > I am not using the Intel driver but the Vivante one packaged by these recipes > : > > https://github.com/Freescale/meta-fsl-arm/tree/dora/recipes-graphics > <https://github.com/Freescale/meta-fsl-arm/tree/dora/recipes-graphics> > Do you think I can use another version of gpu-viv-bin-mx6q and > xf86-video-imxfb keeping my 3.0.35 kernel ? > > Regards, > > Vincent > > > > Le 2017-04-28 11:52, Chris Tapp a écrit : > >> Hi Vincent, >> >> I saw something similar to this a while back with Fido when using the Intel >> video driver (Thread “"Crazy" Xorg memory usage after upgrading from Daisy >> to Fido”). >> >> My app would often get killed due to lack of memory, but it sometimes ran >> long enough that a load of memory was released back to the pool and the app >> would then run as long as I left it running. >> >> My fix was: >> >> The undesirable memory usage within Xorg isn’t there if I create an >> xorg.conf file containing: >> >> Section “Device” >> Identifier “Intel Video” >> Driver “intel” >> Option “TearFree” “true" >> EndSection >> >> So it looks as if I need to enable “TearFree”. I didn’t need to add this for >> the 2.99.910 version of xf86-video-intel included with ‘daisy’. >> >> This probably won’t work for you, but it may be worth a try. >> >> Chris >> >>> On 28 Apr 2017, at 10:21, Vincent DEHORS <vincent.deh...@smile.fr >>> <mailto:vincent.deh...@smile.fr>> wrote: >>> >>> Hi, >>> >>> I use a dora branch (as constructor only provides a 3.0.35 kernel) and when >>> I launch any graphical application using libGLES2 (with X11), the memory >>> increase continuously until there is no memory left (and oom-killer kill >>> the app). >>> >>> I can see the leak with a minimalist Qt5/qml application with an animation >>> or with a Gstreamer pipeline using eglvivsink. >>> >>> Is there any known issue with graphic application in old BSP for i.MX6 ? >>> >>> If the leak is located in the proprietary libGL, is there a way to use a >>> more recent one without upgrading the kernel version ? >>> >>> Regards, >>> >>> Vincent >>> >>> >>> -- >>> ___ >>> meta-freescale mailing list >>> meta-freescale@yoctoproject.org <mailto:meta-freescale@yoctoproject.org> >>> https://lists.yoctoproject.org/listinfo/meta-freescale >> >> -- >> >> Chris Tapp >> opensou...@keylevel.com <mailto:opensou...@keylevel.com> >> www.keylevel.com <http://www.keylevel.com/> >> >> >> You can tell you're getting older when your car insurance gets real cheap! -- Chris Tapp opensou...@keylevel.com www.keylevel.com You can tell you're getting older when your car insurance gets real cheap! -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [meta-fsl-arm] Memory leak in graphic application (dora)
Hi Vincent, I saw something similar to this a while back with Fido when using the Intel video driver (Thread “"Crazy" Xorg memory usage after upgrading from Daisy to Fido”). My app would often get killed due to lack of memory, but it sometimes ran long enough that a load of memory was released back to the pool and the app would then run as long as I left it running. My fix was: The undesirable memory usage within Xorg isn’t there if I create an xorg.conf file containing: Section “Device” Identifier “Intel Video” Driver “intel” Option “TearFree” “true" EndSection So it looks as if I need to enable “TearFree”. I didn’t need to add this for the 2.99.910 version of xf86-video-intel included with ‘daisy’. This probably won’t work for you, but it may be worth a try. Chris > On 28 Apr 2017, at 10:21, Vincent DEHORS <vincent.deh...@smile.fr> wrote: > > Hi, > > I use a dora branch (as constructor only provides a 3.0.35 kernel) and when I > launch any graphical application using libGLES2 (with X11), the memory > increase continuously until there is no memory left (and oom-killer kill the > app). > > I can see the leak with a minimalist Qt5/qml application with an animation or > with a Gstreamer pipeline using eglvivsink. > > Is there any known issue with graphic application in old BSP for i.MX6 ? > > If the leak is located in the proprietary libGL, is there a way to use a more > recent one without upgrading the kernel version ? > > Regards, > > Vincent > > > -- > ___ > meta-freescale mailing list > meta-freescale@yoctoproject.org > https://lists.yoctoproject.org/listinfo/meta-freescale -- Chris Tapp opensou...@keylevel.com www.keylevel.com You can tell you're getting older when your car insurance gets real cheap! -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] Which GStreamer version is preferred?
On 3 Mar 2015, at 10:40, Isaac Nickaein nickaei...@gmail.com wrote: Hi, There are two recipes for installing gstreamer: One called gstreamer which apparently is based on GStreamer 0.1 and other one is gstreamer1.0 is based on GStreamer 1.0. Which one is more stable and suitable for using in production? It’s probably worth considering that 0.10 is no longer supported (and hasn’t been for a couple of years). In my experience 1.0 is much more capable and has quite a lot of powerful new features. Also, I am building the kernel based on the kernel source provided by the Ka-Ro http://www.karo-electronics.com/. What are considerations that should be taken in building kernel so that the Gstreamer benefit the VPU of iMX.6Q? Bests, Isaac -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale -- Chris Tapp opensou...@keylevel.com www.keylevel.com You can tell you're getting older when your car insurance gets real cheap! -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] save kernel configuration
Hi Mat, On 27 Nov 2014, at 07:46, matthias.he...@atlas-elektronik.com matthias.he...@atlas-elektronik.com wrote: Hi there, when I’m turning options on and off in menuconfig these changes are usually saved in the .config file, which resides (in my case)in /build/tmp/work/wandboard_quad-poky-linux-gnueabi/linux-wandboardd/3.10.17-r0/git , right ? As this configuration is obviously downloaded from git, I’ve got a few questions: 1. Is this configuration integral part of (in this case) the linux-wandboard-3.10.17, so if I change the configuration the version must be changed ? 2. Which purpose does the defconfig file in /sources/meta-fsl-arm-extra/recipes-kernel/linux/linux-wandboard-3.10.17 have ? 3. Or is the defconfig file copied, changed by recipe (linux-wandboard_3.10.17.bb, f.e. LOCALVERSION ) and if I change something and want to include this into the image recipe I copy the tweaked .config file into a new defconfig ? Or how would be the procedure ? 1. The version number is simply the kernel version that is being used - configuration just selects which features are exposed; 2. The defconfig is the default configuration that will be used as the .config when the kernel is built for the wandboard; 3. Any kernel changes that are requested else where (e.g. configuration fragments, below) modify what is in .config before the build takes place. Any changes you make using menuconfig will be lost as they are stored in the work area. If you want to be able to reapply changes you probably want to look at using configuration fragments. I would start by reading the section Creating Configuration Fragments in the documentation (www.yoctoproject.org/docs/1.7/mega-manual/mega-manual.html). Configuration fragments are much easier to manage and will apply to any kernel version that supports the option(s). -- Chris Tapp opensou...@keylevel.com www.keylevel.com You can tell you're getting older when your car insurance gets real cheap! -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [PATCH 0/1] arm: imx: fsl_otp: make fuses (OTP memory) read-only
On 8 Nov 2014, at 02:03, Nikolay Dimitrov picmas...@mail.bg wrote: Hi Alexander, The driver allows to be enabled/disabled by a configuration option, so it's a responsibility of your engineering team to properly configure the software for development, manufacturing and production purposes, as there's no one size fits all solution for this option. And I think it would be a unwise decision just to cripple the driver because there is potential for misuse the driver. If so, we have to disable also all device files and sysfs entries that allow raw access to physical memory, physical disks, cpu frequency, thermal device, power supply voltages, as all of these can screw-up the product (either by deleting data or by frying a component on the board). And we have to forbid kitchen knives :). I like Eric's idea with sysfs unlock entry. It's also possible to have different sysfs read and write files' permissions, to provide privilege separation. I also understand your confusion of the answers received on LKML and here, but you should already know that each FOSS tribe has its own customs. What's good for the kernel itself doesn't make it instantly good for actual systems/product integration, so it's normal to have groups with different goals to react differently on the same topic. As has already been mentioned, it is the responsibility of a project to ensure that any product is suitably protected. I can image a customer would be really unhappy if their system (e.g. Smart TV) could be destroyed by a bit of malware ! -- Chris Tapp opensou...@keylevel.com www.keylevel.com You can tell you're getting older when your car insurance gets real cheap! -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] Utilite?
On 29 Apr 2014, at 18:21, Otavio Salvador ota...@ossystems.com.br wrote: On Tue, Apr 29, 2014 at 9:44 AM, randy.krak...@freescale.com randy.krak...@freescale.com wrote: Has anyone built 3.10.17 images with gstreamer 1.0 for Utilite? Utility has not been send for inclusion in FSL Community BSP so I think most people are not using/aware of it. It's a platform that I've been meaning to find time to evaluate. Spec is similar to the Wandboards, but in a product-ready format. I'm guessing it shouldn't be too difficult to get it running? Chris Tapp opensou...@keylevel.com www.keylevel.com -- ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] Wandboard Quad experience (good!)
Hi John, On 14 Jul 2013, at 20:38, John Weber wrote: Hi Chris, Thanks. You've probably noticed, but this is a different error from the first one you sent. The first one was in the Vivante driver. Yes, I had spotted it was different... This one seems related to a memory limitation and perhaps related to the CONFIG_SWAP being on by default in the kernel build. Since there is no swap partition, having CONFIG_SWAP seems a little useless. Oddly enough, all of the default i.MX6 defconfigs set CONFIG_SWAP. I'm seeing if we can remove that option. but I had no idea it was related to swap ;-) I'll disable locally and see if that makes a difference. I can't see why swap should be getting used as the app never uses anywhere near the 2GB the board has, but I've see linux hit swap when there still seems to be plenty of physical memory about, so this may be expected. It is just possible that this may be related to the other issue, as I can imagine a gstreamer-heavy app does a lot of memory allocation/deallocation... John On 7/13/13 4:26 PM, Chris Tapp wrote: Hi John, On 13 Jul 2013, at 01:07, John Weber wrote: Chris, This looks like it is coming from the Vivante GPU driver in: drivers/mxc/gpu-viv/hal/kernel/gc_hal_kernel.c, line 1315. How would I replicate this problem? Good question! Simply running (with GST_DEBUG=*:2) gst-launch playbin2 uri=http://media.w3.org/2010/05/sintel/trailer.webm video-sink=queue2 ! mfw_v4lsink sometimes gives this: [ 2445.396718] source:src: page allocation failure: order:11, mode:0xd1 [ 2445.403170] Backtrace: [ 2445.405710] [c003e358] (dump_backtrace+0x0/0x104) from [c0421760] (dump_stack+0x18/0x1c) [ 2445.414222] r6:e9b8 r5:00d1 r4:0001 r3: [ 2445.420029] [c0421748] (dump_stack+0x0/0x1c) from [c00b7be8] (warn_alloc_failed+0xe4/0x104) [ 2445.428825] [c00b7b04] (warn_alloc_failed+0x0/0x104) from [c00ba12c] (__alloc_pages_nodemask+0x5b8/0x634) [ 2445.438806] r3: r2: [ 2445.442482] r8: r7: r6:e9b8 r5:000b r4:00d1 [ 2445.449342] [c00b9b74] (__alloc_pages_nodemask+0x0/0x634) from [c004400c] (__dma_alloc+0xc4/0x2b0) [ 2445.458728] [c0043f48] (__dma_alloc+0x0/0x2b0) from [c0044550] (dma_alloc_coherent+0x5c/0x68) [ 2445.467695] [c00444f4] (dma_alloc_coherent+0x0/0x68) from [c02f693c] (vpu_alloc_dma_buffer+0x34/0x5c) [ 2445.477323] r7:e9b8 r6:e9cb6f28 r5:e9cb6f20 r4:e9cb6f28 [ 2445.483422] [c02f6908] (vpu_alloc_dma_buffer+0x0/0x5c) from [c02f6a38] (vpu_ioctl+0xd4/0x7ac) [ 2445.492366] r4:41efe940 r3: [ 2445.496042] [c02f6964] (vpu_ioctl+0x0/0x7ac) from [c00f144c] (vfs_ioctl+0x28/0x44) [ 2445.504025] r8:e9b468d0 r7:0007 r6:5600 r5:e9b667a0 r4:e9b667a0 [ 2445.510888] [c00f1424] (vfs_ioctl+0x0/0x44) from [c00f1e78] (do_vfs_ioctl+0x414/0x508) [ 2445.519167] [c00f1a64] (do_vfs_ioctl+0x0/0x508) from [c00f1fa8] (sys_ioctl+0x3c/0x68) [ 2445.527381] [c00f1f6c] (sys_ioctl+0x0/0x68) from [c003ac00] (ret_fast_syscall+0x0/0x30) [ 2445.535753] r7:0036 r6:415c11ac r5:420762a8 r4:41efe940 [ 2445.541491] Mem-info: [ 2445.543770] DMA per-cpu: [ 2445.546309] CPU0: hi: 90, btch: 15 usd: 84 [ 2445.551119] CPU1: hi: 90, btch: 15 usd: 84 [ 2445.555918] CPU2: hi: 90, btch: 15 usd: 0 [ 2445.560733] CPU3: hi: 90, btch: 15 usd: 98 [ 2445.565529] Normal per-cpu: [ 2445.568330] CPU0: hi: 90, btch: 15 usd: 80 [ 2445.573146] CPU1: hi: 90, btch: 15 usd: 66 [ 2445.577944] CPU2: hi: 90, btch: 15 usd: 77 [ 2445.582757] CPU3: hi: 90, btch: 15 usd: 19 [ 2445.587553] HighMem per-cpu: [ 2445.590455] CPU0: hi: 186, btch: 31 usd: 16 [ 2445.595254] CPU1: hi: 186, btch: 31 usd: 37 [ 2445.600052] CPU2: hi: 186, btch: 31 usd: 172 [ 2445.604863] CPU3: hi: 186, btch: 31 usd: 181 [ 2445.609675] active_anon:1321 inactive_anon:19 isolated_anon:0 [ 2445.609680] active_file:2311 inactive_file:2276 isolated_file:0 [ 2445.609686] unevictable:0 dirty:1 writeback:0 unstable:0 [ 2445.609690] free:456985 slab_reclaimable:305 slab_unreclaimable:1705 [ 2445.609696] mapped:1837 shmem:43 pagetables:153 bounce:0 [ 2445.638709] DMA free:48392kB min:1052kB low:1312kB high:1576kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:186944kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes [ 2445.675225] lowmem_reserve[]: 0 308 1673 1673 [ 2445.679676] Normal free:392244kB min:1776kB low:2220kB high:2664kB active_anon:0kB inactive_anon:0kB active_file:2036kB inactive_file:1676kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:315584kB mlocked:0kB dirty:4kB writeback:0kB mapped
[meta-freescale] Wandboard uBoot clock
When the Wandboard Quad starts, uBoot reports that the CPU is running at 792 MHz. The Quad is a 1 GHz board, so should this be higher or does it somehow get switched later on? Chris Tapp opensou...@keylevel.com www.keylevel.com ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] Gstreamer pipeline problem
On 15 Jul 2013, at 09:24, Thomas Senyk wrote: On Friday, 12 July, 2013 17:35:01 Chris Tapp wrote: Hi Thomas, Some more info below: On 11 Jul 2013, at 09:39, Thomas Senyk wrote: On Wednesday, 10 July, 2013 20:53:58 Chris Tapp wrote: On 10 Jul 2013, at 20:19, Chris Tapp wrote: I've got an application which uses playbin2 to capture video. The pipeline is of the form: playbin2 uri=... video-sink=queue2 ! videoscale ! video/x-raw-rgb, pixel-aspect-ratio=1/1, width=capture-width, height=capture-height ! fakesink I then get the frame property from the pipeline and use this to grab the latest frame. This works on my development system (Ubuntu 11.10) and a Cedar Trail / Yocto system, but the pipeline fails on the Wandboard Quad. I think this is related to: 0:00:13.028151336 1349 0x4442d520 WARN basetransform /media/SSD-RAID/build-danny-wandboard/tmp/work/armv7a-vfp-neon-poky-linu x -gnueabi/gstreamer/0.10.36-r2/gstreamer-0.10.36/libs/gst/base/gstbasetra ns form.c:1304:gst_base_transform_setcaps:videoscale0x2ab820 transform could not transform video/x-raw-yuv, width=(int)854, height=(int)480, framerate=(fraction)24/1, format=(fourcc)I420, interlaced=(boolean)false in anything we support I added an ffmpegcolorspace element betwween the queue2 and the videoscale to get round this and the pipeline now builds, but only a few frames are captured. There are different diagnostics showing: 0:00:02.881403000 1361 0x28da60 WARN vpudec vpudec.c:914:gst_vpudec_core_create_and_register_frames: Allocate Internal framebuffers Message Callback : Element playbin0x250b68 changed state from READY to PAUSED. 0:00:03.237675000 1361 0x28da60 WARN vpudec vpudec.c:1578:gst_vpudec_chain: Got no frame buffer message, return 0x89, 8 frames in displaying queue!! 0:00:03.242324334 1361 0x28da60 WARN vpudec vpudec.c:1578:gst_vpudec_chain: Got no frame buffer message, return 0x89, 8 frames in displaying queue!! lots of repeats 0:00:08.499914334 1382 0x28d860 WARN vpudec vpudec.c:1655:gst_vpudec_chain: Retry too many times, maybe BUG!! 0:00:08.500784667 1382 0x28d860 WARN vpudec vpudec.c:1578:gst_vpudec_chain: Got no frame buffer message, return 0x88, 8 frames in displaying queue!! lots of repeats Message Callback : Element playbin0x250aa0 changed state from PAUSED to PLAYING. 0:00:09.253202667 1382 0x28d860 WARN vpudec vpudec.c:1578:gst_vpudec_chain: Got no frame buffer message, return 0x88, 8 frames in displaying queue!! 0:00:13.364523335 1460 0x142ec0 WARN mfw_v4lsink mfw_gst_v4l_buffer.c:435:mfw_gst_v4l2_new_buffer: Try new buffer failed, ret 2 No such file or directory queued 0 The Message Callback events are my own logging to try and see what's happening in my app. Is this something I'm doing wrong, or are these messages a real issue somewhere? This is when playing a .webm. The results for an .flv are as expected. is it the same when you use v4l2 sink instead of fakesink? Is playbin (without defining the pipeline) behaving the same? I've run some tests using pipelines of the form: gst-launch playbin2=file://trailer.webm video-sink=a-sink-to-test GST_DEBUG was set to *:2 1) When the sink is set to mfw_4vlsink I get full screen video playback; 2) When the sink is set to fakesink I get nothing on the screen (as expected), and no debug of interest; 3) When the sink is set to queue2 ! mfw_4vlsink I get very choppy full screen video playback (which eventually stalls) and debug output as originally reported; 4) When the sink is set to queue2 ! fakesink I get nothing on the screen (as expected), and no debug of interest; 5) When the sink is set to queue2 ! fakesink sync=1 I get nothing on the screen and debug output as originally reported. These were all run from the command line, no 'X' running. It looks like queue2 + sync=1 (default for v4lsink) combination causes the problem... Setting sync=0 for v4lsink makes no difference and looks to be ignored. Do you actually need queue2 or sync=1? Your end goal is to get everything into your opengl context and render it, right? Shouldn't you be good with setting up a minimal gstreamer pipeline and let gstreamer handle the rest? I normally run a basic playbin2 pipeline to 'fakesink'. When it's time to render I grab the latest frame via playbin2, upload this into a texture and render. I seem to need queue2 on the video-sink and audio-sink to keep them in sync. Video sinks generally set sync=1 by default, but fakesink doesn't. If this isn't set, then the video plays too fast and loses sync with the audio. Don't get me wrong. I'm not an gstreamer expert :) I'm just trying to give any (possibly) useful hint I have :) Me neither. Any hints are more than welcome ;-) Things also 'get confused' at times
Re: [meta-freescale] Wandboard uBoot clock
On 15 Jul 2013, at 17:35, Fabio Estevam wrote: On Mon, Jul 15, 2013 at 1:32 PM, Chris Tapp opensou...@keylevel.com wrote: When the Wandboard Quad starts, uBoot reports that the CPU is running at 792 MHz. The Quad is a 1 GHz board, so should this be higher or does it somehow get switched later on? U-boot starts at 792MHz and kernel bumps it to 1GHz. Thanks for the confirmation. Chris Tapp opensou...@keylevel.com www.keylevel.com ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] Gstreamer pipeline problem
On 15 Jul 2013, at 18:11, Thomas Senyk wrote: SNIP I normally run a basic playbin2 pipeline to 'fakesink'. When it's time to render I grab the latest frame via playbin2, upload this into a texture and render. ah ok, then I see two possible setups. either: decoder pipeline ! glupload ! fakesink ! your application using the tex ids from glupload coming in with GstBuffer or: decoder pipeline ! fakesink ! your application maps the memory, coming in with GstBuffer, using glTexDirectVIVMap ... using fakesink 'in front' of your application is a means to get access to the GstBuffer objects, right? (rather then haven to implement the pad and everything for a actually sink, you just have to implement one call-back function for 'handoff'-signal). Do I get you right? Nearly. What I've got is basically just: playbin2 uri=... video-sink=fakesink So, not a lot going on! I then use the frame property of playbin2 to get the most recently rendered frame, which I then glTexImage2D. I really do it this way so I can easily control where the frame is rendered and get it in sync with my rendering loop (which has lots of other animation taking place). If so, I advice you to do the 'or', it's not much code and you got all the opengl parts in your hand. There shouldn't be any trade-off for this .. besides having to write hardware- specific code. That's the real catch - I'm trying to write code which I can use on multiple platforms. I seem to need queue2 on the video-sink and audio-sink to keep them in sync. Video sinks generally set sync=1 by default, but fakesink doesn't. If this isn't set, then the video plays too fast and loses sync with the audio. ok, never looked any lipsync so far (probably should have...) so can't tell, therefor never tried to fix it either. I missed this bit earlier: Another thing I spotted: I just looked at your original mail and from the work I've done last week I can tell that I've never seen* or therefor used x-raw-rgb * 'seen' as in: source file having rgb format For me there was no need ... I'm having a sink (Qt/c++ code) which takes x- raw-yuv ... this code give the frame over to the opengl-scenegraph and then I map this memory with code like: void *bits = (void*)mFrame.bits(); GLuint physical = ~0U; glTexDirectVIVMap_LOCALE(GL_TEXTURE_2D, w, h, GL_VIV_YV12, bits, physical); This is then directly used in the shaders without any YUV-RGB code. The texture units knows YUV and does the texture-coordinate/color-lookup accordingly. ... what I'm trying to say: you don't have to convert to GL_RGB(A). That would be nice if it can be done portably. Chris Tapp opensou...@keylevel.com www.keylevel.com ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] Wandboard Quad experience (good!)
= 1387304kB [ 2445.805269] 4614 total pagecache pages [ 2445.809023] 0 pages in swap cache [ 2445.812355] Swap cache stats: add 0, delete 0, find 0/0 [ 2445.817586] Free swap = 0kB [ 2445.820483] Total swap = 0kB [ 2445.870417] 524288 pages of RAM [ 2445.873566] 458040 free pages [ 2445.876537] 50744 reserved pages [ 2445.879767] 2012 slab pages [ 2445.882584] 5157 pages shared [ 2445.885557] 0 pages swap cached [ 2445.888705] Physical memory allocation error! [ 2445.893083] Physical memory allocation error! I'll have a go at getting the other one to show... Chris Tapp opensou...@keylevel.com www.keylevel.com ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] Gstreamer pipeline problem
Hi John, On 12 Jul 2013, at 01:22, John Weber wrote: Hi Chris, gst-launch videotestsrc ! v4l2sink to work as there's no /dev/video1 ! Does anyone know where I can find instructions on how to get v4l2 working under Ubuntu 12.04 for a radeon HD 5450 card? Google has not been my friend ;-) /dev/video1 is created when you have an actual video input like a video decoder or camera or UVC camera and it would be used with v4l2src (or in the case of i.MX6 CSI, mfw_v4lsrc). videotestsrc should not need a video input device to work though as it is creates its own video data. What is the error you are seeing? What is your setup? Board? Yocto version? Yocto image? Sorry, I don't make myself clear here. I wanted to try v4l on my Ubuntu development system first - it's this that isn't working: gst-launch-0.10 videotestsrc ! v4l2sink Setting pipeline to PAUSED ... ERROR: Pipeline doesn't want to pause. ERROR: from element /GstPipeline:pipeline0/GstV4l2Sink:v4l2sink0: Cannot identify device /dev/video1. Additional debug info: v4l2_calls.c(493): gst_v4l2_open (): /GstPipeline:pipeline0/GstV4l2Sink:v4l2sink0: system error: No such file or directory Setting pipeline to NULL ... Freeing pipeline ... John ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale Chris Tapp opensou...@keylevel.com www.keylevel.com ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] Gstreamer pipeline problem
Hi Thomas, Some more info below: On 11 Jul 2013, at 09:39, Thomas Senyk wrote: On Wednesday, 10 July, 2013 20:53:58 Chris Tapp wrote: On 10 Jul 2013, at 20:19, Chris Tapp wrote: I've got an application which uses playbin2 to capture video. The pipeline is of the form: playbin2 uri=... video-sink=queue2 ! videoscale ! video/x-raw-rgb, pixel-aspect-ratio=1/1, width=capture-width, height=capture-height ! fakesink I then get the frame property from the pipeline and use this to grab the latest frame. This works on my development system (Ubuntu 11.10) and a Cedar Trail / Yocto system, but the pipeline fails on the Wandboard Quad. I think this is related to: 0:00:13.028151336 1349 0x4442d520 WARN basetransform /media/SSD-RAID/build-danny-wandboard/tmp/work/armv7a-vfp-neon-poky-linux -gnueabi/gstreamer/0.10.36-r2/gstreamer-0.10.36/libs/gst/base/gstbasetrans form.c:1304:gst_base_transform_setcaps:videoscale0x2ab820 transform could not transform video/x-raw-yuv, width=(int)854, height=(int)480, framerate=(fraction)24/1, format=(fourcc)I420, interlaced=(boolean)false in anything we support I added an ffmpegcolorspace element betwween the queue2 and the videoscale to get round this and the pipeline now builds, but only a few frames are captured. There are different diagnostics showing: 0:00:02.881403000 1361 0x28da60 WARN vpudec vpudec.c:914:gst_vpudec_core_create_and_register_frames: Allocate Internal framebuffers Message Callback : Element playbin0x250b68 changed state from READY to PAUSED. 0:00:03.237675000 1361 0x28da60 WARN vpudec vpudec.c:1578:gst_vpudec_chain: Got no frame buffer message, return 0x89, 8 frames in displaying queue!! 0:00:03.242324334 1361 0x28da60 WARN vpudec vpudec.c:1578:gst_vpudec_chain: Got no frame buffer message, return 0x89, 8 frames in displaying queue!! lots of repeats 0:00:08.499914334 1382 0x28d860 WARN vpudec vpudec.c:1655:gst_vpudec_chain: Retry too many times, maybe BUG!! 0:00:08.500784667 1382 0x28d860 WARN vpudec vpudec.c:1578:gst_vpudec_chain: Got no frame buffer message, return 0x88, 8 frames in displaying queue!! lots of repeats Message Callback : Element playbin0x250aa0 changed state from PAUSED to PLAYING. 0:00:09.253202667 1382 0x28d860 WARN vpudec vpudec.c:1578:gst_vpudec_chain: Got no frame buffer message, return 0x88, 8 frames in displaying queue!! 0:00:13.364523335 1460 0x142ec0 WARN mfw_v4lsink mfw_gst_v4l_buffer.c:435:mfw_gst_v4l2_new_buffer: Try new buffer failed, ret 2 No such file or directory queued 0 The Message Callback events are my own logging to try and see what's happening in my app. Is this something I'm doing wrong, or are these messages a real issue somewhere? This is when playing a .webm. The results for an .flv are as expected. is it the same when you use v4l2 sink instead of fakesink? Is playbin (without defining the pipeline) behaving the same? I've run some tests using pipelines of the form: gst-launch playbin2=file://trailer.webm video-sink=a-sink-to-test GST_DEBUG was set to *:2 1) When the sink is set to mfw_4vlsink I get full screen video playback; 2) When the sink is set to fakesink I get nothing on the screen (as expected), and no debug of interest; 3) When the sink is set to queue2 ! mfw_4vlsink I get very choppy full screen video playback (which eventually stalls) and debug output as originally reported; 4) When the sink is set to queue2 ! fakesink I get nothing on the screen (as expected), and no debug of interest; 5) When the sink is set to queue2 ! fakesink sync=1 I get nothing on the screen and debug output as originally reported. These were all run from the command line, no 'X' running. It looks like queue2 + sync=1 (default for v4lsink) combination causes the problem... Setting sync=0 for v4lsink makes no difference and looks to be ignored. Things also 'get confused' at times and 1) doesn't work anymore without a restart. Does any of that help? ;-) Chris Tapp opensou...@keylevel.com www.keylevel.com ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] Gstreamer pipeline problem
Hi John, On 12 Jul 2013, at 15:12, John Weber wrote: Hi Chris, That's unfortunate as I need a pipeline which can run on many different platforms, including 'standard pc'. This was one reason why I was using fakesink to capture the images - v4l looked like a way to go so that I could stream the video direct to the screen and get the full benefits of any acceleration supported by a platform (zero copy, etc.). I think you will probably need to build an application that creates a pipeline based on the host. For example, a desktop system probably will not have much use for V4L output devices, so they might not use v4l2sink but autovideosink. On a i.MX6 for example, you'll want to use mfw_v4lsink, which as I understand it does take advantage of some of the built-in acceleration. Also, for video decoding (H.264 decompression I mean), you'll want to change the element you use there as well. For i.MX6 this is vpudec, but for general purpose there is x264dec (think that is the name but not sure). Yes, that's one of the reasons I've been using playbin2 and fakesink. I'm hoping that playbin will build a decent decode pipeline and I can then use the frames in fakesink to create an OpenGLES texture which I can render in my app. This also gives a portable way of rendering the video where I want, at the size I need and without and decoration. I was hoping that glupload may help make this more efficient, but I can't even get gst-plugins-gl to build at the moment. Chris Tapp opensou...@keylevel.com www.keylevel.com ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] Error building master
Hi John, On 12 Jul 2013, at 18:44, John Weber wrote: I've synced the entire platform and am rebuilding all again to make sure I still see this error, but this was the second time I've seen it. I'll report back. This looks to be the same as http://comments.gmane.org/gmane.linux.embedded.yocto.general/12533. I'm supposed to have opened a bug for this - I'll try and get it in later on today. On 7/12/13 8:49 AM, Otavio Salvador wrote: On Wed, Jul 10, 2013 at 1:09 AM, John Weber rjohnwe...@gmail.com wrote: I ran into this problem again. Again, I worked around it by manually copying the required libraries from gpu-viv-bin-mx6q to the sysroot location. Here is some other information that I discovered tonight that might shed some light. After I did the manual copy, I attempted to rebuild the image again. When I did, libglu compile succeeded, and bitbake produced some warning messages. I never saw this build error. Any more info? -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.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 Chris Tapp opensou...@keylevel.com www.keylevel.com ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] Error building master
On 12 Jul 2013, at 19:35, Chris Tapp wrote: Hi John, On 12 Jul 2013, at 18:44, John Weber wrote: I've synced the entire platform and am rebuilding all again to make sure I still see this error, but this was the second time I've seen it. I'll report back. This looks to be the same as http://comments.gmane.org/gmane.linux.embedded.yocto.general/12533. I'm supposed to have opened a bug for this - I'll try and get it in later on today. Done - https://bugzilla.yoctoproject.org/show_bug.cgi?id=4848 On 7/12/13 8:49 AM, Otavio Salvador wrote: On Wed, Jul 10, 2013 at 1:09 AM, John Weber rjohnwe...@gmail.com wrote: I ran into this problem again. Again, I worked around it by manually copying the required libraries from gpu-viv-bin-mx6q to the sysroot location. Here is some other information that I discovered tonight that might shed some light. After I did the manual copy, I attempted to rebuild the image again. When I did, libglu compile succeeded, and bitbake produced some warning messages. I never saw this build error. Any more info? -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.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 Chris Tapp opensou...@keylevel.com www.keylevel.com ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale Chris Tapp opensou...@keylevel.com www.keylevel.com ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] Error building master
On 12 Jul 2013, at 22:49, John Weber wrote: On 7/12/13 3:10 PM, Chris Tapp wrote: On 12 Jul 2013, at 19:35, Chris Tapp wrote: Hi John, On 12 Jul 2013, at 18:44, John Weber wrote: I've synced the entire platform and am rebuilding all again to make sure I still see this error, but this was the second time I've seen it. I'll report back. This looks to be the same as http://comments.gmane.org/gmane.linux.embedded.yocto.general/12533. I'm supposed to have opened a bug for this - I'll try and get it in later on today. Done - https://bugzilla.yoctoproject.org/show_bug.cgi?id=4848 Thanks Chris. It does look similar. Here is another piece of information from today: Starting from a semi-clean build (new build/tmp, but with preexisting shared state cache), and a freshly updated set of metadata, I ran bitbake fsl-image-test, here is the header printout: john@leo:~/fsl-community-bsp/build$ MACHINE=wandboard-dual bitbake fsl-image-test Loading cache: 100% |###| ETA: 00:00:00 Loaded 1706 entries from dependency cache. Build Configuration: BB_VERSION= 1.19.1 BUILD_SYS = x86_64-linux NATIVELSBSTRING = Ubuntu-12.04 TARGET_SYS= arm-poky-linux-gnueabi MACHINE = wandboard-dual DISTRO= poky DISTRO_VERSION= 1.4+snapshot-20130712 TUNE_FEATURES = armv7a vfp neon TARGET_FPU= vfp-neon meta meta-yocto= (nobranch):a63229917a5708de2d161aba0d67168ce0da6365 meta-oe = (nobranch):c383d6230942bb1558cee02764bced09031cb70f meta-fsl-arm = master-next:e2f010bec19aef73b4731cb4f66c7412d59b265c meta-fsl-arm-extra = (nobranch):3898b9dfa4bc81791665179d8854d47a5080060e meta-fsl-demos= (nobranch):eb6bd0d3e799c9053f80104194a0f2a37fb690e2 - I encountered the same exact issue with libglu (not able to find -lGL or libGL.so) - Running bitbake gpu-viv-bin-mx6q followed by bitbake fsl-image-test worked to create an image I'm fairly sure that libGL.so is not being populated into the sysroot before libglu runs its do_compile task, so it seems to be a dependency problem to me. But others should see this problem as well and they are not. Then, I started from a brand new shared state cache and new build/tmp just to eliminate the possibility of any issues that could be part of my personal setup here. I had the same result. Not sure what I can do if I'm the only person seeing this issue, besides file a bug on it. Sounds like it's worth filing. It certainly looks like there's something there and it makes sense to capture any information you've got. John Chris Tapp opensou...@keylevel.com www.keylevel.com ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [yocto] Compile error for boost_1.54.0
On 11 Jul 2013, at 20:27, Saul Wold wrote: OK, I finally tracked this bugger down to the eglibc update to 2.18 and specifically ../../../eglibc/2.18-r0/eglibc-2.18/libc/ChangeLog: * include/features.h (__GLIBC_HAVE_LONG_LONG): Remove. Turns out that in boost code there is a check for the __GLIBC_HAVE_LONG_LONG in cstdint.hpp and this was not getting triggered any more. The include issue for g++ was kind of a red herring in this case, that issue still exists, but this is a different problem. And there is a patch for that in the SVN master, I will pull it! Thanks Saul :-) Sau! On 07/09/2013 10:04 PM, Khem Raj wrote: On Jul 9, 2013, at 1:50 PM, Martin Jansa martin.ja...@gmail.com wrote: On Tue, Jul 09, 2013 at 09:25:30PM +0100, Chris Tapp wrote: Forwarding to Yocto mailing list: On 9 Jul 2013, at 21:21, Otavio Salvador wrote: On Tue, Jul 9, 2013 at 5:19 PM, Chris Tapp opensou...@keylevel.com wrote: On 9 Jul 2013, at 20:09, Chris Tapp wrote: I'm getting a failure in do_compile when building boost_1.54.0 using master-next for the wandboard-quad. The log is about 1.5MB, but the important bit seems to be that uintptr_t isn't defined but is required by /boost/atomic/atomic.hpp. Has anyone seen this before? I also meant to say that adding: typedef unsigned long long uintptr_t; to atomic.hpp 'fixes' the build, but this is not a good solution ;-) It needs to be checked against normal Poky to ensure it is BSP specific; I doubt it is. See http://lists.openembedded.org/pipermail/openembedded-devel/2013-July/091331.html in above thread answering to your question if you want to include cstblib you need to specify -std=gnu++0x or -std=c++0x to cppflags. above container is not supported prior to c++0x standard But maybe it wasn't caused by eglibc upgrade (and header cleanup in eglibc) but by boost upgrade. -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com ___ yocto mailing list yo...@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yo...@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yo...@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto Chris Tapp opensou...@keylevel.com www.keylevel.com ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] Gstreamer pipeline problem
On 11 Jul 2013, at 09:39, Thomas Senyk wrote: On Wednesday, 10 July, 2013 20:53:58 Chris Tapp wrote: On 10 Jul 2013, at 20:19, Chris Tapp wrote: I've got an application which uses playbin2 to capture video. The pipeline is of the form: playbin2 uri=... video-sink=queue2 ! videoscale ! video/x-raw-rgb, pixel-aspect-ratio=1/1, width=capture-width, height=capture-height ! fakesink I then get the frame property from the pipeline and use this to grab the latest frame. This works on my development system (Ubuntu 11.10) and a Cedar Trail / Yocto system, but the pipeline fails on the Wandboard Quad. I think this is related to: 0:00:13.028151336 1349 0x4442d520 WARN basetransform /media/SSD-RAID/build-danny-wandboard/tmp/work/armv7a-vfp-neon-poky-linux -gnueabi/gstreamer/0.10.36-r2/gstreamer-0.10.36/libs/gst/base/gstbasetrans form.c:1304:gst_base_transform_setcaps:videoscale0x2ab820 transform could not transform video/x-raw-yuv, width=(int)854, height=(int)480, framerate=(fraction)24/1, format=(fourcc)I420, interlaced=(boolean)false in anything we support I added an ffmpegcolorspace element betwween the queue2 and the videoscale to get round this and the pipeline now builds, but only a few frames are captured. There are different diagnostics showing: 0:00:02.881403000 1361 0x28da60 WARN vpudec vpudec.c:914:gst_vpudec_core_create_and_register_frames: Allocate Internal framebuffers Message Callback : Element playbin0x250b68 changed state from READY to PAUSED. 0:00:03.237675000 1361 0x28da60 WARN vpudec vpudec.c:1578:gst_vpudec_chain: Got no frame buffer message, return 0x89, 8 frames in displaying queue!! 0:00:03.242324334 1361 0x28da60 WARN vpudec vpudec.c:1578:gst_vpudec_chain: Got no frame buffer message, return 0x89, 8 frames in displaying queue!! lots of repeats 0:00:08.499914334 1382 0x28d860 WARN vpudec vpudec.c:1655:gst_vpudec_chain: Retry too many times, maybe BUG!! 0:00:08.500784667 1382 0x28d860 WARN vpudec vpudec.c:1578:gst_vpudec_chain: Got no frame buffer message, return 0x88, 8 frames in displaying queue!! lots of repeats Message Callback : Element playbin0x250aa0 changed state from PAUSED to PLAYING. 0:00:09.253202667 1382 0x28d860 WARN vpudec vpudec.c:1578:gst_vpudec_chain: Got no frame buffer message, return 0x88, 8 frames in displaying queue!! 0:00:13.364523335 1460 0x142ec0 WARN mfw_v4lsink mfw_gst_v4l_buffer.c:435:mfw_gst_v4l2_new_buffer: Try new buffer failed, ret 2 No such file or directory queued 0 The Message Callback events are my own logging to try and see what's happening in my app. Is this something I'm doing wrong, or are these messages a real issue somewhere? This is when playing a .webm. The results for an .flv are as expected. is it the same when you use v4l2 sink instead of fakesink? Is playbin (without defining the pipeline) behaving the same? I've not got that in the build at the moment - I'll add it in and give it a try. I was going to try v4l2 out on my development system as I've not used it before, but I can't even get: gst-launch videotestsrc ! v4l2sink to work as there's no /dev/video1 ! Does anyone know where I can find instructions on how to get v4l2 working under Ubuntu 12.04 for a radeon HD 5450 card? Google has not been my friend ;-) Chris Tapp opensou...@keylevel.com www.keylevel.com ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale Chris Tapp opensou...@keylevel.com www.keylevel.com ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] Wandboard Quad experience (good!)
Hi John, On 10 Jul 2013, at 03:57, John Weber wrote: Hi Chris, First off - thanks for trying out the kernel. Let me know if you see anything that needs to be fixed. Patches are welcome, of course. I chatted with Otavio about this issue because I'm working on getting Quad up and running tonight. He already has a patch to submit. If you're interested in trying this tonight, all you need to do is rename: meta-fsl-arm-extra/recipes-bsp/broadcom-nvram-config/files/wandboard-dual to meta-fsl-arm-extra/recipes-bsp/broadcom-nvram-config/files/wandboard (without the '-dual') When we did this in the beginning, all we had with Wifi on it was the Dual. Now we have Quad, so we need to use a common directory. Thanks, that's done the trick. Kernel looks good so far - I just need to enable CONFIG_HID_APPLE so my keyboard works ;-) John On Tue, Jul 9, 2013 at 6:05 PM, Chris Tapp opensou...@keylevel.com wrote: On 9 Jul 2013, at 23:03, Chris Tapp wrote: On 9 Jul 2013, at 22:51, Otavio Salvador wrote: On Tue, Jul 9, 2013 at 6:38 PM, Chris Tapp opensou...@keylevel.com wrote: Thanks to help from Otavio and others, I now have an image building for the Wandboard Quad. I've built a custom OpenGLES application running under EGL (which I normally run on a Cedar Trail platform) and it's mostly running as expected - just need to work out why my gstreamer pipeline isn't working. The only bit that I had to work round was broadcom-nvram-config, which resulted in: NOTE: Resolving any missing task queue dependencies ERROR: Nothing RPROVIDES 'linux-firmware-INVALID' (but /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/broadcom-nvram-config.bb RDEPENDS on or otherwise requires it) NOTE: Runtime target 'linux-firmware-INVALID' is unbuildable, removing... I got round this by commenting out: MACHINE_EXTRA_RRECOMMENDS += broadcom-nvram-config I fixed this and pused this for master-next; please confirm it works :-) Yes it does. Thank you :-) Or not... I'm getting a fetcher failure: WARNING: Failed to fetch URL file://nvram.txt, attempting MIRRORS if available ERROR: Fetcher failure: Unable to find file file://nvram.txt anywhere. The paths that were searched were: /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/broadcom-nvram-config-1.0/arm /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/broadcom-nvram-config-1.0/armv7a /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/broadcom-nvram-config-1.0/mx6 /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/broadcom-nvram-config-1.0/mx6q /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/broadcom-nvram-config-1.0/wandboard /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/broadcom-nvram-config-1.0/wandboard-quad /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/broadcom-nvram-config-1.0/poky /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/broadcom-nvram-config-1.0/ /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/broadcom-nvram-config/arm /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/broadcom-nvram-config/armv7a /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/broadcom-nvram-config/mx6 /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/broadcom-nvram-config/mx6q /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/broadcom-nvram-config/wandboard /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/broadcom-nvram-config/wandboard-quad /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/broadcom-nvram-config/poky /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/broadcom-nvram-config/ /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/files/arm /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/files/armv7a /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/files/mx6 /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/files/mx6q /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/files/wandboard /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/files/wandboard-quad /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/files/poky /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/files/ /media/SSD-RAID/build-danny-wandboard/../yocto-downloads ERROR: Function failed: Fetcher failure for URL: 'file://nvram.txt'. Unable to fetch URL from any source. ERROR
[meta-freescale] Gstreamer pipeline problem
I've got an application which uses playbin2 to capture video. The pipeline is of the form: playbin2 uri=... video-sink=queue2 ! videoscale ! video/x-raw-rgb, pixel-aspect-ratio=1/1, width=capture-width, height=capture-height ! fakesink I then get the frame property from the pipeline and use this to grab the latest frame. This works on my development system (Ubuntu 11.10) and a Cedar Trail / Yocto system, but the pipeline fails on the Wandboard Quad. I think this is related to: 0:00:13.028151336 1349 0x4442d520 WARN basetransform /media/SSD-RAID/build-danny-wandboard/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/gstreamer/0.10.36-r2/gstreamer-0.10.36/libs/gst/base/gstbasetransform.c:1304:gst_base_transform_setcaps:videoscale0x2ab820 transform could not transform video/x-raw-yuv, width=(int)854, height=(int)480, framerate=(fraction)24/1, format=(fourcc)I420, interlaced=(boolean)false in anything we support I added an ffmpegcolorspace element betwween the queue2 and the videoscale to get round this and the pipeline now builds, but only a few frames are captured. There are different diagnostics showing: 0:00:02.881403000 1361 0x28da60 WARN vpudec vpudec.c:914:gst_vpudec_core_create_and_register_frames: Allocate Internal framebuffers Message Callback : Element playbin0x250b68 changed state from READY to PAUSED. 0:00:03.237675000 1361 0x28da60 WARN vpudec vpudec.c:1578:gst_vpudec_chain: Got no frame buffer message, return 0x89, 8 frames in displaying queue!! 0:00:03.242324334 1361 0x28da60 WARN vpudec vpudec.c:1578:gst_vpudec_chain: Got no frame buffer message, return 0x89, 8 frames in displaying queue!! lots of repeats 0:00:08.499914334 1382 0x28d860 WARN vpudec vpudec.c:1655:gst_vpudec_chain: Retry too many times, maybe BUG!! 0:00:08.500784667 1382 0x28d860 WARN vpudec vpudec.c:1578:gst_vpudec_chain: Got no frame buffer message, return 0x88, 8 frames in displaying queue!! lots of repeats Message Callback : Element playbin0x250aa0 changed state from PAUSED to PLAYING. 0:00:09.253202667 1382 0x28d860 WARN vpudec vpudec.c:1578:gst_vpudec_chain: Got no frame buffer message, return 0x88, 8 frames in displaying queue!! 0:00:13.364523335 1460 0x142ec0 WARN mfw_v4lsink mfw_gst_v4l_buffer.c:435:mfw_gst_v4l2_new_buffer: Try new buffer failed, ret 2 No such file or directory queued 0 The Message Callback events are my own logging to try and see what's happening in my app. Is this something I'm doing wrong, or are these messages a real issue somewhere? Chris Tapp opensou...@keylevel.com www.keylevel.com ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] Gstreamer pipeline problem
On 10 Jul 2013, at 20:19, Chris Tapp wrote: I've got an application which uses playbin2 to capture video. The pipeline is of the form: playbin2 uri=... video-sink=queue2 ! videoscale ! video/x-raw-rgb, pixel-aspect-ratio=1/1, width=capture-width, height=capture-height ! fakesink I then get the frame property from the pipeline and use this to grab the latest frame. This works on my development system (Ubuntu 11.10) and a Cedar Trail / Yocto system, but the pipeline fails on the Wandboard Quad. I think this is related to: 0:00:13.028151336 1349 0x4442d520 WARN basetransform /media/SSD-RAID/build-danny-wandboard/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/gstreamer/0.10.36-r2/gstreamer-0.10.36/libs/gst/base/gstbasetransform.c:1304:gst_base_transform_setcaps:videoscale0x2ab820 transform could not transform video/x-raw-yuv, width=(int)854, height=(int)480, framerate=(fraction)24/1, format=(fourcc)I420, interlaced=(boolean)false in anything we support I added an ffmpegcolorspace element betwween the queue2 and the videoscale to get round this and the pipeline now builds, but only a few frames are captured. There are different diagnostics showing: 0:00:02.881403000 1361 0x28da60 WARN vpudec vpudec.c:914:gst_vpudec_core_create_and_register_frames: Allocate Internal framebuffers Message Callback : Element playbin0x250b68 changed state from READY to PAUSED. 0:00:03.237675000 1361 0x28da60 WARN vpudec vpudec.c:1578:gst_vpudec_chain: Got no frame buffer message, return 0x89, 8 frames in displaying queue!! 0:00:03.242324334 1361 0x28da60 WARN vpudec vpudec.c:1578:gst_vpudec_chain: Got no frame buffer message, return 0x89, 8 frames in displaying queue!! lots of repeats 0:00:08.499914334 1382 0x28d860 WARN vpudec vpudec.c:1655:gst_vpudec_chain: Retry too many times, maybe BUG!! 0:00:08.500784667 1382 0x28d860 WARN vpudec vpudec.c:1578:gst_vpudec_chain: Got no frame buffer message, return 0x88, 8 frames in displaying queue!! lots of repeats Message Callback : Element playbin0x250aa0 changed state from PAUSED to PLAYING. 0:00:09.253202667 1382 0x28d860 WARN vpudec vpudec.c:1578:gst_vpudec_chain: Got no frame buffer message, return 0x88, 8 frames in displaying queue!! 0:00:13.364523335 1460 0x142ec0 WARN mfw_v4lsink mfw_gst_v4l_buffer.c:435:mfw_gst_v4l2_new_buffer: Try new buffer failed, ret 2 No such file or directory queued 0 The Message Callback events are my own logging to try and see what's happening in my app. Is this something I'm doing wrong, or are these messages a real issue somewhere? This is when playing a .webm. The results for an .flv are as expected. Chris Tapp opensou...@keylevel.com www.keylevel.com ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] Sanity check please...
Hi Otavio, On 9 Jul 2013, at 01:09, Otavio Salvador wrote: On Mon, Jul 8, 2013 at 6:20 PM, Chris Tapp opensou...@keylevel.com wrote: snip So, I thought I should try master instead of master-next (not for meta-fsl-arm-extras as I need the quad machine), but then the kernel fails to build with: | arch/arm/mach-mx6/built-in.o: In function `wand_sata_init': | :(.text+0x102ac): undefined reference to `sata_init' | arch/arm/mach-mx6/built-in.o: In function `wand_board_init': | :(.init.text+0x2424): undefined reference to `imx6q_ahci_data' | :(.init.text+0x30f8): undefined reference to `imx_add_ahci' | make: *** [.tmp_vmlinux1] Error 1 Yes; I think it lackes a defconfig fix. I am using John's Linux kernel for testing and I got it building fine. I hadn't an opportunity to boot it yet (I am finishing a customer BSP based on dylan) but you can give it a try. Thanks, that seems to build nicely. Chris Tapp opensou...@keylevel.com www.keylevel.com ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] Compile error for boost_1.54.0
On 9 Jul 2013, at 20:09, Chris Tapp wrote: I'm getting a failure in do_compile when building boost_1.54.0 using master-next for the wandboard-quad. The log is about 1.5MB, but the important bit seems to be that uintptr_t isn't defined but is required by /boost/atomic/atomic.hpp. Has anyone seen this before? I also meant to say that adding: typedef unsigned long long uintptr_t; to atomic.hpp 'fixes' the build, but this is not a good solution ;-) Chris Tapp opensou...@keylevel.com www.keylevel.com ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] Wandboard Quad experience (good!)
On 9 Jul 2013, at 22:51, Otavio Salvador wrote: On Tue, Jul 9, 2013 at 6:38 PM, Chris Tapp opensou...@keylevel.com wrote: Thanks to help from Otavio and others, I now have an image building for the Wandboard Quad. I've built a custom OpenGLES application running under EGL (which I normally run on a Cedar Trail platform) and it's mostly running as expected - just need to work out why my gstreamer pipeline isn't working. The only bit that I had to work round was broadcom-nvram-config, which resulted in: NOTE: Resolving any missing task queue dependencies ERROR: Nothing RPROVIDES 'linux-firmware-INVALID' (but /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/broadcom-nvram-config.bb RDEPENDS on or otherwise requires it) NOTE: Runtime target 'linux-firmware-INVALID' is unbuildable, removing... I got round this by commenting out: MACHINE_EXTRA_RRECOMMENDS += broadcom-nvram-config I fixed this and pused this for master-next; please confirm it works :-) Yes it does. Thank you :-) -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 Chris Tapp opensou...@keylevel.com www.keylevel.com ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] Wandboard Quad experience (good!)
On 9 Jul 2013, at 23:03, Chris Tapp wrote: On 9 Jul 2013, at 22:51, Otavio Salvador wrote: On Tue, Jul 9, 2013 at 6:38 PM, Chris Tapp opensou...@keylevel.com wrote: Thanks to help from Otavio and others, I now have an image building for the Wandboard Quad. I've built a custom OpenGLES application running under EGL (which I normally run on a Cedar Trail platform) and it's mostly running as expected - just need to work out why my gstreamer pipeline isn't working. The only bit that I had to work round was broadcom-nvram-config, which resulted in: NOTE: Resolving any missing task queue dependencies ERROR: Nothing RPROVIDES 'linux-firmware-INVALID' (but /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/broadcom-nvram-config.bb RDEPENDS on or otherwise requires it) NOTE: Runtime target 'linux-firmware-INVALID' is unbuildable, removing... I got round this by commenting out: MACHINE_EXTRA_RRECOMMENDS += broadcom-nvram-config I fixed this and pused this for master-next; please confirm it works :-) Yes it does. Thank you :-) Or not... I'm getting a fetcher failure: WARNING: Failed to fetch URL file://nvram.txt, attempting MIRRORS if available ERROR: Fetcher failure: Unable to find file file://nvram.txt anywhere. The paths that were searched were: /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/broadcom-nvram-config-1.0/arm /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/broadcom-nvram-config-1.0/armv7a /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/broadcom-nvram-config-1.0/mx6 /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/broadcom-nvram-config-1.0/mx6q /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/broadcom-nvram-config-1.0/wandboard /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/broadcom-nvram-config-1.0/wandboard-quad /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/broadcom-nvram-config-1.0/poky /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/broadcom-nvram-config-1.0/ /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/broadcom-nvram-config/arm /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/broadcom-nvram-config/armv7a /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/broadcom-nvram-config/mx6 /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/broadcom-nvram-config/mx6q /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/broadcom-nvram-config/wandboard /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/broadcom-nvram-config/wandboard-quad /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/broadcom-nvram-config/poky /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/broadcom-nvram-config/ /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/files/arm /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/files/armv7a /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/files/mx6 /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/files/mx6q /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/files/wandboard /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/files/wandboard-quad /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/files/poky /media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/files/ /media/SSD-RAID/build-danny-wandboard/../yocto-downloads ERROR: Function failed: Fetcher failure for URL: 'file://nvram.txt'. Unable to fetch URL from any source. ERROR: Task 4 (/media/SSD-RAID/meta-fsl-arm-extra-git/recipes-bsp/broadcom-nvram-config/broadcom-nvram-config.bb, do_fetch) failed with exit code '1' -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 Chris Tapp opensou...@keylevel.com www.keylevel.com ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale Chris Tapp opensou...@keylevel.com www.keylevel.com ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
[meta-freescale] Sanity check please...
I'm trying to build for the wandboard-quad from meta-fsl-arm-extras, so I've updated and switched to master-next by running: git checkout master-next git fetch origin git pull for poky, meta-fsl-arm and meta-fsl-arm-extras. However, if I try and build I get: ERROR: No recipes available for: /media/SSD-RAID/meta-fsl-arm-git/recipes-qt/qt4/qt4-embedded_4.8.5.bbappend /media/SSD-RAID/meta-fsl-arm-git/recipes-qt/qt4/qt4-x11-free_4.8.5.bbappend ERROR: Command execution failed: Exited with 1 So, I thought I should try master instead of master-next (not for meta-fsl-arm-extras as I need the quad machine), but then the kernel fails to build with: | arch/arm/mach-mx6/built-in.o: In function `wand_sata_init': | :(.text+0x102ac): undefined reference to `sata_init' | arch/arm/mach-mx6/built-in.o: In function `wand_board_init': | :(.init.text+0x2424): undefined reference to `imx6q_ahci_data' | :(.init.text+0x30f8): undefined reference to `imx_add_ahci' | make: *** [.tmp_vmlinux1] Error 1 There is a sample Yocto image on wandboard.org (http://www.wandboard.org/index.php/downloads), so I know it builds. What am I doing wrong? I suspect it's just down to my poor git skills ;-) Chris Tapp opensou...@keylevel.com www.keylevel.com ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] pkg-config with gpu-viv-bin-mx6q
On 28 Jun 2013, at 03:32, Otavio Salvador wrote: On Thu, Jun 27, 2013 at 9:02 PM, Chris Tapp opensou...@keylevel.com wrote: I've got a recipe for an autotools application with runs under EGL / GLESv2. It uses the following to make sure these are available: PKG_CHECK_MODULE(LIBEGL, egl = 1.0 ) PKG_CHECK_MODULE(LIBGLESv2, glesv2 = 2.0 ) These libs are provided by gpu-viv-bin-mx6q, but it looks like there's no pkg-config data available for autotools. Does this already exist? If not, shall I create a patch to add it? This does, in master branch. Yes, that works great (and also fixes a compile error I was getting). Thanks. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 Chris Tapp opensou...@keylevel.com www.keylevel.com ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [yocto] Problems building core-image-minimal for meta-fsl-asm-extra / 'wandboard-dual'
On 27 Jun 2013, at 17:08, Jeff Osier-Mixon wrote:
Forwarding to meta-freescale (and I highly recommend joining this
list, c/o https://lists.yoctoproject.org)
Thanks. I've just added myself to the list as well.
-- Forwarded message --
From: Chris Tapp opensou...@keylevel.com
Date: Thu, Jun 27, 2013 at 12:54 AM
Subject: [yocto] Problems building core-image-minimal for
meta-fsl-asm-extra / 'wandboard-dual'
To: Yocto Discussion Mailing List yo...@yoctoproject.org
I'm trying to build core-image-minimal for the 'wandboard-dual'
machine from meta-fsl-arm extra
(https://github.com/Freescale/meta-fsl-arm-extra).
The README for that layer states that it depends on
git.openembedded.org/openembedded-core and
git.yoctoproject.org/meta-fsl-arm, both at branch 'danny' and revision
'HEAD'.
So, my bblayers looks like:
LCONF_VERSION = 6
BBPATH = ${TOPDIR}
BBFILES ?=
BBMASK = udev_.*\.bbappend$
BBLAYERS ?= \
/media/SSD-RAID/poky-git/meta \
/media/SSD-RAID/poky-git/meta-yocto \
/media/SSD-RAID/poky-git/meta-yocto-bsp \
/media/SSD-RAID/meta-fsl-arm-git \
/media/SSD-RAID/meta-fsl-arm-extra-git \
(The -git just reminds me that I'm using git repos!).
To (try and) make sure I have the correct branches I've run:
git checkout origin/danny --- for meta-fsl-arm
and
git checkout origin/master --- for meta-fsl-arm-extra
The dependencies listed in the README for origin/danny in meta-fsl-arm
look to fit in with the above.
I've also selected a 'danny' branch within my 'poky' repo:
git checkout danny-8.0.2
I've then built:
bitbake core-image-minimal
However, I'm getting an error in u-boot-fslc:
ERROR: Function failed: do_compile (see
/media/SSD-RAID/build-danny-wandboard/tmp/work/wandboard_dual-poky-linux-gnueabi/u-boot-fslc-v2012.10-r4/temp/log.do_compile.31641
for further information)
ERROR: Logfile of failure stored in:
/media/SSD-RAID/build-danny-wandboard/tmp/work/wandboard_dual-poky-linux-gnueabi/u-boot-fslc-v2012.10-r4/temp/log.do_compile.31641
Log data follows:
| DEBUG: Executing shell function do_compile
| NOTE: make -j 16 CROSS_COMPILE=arm-poky-linux-gnueabi-
CC=arm-poky-linux-gnueabi-gcc
--sysroot=/media/SSD-RAID/build-danny-wandboard/tmp/sysroots/wandboard-dual
wandboard_dl_config
| make: *** No rule to make target `wandboard_dl_config'. Stop.
| make: *** [wandboard_dl_config] Error 1
| ERROR: oe_runmake failed
| ERROR: Function failed: do_compile (see
/media/SSD-RAID/build-danny-wandboard/tmp/work/wandboard_dual-poky-linux-gnueabi/u-boot-fslc-v2012.10-r4/temp/log.do_compile.31641
for further information)
ERROR: Task 68
(/media/SSD-RAID/meta-fsl-arm-git/recipes-bsp/u-boot/u-boot-fslc_2012.10.bb,
do_compile) failed with exit code '1'
Can anyone point out where I've gone wrong?
Chris Tapp
opensou...@keylevel.com
www.keylevel.com
___
yocto mailing list
yo...@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
--
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org
Chris Tapp
opensou...@keylevel.com
www.keylevel.com
___
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale
Re: [meta-freescale] [yocto] Problems building core-image-minimal for meta-fsl-asm-extra / 'wandboard-dual'
On 27 Jun 2013, at 17:36, Otavio Salvador wrote: On Thu, Jun 27, 2013 at 1:32 PM, Chris Tapp opensou...@keylevel.com wrote: On 27 Jun 2013, at 17:08, Jeff Osier-Mixon wrote: Forwarding to meta-freescale (and I highly recommend joining this list, c/o https://lists.yoctoproject.org) Thanks. I've just added myself to the list as well. Please use dylan or master branch. That's done the trick. Thanks :-) I'm going to be using a wandboard-quad for an evaluation - do you have a rough idea how much I'll need to do to add support for this? -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 Chris Tapp opensou...@keylevel.com www.keylevel.com ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
[meta-freescale] pkg-config with gpu-viv-bin-mx6q
I've got a recipe for an autotools application with runs under EGL / GLESv2. It uses the following to make sure these are available: PKG_CHECK_MODULE(LIBEGL, egl = 1.0 ) PKG_CHECK_MODULE(LIBGLESv2, glesv2 = 2.0 ) These libs are provided by gpu-viv-bin-mx6q, but it looks like there's no pkg-config data available for autotools. Does this already exist? If not, shall I create a patch to add it? Chris Tapp opensou...@keylevel.com www.keylevel.com ___ meta-freescale mailing list meta-freescale@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-freescale
