Re: [yocto] Cedartrail / GLES / Framebuffer
Hi Ross, (Resend, as I forgot to include the list last time). On 15 Nov 2012, at 14:44, Burton, Ross wrote: > Hi, > > On 20 October 2012 19:31, Chris Tapp wrote: >> I'm still trying to get my 'perfect' platform configuration for a project. >> >> 1) I need to use the 'nopvr' machine as I need unionfs. This means I need >> the kernel 3.2, which doesn't currently support pvr; >> 2) I'm running using the framebuffer and would rather not have to include >> libx11; >> 3) I was using SDL, but I now need to support GLESv2 / EGL as well. >> >> Is it possible to build a system that runs like this? i.e. GLES on the >> framerbuffer without X11. >> >> I think the only issue is getting a build of MESA that runs without x11, but >> is there anything else, or another way? > > I had this marked to Follow Up but managed to ignore it until now, sorry. My turn - I had to go to Japan for a week and I've only just caught up with e-mails ;-) > GLES without X11 should work using EGL, but that will be using the > closed cdv-pvr-drivers package. If you can't use those for other > reasons, then you're stuck. That should be ok for this project. Thanks for the confirmation. > (yay closed drivers) > > I understand that Ubuntu contains a re-packaging and re-build of the > CedarView binary drivers - it may be worth seeing what kernel they are > built against as I believe that the stack is slightly new than the > MeeGo-derived binaries that we're using. I'll have a look, but this is well outside my comfort-zone :-) James Abernathy reported similar: "It may not solve the 3.0 problem for CDV and Yocto, but I noticed that Ubuntu 12.04.1 with the 3.2 kernel supports the PVR driver on it's 3.2.0 kernel. I've only tested it successfully on an All-In-One with LVDS off of an eDP to LVDS converter used on the DN2800MT motherboard." > Ross Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Best way to support multiple versions of Poky?
I'm just getting round to moving from 'denzil' to 'danny'. I've got a layer that makes some changes to a few recipes through bbappend files. However, 'danny' has bumped a few of these to a new version (which is good) which means I now have bbappend files that get a 'there is no matching bb file' errors when I try to build. This is easy to fix (generally just rename the bbappend to match the new version), but I would like the layer to be able to work with older versions of Poky - mainly in case I need to make changes to an existing project that hasn't be verified under 'danny'. What's the best way to do this? All I can think of is to have another set of layers to use when building against a specific poky version: meta-mystuff | +--poky-versions | +--denzil-specific +--danny-specific +--etc Is there a more elegant solution? Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Image libraries
Is there a recipe available for a library which can load image files into memory / GL textures? Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Image libraries
Hi Ross, On 3 Dec 2012, at 09:51, Burton, Ross wrote: > On 1 December 2012 22:39, Chris Tapp wrote: >> Is there a recipe available for a library which can load image files into >> memory / GL textures? > > Into memory, the lowest level would be libjpeg or libpng, but then > it's your responsibility to match the pixel formats. > If you're using GL and you don't have a higher level abstraction, you > might want to look at Cogl (GL specifics abstraction and sanity layer) > or Clutter (toolkit based on Cogl). Both of these are in oe-core. Thanks, I'll have a look at that. I've been using libsdl-image to get me going as I can use that to get at the image data and it's fairly easy to work out the pixel format. > Ross Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Image libraries
Hi Ross, On 3 Dec 2012, at 09:51, Burton, Ross wrote: > On 1 December 2012 22:39, Chris Tapp wrote: >> Is there a recipe available for a library which can load image files into >> memory / GL textures? > > Into memory, the lowest level would be libjpeg or libpng, but then > it's your responsibility to match the pixel formats. > If you're using GL and you don't have a higher level abstraction, you > might want to look at Cogl (GL specifics abstraction and sanity layer) > or Clutter (toolkit based on Cogl). Both of these are in oe-core. Thanks, I'll have a look at that. I've been using libsdl-image to get me going as I can use that to get at the image data and it's fairly easy to work out the pixel format. > Ross Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] bbappending a bbappend
Is it possible to have more than one bbappend applied to a recipe? I'm using meta-cedartrail with my own layer (which is set as lower priority). Meta-cedartrail has a linux-yocto_3.0.bbappend, but I want to be able to enable CONFIG_HID_APPLE in my layer so my Apple keyboard works (and keep meta-cedartrail 'clean'). Is it possible to use another linux-yocto_3.0.bbappend in my layer? I've given it a try, but it's not working and I thought it would be an idea to see if it __should__ before I try and fix it ;-) Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bbappending a bbappend
On 9 Dec 2012, at 00:11, Chris Larson wrote: > On Sat, Dec 8, 2012 at 5:07 PM, Chris Tapp wrote: > Is it possible to have more than one bbappend applied to a recipe? > > I'm using meta-cedartrail with my own layer (which is set as lower priority). > > Meta-cedartrail has a linux-yocto_3.0.bbappend, but I want to be able to > enable CONFIG_HID_APPLE in my layer so my Apple keyboard works (and keep > meta-cedartrail 'clean'). Is it possible to use another > linux-yocto_3.0.bbappend in my layer? I've given it a try, but it's not > working and I thought it would be an idea to see if it __should__ before I > try and fix it ;-) > > All bbappends from all layers are applied, in layer priority order. Thanks, I was hoping that was the case. I wonder why this isn't working then - I think I've done it as shown in the dev manual... > -- > Christopher Larson Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bbappending a bbappend
On 9 Dec 2012, at 02:06, Chris Larson wrote: > > > On Sat, Dec 8, 2012 at 5:54 PM, Chris Tapp wrote: > On 9 Dec 2012, at 00:11, Chris Larson wrote: > >> On Sat, Dec 8, 2012 at 5:07 PM, Chris Tapp wrote: >> Is it possible to have more than one bbappend applied to a recipe? >> >> I'm using meta-cedartrail with my own layer (which is set as lower priority). >> >> Meta-cedartrail has a linux-yocto_3.0.bbappend, but I want to be able to >> enable CONFIG_HID_APPLE in my layer so my Apple keyboard works (and keep >> meta-cedartrail 'clean'). Is it possible to use another >> linux-yocto_3.0.bbappend in my layer? I've given it a try, but it's not >> working and I thought it would be an idea to see if it __should__ before I >> try and fix it ;-) >> >> All bbappends from all layers are applied, in layer priority order. > > Thanks, I was hoping that was the case. > > I wonder why this isn't working then - I think I've done it as shown in the > dev manual... > > > Try making use of bitbake-layers show-appends (iirc) Thanks, I didn't know about that one. It shows three .bbappends: 1) meta-yocto-bsp 2) meta-cedartrail 3) One for my layer > -- > Christopher Larson Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bbappending a bbappend
On 9 Dec 2012, at 04:47, Bruce Ashfield wrote: > > > > On Sat, Dec 8, 2012 at 7:54 PM, Chris Tapp wrote: > On 9 Dec 2012, at 00:11, Chris Larson wrote: > >> On Sat, Dec 8, 2012 at 5:07 PM, Chris Tapp wrote: >> Is it possible to have more than one bbappend applied to a recipe? >> >> I'm using meta-cedartrail with my own layer (which is set as lower priority). >> >> Meta-cedartrail has a linux-yocto_3.0.bbappend, but I want to be able to >> enable CONFIG_HID_APPLE in my layer so my Apple keyboard works (and keep >> meta-cedartrail 'clean'). Is it possible to use another >> linux-yocto_3.0.bbappend in my layer? I've given it a try, but it's not >> working and I thought it would be an idea to see if it __should__ before I >> try and fix it ;-) >> >> All bbappends from all layers are applied, in layer priority order. > > Thanks, I was hoping that was the case. > > I wonder why this isn't working then - I think I've done it as shown in the > dev manual... > > Is it something other than the bbappends ? i.e. are you sure you have all the > required > dependencies for CONFIG_HID_APPLE already enabled, or in the same fragment > you are appending ? menuconfig shows that the dependencies are ok. I've got a single fragment referenced using a SRC_URI in the bbappend which sets FILESEXTRAPATHS_prepend. The .cfg file just sets: CONFIG_HID_APPLE=y I can't find my .cfg file in the work area, so it seems as if it's not being picked up. > Bruce > > >> -- >> Christopher Larson > > Chris Tapp > > opensou...@keylevel.com > www.keylevel.com > > > > > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > > > > > -- > "Thou shalt not follow the NULL pointer, for chaos and madness await thee at > its end" Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] meta-cedartrail - install to sdb fails to boot
I've built an image using meta-cedartrail and copied the .hdd image onto a USB drive. Booting the 'install' label install as expected to an mSATA SSD as sda on an Intel DN2800MT board and this boots as expected. However, I need to use an eUSB SSD. The installer detects this as 'sdb' and installs ok, but the system fails to boot with a 'kernel panic' reporting that the root FS can't be found. The grub boot specifies: set root=(hd0,1) ... root=/dev/sdb2 Which looks reasonable. The serial console diagnostics "... here are the available partitions:" entry does not list __any__ partitions. Does this mean that the driver required is currently a module and needs to be configured as a built-in? If so, is there an easy way to work out which one? Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bbappending a bbappend
On 9 Dec 2012, at 16:30, Chris Larson wrote: > On Sun, Dec 9, 2012 at 7:50 AM, Bruce Ashfield > wrote: > On 12-12-09 5:48 AM, Chris Tapp wrote: > On 9 Dec 2012, at 04:47, Bruce Ashfield wrote: > > > > > On Sat, Dec 8, 2012 at 7:54 PM, Chris Tapp <mailto:opensou...@keylevel.com>> wrote: > > On 9 Dec 2012, at 00:11, Chris Larson wrote: > > On Sat, Dec 8, 2012 at 5:07 PM, Chris Tapp > mailto:opensou...@keylevel.com>> wrote: > > Is it possible to have more than one bbappend applied to a > recipe? > > I'm using meta-cedartrail with my own layer (which is set as > lower priority). > > Meta-cedartrail has a linux-yocto_3.0.bbappend, but I want to > be able to enable CONFIG_HID_APPLE in my layer so my Apple > keyboard works (and keep meta-cedartrail 'clean'). Is it > possible to use another linux-yocto_3.0.bbappend in my layer? > I've given it a try, but it's not working and I thought it > would be an idea to see if it __should__ before I try and fix > it ;-) > > > All bbappends from all layers are applied, in layer priority order. > > Thanks, I was hoping that was the case. > > I wonder why this isn't working then - I think I've done it as > shown in the dev manual... > > > Is it something other than the bbappends ? i.e. are you sure you have > all the required > dependencies for CONFIG_HID_APPLE already enabled, or in the same fragment > you are appending ? > > menuconfig shows that the dependencies are ok. I've got a single > fragment referenced using a SRC_URI in the bbappend which sets > FILESEXTRAPATHS_prepend. The .cfg file just sets: > > CONFIG_HID_APPLE=y > > I can't find my .cfg file in the work area, so it seems as if it's not > being picked up. > > I'd suggest putting your .bbappend on a pastebin so we can inspect it. Please see http://pastebin.com/EnesrEN0 > -- > Christopher Larson Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bbappending a bbappend
On 9 Dec 2012, at 16:47, Chris Larson wrote: > > > On Sun, Dec 9, 2012 at 9:44 AM, Chris Tapp wrote: > On 9 Dec 2012, at 16:30, Chris Larson wrote: > >> On Sun, Dec 9, 2012 at 7:50 AM, Bruce Ashfield >> wrote: >> On 12-12-09 5:48 AM, Chris Tapp wrote: >> On 9 Dec 2012, at 04:47, Bruce Ashfield wrote: >> >> >> >> >> On Sat, Dec 8, 2012 at 7:54 PM, Chris Tapp > <mailto:opensou...@keylevel.com>> wrote: >> >> On 9 Dec 2012, at 00:11, Chris Larson wrote: >> >> On Sat, Dec 8, 2012 at 5:07 PM, Chris Tapp >> mailto:opensou...@keylevel.com>> wrote: >> >> Is it possible to have more than one bbappend applied to a >> recipe? >> >> I'm using meta-cedartrail with my own layer (which is set as >> lower priority). >> >> Meta-cedartrail has a linux-yocto_3.0.bbappend, but I want to >> be able to enable CONFIG_HID_APPLE in my layer so my Apple >> keyboard works (and keep meta-cedartrail 'clean'). Is it >> possible to use another linux-yocto_3.0.bbappend in my layer? >> I've given it a try, but it's not working and I thought it >> would be an idea to see if it __should__ before I try and fix >> it ;-) >> >> >> All bbappends from all layers are applied, in layer priority order. >> >> Thanks, I was hoping that was the case. >> >> I wonder why this isn't working then - I think I've done it as >> shown in the dev manual... >> >> >> Is it something other than the bbappends ? i.e. are you sure you have >> all the required >> dependencies for CONFIG_HID_APPLE already enabled, or in the same fragment >> you are appending ? >> >> menuconfig shows that the dependencies are ok. I've got a single >> fragment referenced using a SRC_URI in the bbappend which sets >> FILESEXTRAPATHS_prepend. The .cfg file just sets: >> >> CONFIG_HID_APPLE=y >> >> I can't find my .cfg file in the work area, so it seems as if it's not >> being picked up. >> >> I'd suggest putting your .bbappend on a pastebin so we can inspect it. > > Please see http://pastebin.com/EnesrEN0 > > Did you use bitbake -e linux-yocto | grep SRC_URI= to confirm it's listed > there? I have now - it isn't showing. Any syntax errors in the bbappend are detected, so it looks like it's being processed. > -- > Christopher Larson Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-cedartrail - install to sdb fails to boot
On 9 Dec 2012, at 16:20, Chris Tapp wrote: > I've built an image using meta-cedartrail and copied the .hdd image onto a > USB drive. > > Booting the 'install' label install as expected to an mSATA SSD as sda on an > Intel DN2800MT board and this boots as expected. > > However, I need to use an eUSB SSD. The installer detects this as 'sdb' and > installs ok, but the system fails to boot with a 'kernel panic' reporting > that the root FS can't be found. The grub boot specifies: > > set root=(hd0,1) > > ... root=/dev/sdb2 > > Which looks reasonable. The serial console diagnostics "... here are the > available partitions:" entry does not list __any__ partitions. Does this mean > that the driver required is currently a module and needs to be configured as > a built-in? If so, is there an easy way to work out which one? Adding rootdelay=5 to the kernel command line means the kernel then sees the USB boot device. It is also sda2 (rather than sdb2, as installed), so I also needed to set root=/dev/sda2 Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] meta-cedartrail - where is grub configured for 'install' option?
I am trying to change the 'install' behaviour for the meta-cedartrail image so that the installed system has a different grub.cfg file. Is there a file I can bbappend to achieve this? image_live.bbclass refers to the 'install' syslinux label that triggers the install, but I've not been able to get from this to how/where grub.cfg is created. Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] I think my kernel image just went back in time...
In tmp/deploy/images: 1) bzImage had a timestamp of 2012-12-09 21:49 and the file ended -20121209214459.bin 2) Cleaned the image and the task it contained (to pick up some changes on rebuild) and deleted the image files (.hddimg, etc.) in tmp/deploy/images making sure to leave the kernel files intact. 3) Rebuilt the image. The bzImage now has a timestamp of 2012-12-09 11:13 and the name ends -20121209105420.bin This looks to me like the kernel image has reverted to an earlier one! It is certainly behaving as if this is the case, because a kernel option that I added is no longer in the deployed image... Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bbappending a bbappend
On 9 Dec 2012, at 16:57, Chris Tapp wrote: > > On 9 Dec 2012, at 16:47, Chris Larson wrote: > >> >> >> On Sun, Dec 9, 2012 at 9:44 AM, Chris Tapp wrote: >> On 9 Dec 2012, at 16:30, Chris Larson wrote: >> >>> On Sun, Dec 9, 2012 at 7:50 AM, Bruce Ashfield >>> wrote: >>> On 12-12-09 5:48 AM, Chris Tapp wrote: >>> On 9 Dec 2012, at 04:47, Bruce Ashfield wrote: >>> >>> >>> >>> >>> On Sat, Dec 8, 2012 at 7:54 PM, Chris Tapp >> <mailto:opensou...@keylevel.com>> wrote: >>> >>> On 9 Dec 2012, at 00:11, Chris Larson wrote: >>> >>> On Sat, Dec 8, 2012 at 5:07 PM, Chris Tapp >>> mailto:opensou...@keylevel.com>> wrote: >>> >>> Is it possible to have more than one bbappend applied to a >>> recipe? >>> >>> I'm using meta-cedartrail with my own layer (which is set as >>> lower priority). >>> >>> Meta-cedartrail has a linux-yocto_3.0.bbappend, but I want to >>> be able to enable CONFIG_HID_APPLE in my layer so my Apple >>> keyboard works (and keep meta-cedartrail 'clean'). Is it >>> possible to use another linux-yocto_3.0.bbappend in my layer? >>> I've given it a try, but it's not working and I thought it >>> would be an idea to see if it __should__ before I try and fix >>> it ;-) >>> >>> >>> All bbappends from all layers are applied, in layer priority order. >>> >>> Thanks, I was hoping that was the case. >>> >>> I wonder why this isn't working then - I think I've done it as >>> shown in the dev manual... >>> >>> >>> Is it something other than the bbappends ? i.e. are you sure you have >>> all the required >>> dependencies for CONFIG_HID_APPLE already enabled, or in the same fragment >>> you are appending ? >>> >>> menuconfig shows that the dependencies are ok. I've got a single >>> fragment referenced using a SRC_URI in the bbappend which sets >>> FILESEXTRAPATHS_prepend. The .cfg file just sets: >>> >>> CONFIG_HID_APPLE=y >>> >>> I can't find my .cfg file in the work area, so it seems as if it's not >>> being picked up. >>> >>> I'd suggest putting your .bbappend on a pastebin so we can inspect it. >> >> Please see http://pastebin.com/EnesrEN0 >> >> Did you use bitbake -e linux-yocto | grep SRC_URI= to confirm it's listed >> there? > > I have now - it isn't showing. Any syntax errors in the bbappend are > detected, so it looks like it's being processed. I think I may have worked this out. My bbappend was using SRC_URI. If I change this to SRC_URI_cedartrail then my .cfg is fetched and merged as expected. I was expecting SRC_URI to be used for all machines, but this doesn't seem to be the case. >> -- >> Christopher Larson > > Chris Tapp > > opensou...@keylevel.com > www.keylevel.com > > > > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] libva failing for mp4 using gstreamer under 'danny' with cedartrail BSP
I've got an X application that uses gstreamer to capture frames from video files and display them using GLES textures. This works fine for webm and flv files, but if I try and use mp4 (or avi) then I get no frames. I'm not seeing any gstreamer errors, but the console shows: libva: VA_API version 0.32.1 libva: va_getDriverName() returns 0 libva: Trying to open /usr/lib/dri/pvr_drv_video.so libva: va_openDriver() returns 0 1) I'm building under 'danny' for cedartrail with PVR. 2) The pvr_drv_video.so file mentioned above exists. 3) The same gstreamer pipeline works fine on my host build system. 4) I'm fairly sure the required gstreamer plugins are present. Does anyone have an idea as to what might be causing this? Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] libva failing for mp4 using gstreamer under 'danny' with cedartrail BSP
On 13 Dec 2012, at 21:55, Ross Burton wrote: > On Thursday, 13 December 2012 at 21:10, Chris Tapp wrote: >> I've got an X application that uses gstreamer to capture frames from video >> files and display them using GLES textures. >> >> This works fine for webm and flv files, but if I try and use mp4 (or avi) >> then I get no frames. I'm not seeing any gstreamer errors, but the console >> shows: >> >> libva: VA_API version 0.32.1 >> libva: va_getDriverName() returns 0 >> libva: Trying to open /usr/lib/dri/pvr_drv_video.so >> libva: va_openDriver() returns 0 >> >> 1) I'm building under 'danny' for cedartrail with PVR. >> 2) The pvr_drv_video.so file mentioned above exists. >> 3) The same gstreamer pipeline works fine on my host build system. >> 4) I'm fairly sure the required gstreamer plugins are present. > > To verify (4) which is obviously fairly important, can you confirm that a > simple playbin will play the videos correctly on the CedarTrail? Good catch. This shows there is no video/x-surface decoder available. Off to find which plugin I need... I should have thought of trying that. Thanks! I'll have to find out why my gstreamer error handler isn't spotting the problem! > It's possible that you've got some horrible GLES/VA interaction, specifically > the download from VA-land to however you're getting the video into the > textures. Speaking of which, how are you getting from frames to textures? I'm using appsink to give me access to the raw pixel data which I then glTexSubImage into a texture. I'm using appsink as I've got legacy code that uses it for an SDL app. I may try and switch to gstreamer GL plugin support when I find the best option ;-) > Ross > > Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] libva failing for mp4 using gstreamer under 'danny' with cedartrail BSP
On 13 Dec 2012, at 22:38, Ross Burton wrote: > On Thursday, 13 December 2012 at 22:22, Chris Tapp wrote: >> Good catch. This shows there is no video/x-surface decoder available. Off to >> find which plugin I need... >> >> I should have thought of trying that. Thanks! I'll have to find out why my >> gstreamer error handler isn't spotting the problem! > Yeah… that's a bug I meant to fix in danny-next but failed. Install > gst-plugins-xvimagesink (or something like that, not at my work machines > right now). Thanks, I'll give that a try. >>> It's possible that you've got some horrible GLES/VA interaction, >>> specifically the download from VA-land to however you're getting the video >>> into the textures. Speaking of which, how are you getting from frames to >>> textures? >> I'm using appsink to give me access to the raw pixel data which I then >> glTexSubImage into a texture. I'm using appsink as I've got legacy code that >> uses it for an SDL app. I may try and switch to gstreamer GL plugin support >> when I find the best option ;-) > > There'll be a better way - gstreamer-gl is worth a look at if you can assume > VAAPI you should be able to construct a fairly efficient vaapi-gl pipeline > (with gstreamer 1.0 I believe you'll be able to get zero-copy) I had a quick scan of that the other day and thought it looked like it would be worth a try. I'm hoping to be able to stick with the DN2800MT board for a while, so VAAPI will be available. Zero-copy would be really nice :-) > Ross > > Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] libva failing for mp4 using gstreamer under 'danny' with cedartrail BSP
On 13 Dec 2012, at 22:50, Chris Tapp wrote: > > On 13 Dec 2012, at 22:38, Ross Burton wrote: > >> On Thursday, 13 December 2012 at 22:22, Chris Tapp wrote: >>> Good catch. This shows there is no video/x-surface decoder available. Off >>> to find which plugin I need... >>> >>> I should have thought of trying that. Thanks! I'll have to find out why my >>> gstreamer error handler isn't spotting the problem! >> Yeah… that's a bug I meant to fix in danny-next but failed. Install >> gst-plugins-xvimagesink (or something like that, not at my work machines >> right now). > > Thanks, I'll give that a try. Unfortunately, adding xvimagesink hasn't helped. I also still don't really understand why webm and flv work ok. >>>> It's possible that you've got some horrible GLES/VA interaction, >>>> specifically the download from VA-land to however you're getting the video >>>> into the textures. Speaking of which, how are you getting from frames to >>>> textures? >>> I'm using appsink to give me access to the raw pixel data which I then >>> glTexSubImage into a texture. I'm using appsink as I've got legacy code >>> that uses it for an SDL app. I may try and switch to gstreamer GL plugin >>> support when I find the best option ;-) >> >> There'll be a better way - gstreamer-gl is worth a look at if you can assume >> VAAPI you should be able to construct a fairly efficient vaapi-gl pipeline >> (with gstreamer 1.0 I believe you'll be able to get zero-copy) > > I had a quick scan of that the other day and thought it looked like it would > be worth a try. I'm hoping to be able to stick with the DN2800MT board for a > while, so VAAPI will be available. Zero-copy would be really nice :-) > >> Ross >> >> > > Chris Tapp > > opensou...@keylevel.com > www.keylevel.com > > > > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] libva failing for mp4 using gstreamer under 'danny' with cedartrail BSP
Hi Ross, On 13 Dec 2012, at 23:58, Burton, Ross wrote: > On 13 December 2012 23:23, Chris Tapp wrote: >> Unfortunately, adding xvimagesink hasn't helped. I also still don't really >> understand why webm and flv work ok. > > They're probably using ximagesink, but depending on your pipeline > you're probably doing the decode for mp4 using VAAPI, which has > special requirements on sinks. One question - is that also true for 'fakesink'? I thought that was supposed to accept any format, but it also throws the same error. My pipeline is just uridecodebin ! fakesink > I'd throw in some debugging to inspect the pipelines constructed for flv vs > mp4. > > Ross Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-cedartrail - where is grub configured for 'install' option?
Hi Darren, On 7 Jan 2013, at 16:44, Darren Hart wrote: > On 12/09/2012 01:39 PM, Chris Tapp wrote: >> I am trying to change the 'install' behaviour for the meta-cedartrail image >> so that the installed system has a different grub.cfg file. Is there a file >> I can bbappend to achieve this? >> >> image_live.bbclass refers to the 'install' syslinux label that triggers the >> install, but I've not been able to get from this to how/where grub.cfg is >> created. >> > > This is currently rather crudely implemented here: > > meta/recipes-core/initrdscripts/files/init-install.sh > > A better deployment mechanism is something being discussed and which > should make this more configurable. > > For now, you could bbappend initramfs-live-install_1.0.bb and replace the > init-install.sh script with your own. Thanks. I've already got to look at that script anyway as it fails to install to an internal USB drive on a DN2800-MT board as (I think) it isn't waiting long enough for it to enumerate when booting the 'install' image. > -- > Darren Hart > Intel Open Source Technology Center > Yocto Project - Technical Lead - Linux Kernel Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] I think my kernel image just went back in time...
On 7 Jan 2013, at 16:26, Darren Hart wrote: > > > On 12/21/2012 10:17 AM, Tomas Frydrych wrote: >> On 09/12/12 23:17, Chris Tapp wrote: >>> In tmp/deploy/images: >>> >>> 1) bzImage had a timestamp of 2012-12-09 21:49 and the file ended >>> -20121209214459.bin >>> >>> 2) Cleaned the image and the task it contained (to pick up some >>> changes on rebuild) and deleted the image files (.hddimg, etc.) in >>> tmp/deploy/images making sure to leave the kernel files intact. >> >> Did you cleansstate it? I find that without cleaning the state kernel >> image gets always pulled out of sstate rather than properly rebuilt. It was a while back now and I can't recall for sure. I'm 99.9% certain I used -c cleanall on the image. >> Tomas > > Do you still experience this on the master branch? I've not had a chance to try and I can't remember the exact steps to reproduce it. I've only seen this happen once for the same work-flow. > -- > Darren Hart > Intel Open Source Technology Center > Yocto Project - Technical Lead - Linux Kernel > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-cedartrail - where is grub configured for 'install' option?
On 10 Jan 2013, at 17:15, Darren Hart wrote: > > > On 01/10/2013 12:09 AM, Chris Tapp wrote: >> Hi Darren, >> >> On 7 Jan 2013, at 16:44, Darren Hart wrote: >> >>> On 12/09/2012 01:39 PM, Chris Tapp wrote: >>>> I am trying to change the 'install' behaviour for the meta-cedartrail >>>> image so that the installed system has a different grub.cfg file. Is there >>>> a file I can bbappend to achieve this? >>>> >>>> image_live.bbclass refers to the 'install' syslinux label that triggers >>>> the install, but I've not been able to get from this to how/where grub.cfg >>>> is created. >>>> >>> >>> This is currently rather crudely implemented here: >>> >>> meta/recipes-core/initrdscripts/files/init-install.sh >>> >>> A better deployment mechanism is something being discussed and which >>> should make this more configurable. >>> >>> For now, you could bbappend initramfs-live-install_1.0.bb and replace the >>> init-install.sh script with your own. >> >> Thanks. I've already got to look at that script anyway as it fails to >> install to an internal USB drive on a DN2800-MT board as (I think) it >> isn't waiting long enough for it to enumerate when booting the >> 'install' image. > > Hrm, I thought it waited indefinitely for the device to appear. Or is it > finding something else and bailing out of the loop? Where is the failure? The only other device is the USB drive I booted from. I've not had a chance yet to really look at what's going on, but it looks as if it's not waiting long enough as it reports no installable devices. If I then check when it exits to the shell I can see the drive is there and re-running the script then means it does find it (the script then fails for other reasons to do with the failed run). It will sometimes install, so it looks as if the wait is nearly long enough. I'm using an ATP AF512SSGH if that makes a difference. BTW the change I need to make to the grub file is partially related - the boot device is sda and the internal (install target) is sdb. Grub gets configured to boot from sdb but the device is sda on a clean boot. > -- > Darren Hart > Intel Open Source Technology Center > Yocto Project - Technical Lead - Linux Kernel Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/1][linux-yocto] Remove Cedartrail Machine
On 8 Feb 2013, at 23:18, kishore.k.bo...@intel.com wrote: > From: Kishore Bodke > > > Hi, > > This patch set is to remove the Cedartail Machine from > Linux-yocto-3.4 Kernel. > Cedartrail BSP will not be supported for Yocto 1.4 Release. Hi Kishore, Are there any plans to bring support back in? We recently committed a project to using this BSP for the Intel DN2800MT... > Also Please remove the standard/cedartrail branch. > > Please pull into linux-yocto-3.4/meta branch. > > Thanks > Kishore. > > The following changes since commit f697e099bc76d5df3a307a5bc0cc25021dd6dfe0: > > meta: bump to v3.4.28, rt-40 (2013-02-04 00:14:21 -0500) > > are available in the git repository at: > > git://git.pokylinux.org/linux-yocto-contrib kishore/cedartrail_remove > > http://git.pokylinux.org/cgit.cgi/linux-yocto-contrib/log/?h=kishore/cedartrail_remove > > Kishore Bodke (1): > meta: Remove Cedartrail Machine > > .../bsp/cedartrail/cedartrail-preempt-rt.scc | 13 -- > .../bsp/cedartrail/cedartrail-standard.scc |8 > .../cfg/kernel-cache/bsp/cedartrail/cedartrail.cfg | 46 > .../cfg/kernel-cache/bsp/cedartrail/cedartrail.scc | 15 --- > 4 files changed, 82 deletions(-) > delete mode 100755 > meta/cfg/kernel-cache/bsp/cedartrail/cedartrail-preempt-rt.scc > delete mode 100755 > meta/cfg/kernel-cache/bsp/cedartrail/cedartrail-standard.scc > delete mode 100755 meta/cfg/kernel-cache/bsp/cedartrail/cedartrail.cfg > delete mode 100644 meta/cfg/kernel-cache/bsp/cedartrail/cedartrail.scc > > -- > 1.7.9.5 > > _______ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/1][linux-yocto] Remove Cedartrail Machine
Hi Song / Kishore, On 11 Feb 2013, at 18:47, Liu, Song wrote: > Hi Chris, > > Intel is still supporting critical fixes for the Cedar Trail BSP on Yocto > Project 1.3 release. If you need additional support for your project, I can > connect you with some Intel sales/support people who can help. At the same > time, would you be able to share more information about your project with me? > It will help when I ask them for additional support. Thanks, that's good news. The only slight down side from my perspective is we won't get the benefits from 1.4 (and future) improvements. However, it will give me an excuse to move the hardware on as new platforms become available ;-) > Song > > -Original Message- > From: Chris Tapp [mailto:opensou...@keylevel.com] > Sent: Saturday, February 09, 2013 1:33 AM > To: Bodke, Kishore K > Cc: bruce.ashfi...@windriver.com; dvh...@linux.intel.com; Saxena, Rahul; Liu, > Song; Zanussi, Tom; linux-yo...@yoctoproject.org; yocto@yoctoproject.org > Subject: Re: [yocto] [PATCH 0/1][linux-yocto] Remove Cedartrail Machine > > > On 8 Feb 2013, at 23:18, kishore.k.bo...@intel.com wrote: > >> From: Kishore Bodke >> >> >> Hi, >> >> This patch set is to remove the Cedartail Machine from >> Linux-yocto-3.4 Kernel. >> Cedartrail BSP will not be supported for Yocto 1.4 Release. > > Hi Kishore, > > Are there any plans to bring support back in? We recently committed a project > to using this BSP for the Intel DN2800MT... > >> Also Please remove the standard/cedartrail branch. >> >> Please pull into linux-yocto-3.4/meta branch. >> >> Thanks >> Kishore. >> >> The following changes since commit f697e099bc76d5df3a307a5bc0cc25021dd6dfe0: >> >> meta: bump to v3.4.28, rt-40 (2013-02-04 00:14:21 -0500) >> >> are available in the git repository at: >> >> git://git.pokylinux.org/linux-yocto-contrib kishore/cedartrail_remove >> http://git.pokylinux.org/cgit.cgi/linux-yocto-contrib/log/?h=kishore/c >> edartrail_remove >> >> Kishore Bodke (1): >> meta: Remove Cedartrail Machine >> >> .../bsp/cedartrail/cedartrail-preempt-rt.scc | 13 -- >> .../bsp/cedartrail/cedartrail-standard.scc |8 >> .../cfg/kernel-cache/bsp/cedartrail/cedartrail.cfg | 46 >> >> .../cfg/kernel-cache/bsp/cedartrail/cedartrail.scc | 15 --- >> 4 files changed, 82 deletions(-) >> delete mode 100755 >> meta/cfg/kernel-cache/bsp/cedartrail/cedartrail-preempt-rt.scc >> delete mode 100755 >> meta/cfg/kernel-cache/bsp/cedartrail/cedartrail-standard.scc >> delete mode 100755 meta/cfg/kernel-cache/bsp/cedartrail/cedartrail.cfg >> delete mode 100644 meta/cfg/kernel-cache/bsp/cedartrail/cedartrail.scc >> >> -- >> 1.7.9.5 >> >> ___ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto > > Chris Tapp > > opensou...@keylevel.com > www.keylevel.com > > > Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/1][linux-yocto] Remove Cedartrail Machine
On 12 Feb 2013, at 20:54, Burton, Ross wrote: > On 12 February 2013 19:56, Tom Zanussi wrote: >> It probably wouldn't take much to bring it back - basically the pvr >> graphics driver, which I assume is one of the most important features of >> this BSP for users, is stuck at kernel version 3.0. If everything else >> stayed the same, forward-porting the GPL'ed kernel portion of the driver >> would be all that would be needed to get it working again. We've done >> that routinely for other drivers such as EMGD, so I don't think that >> would be too big a deal. > > Alternatively there's the fully open source but non-accelerated > graphics drivers. This would let the BSP survive, but is anyone > (Chris, I'm looking at you here!) using CDT in a situation where the > open 2D driver is sufficient? Not me ;-) One of the main reasons I moved 'here' was because we needed the graphics performance. > Ross Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/1][linux-yocto] Remove Cedartrail Machine
On 12 Feb 2013, at 19:56, Tom Zanussi wrote: > On Mon, 2013-02-11 at 22:02 -0800, Sean Liming wrote: >> >>> -Original Message- >>> From: yocto-boun...@yoctoproject.org [mailto:yocto- >>> boun...@yoctoproject.org] On Behalf Of Liu, Song >>> Sent: Monday, February 11, 2013 1:25 PM >>> To: Chris Tapp >>> Cc: Darren Hart; Yocto Discussion Mailing List >>> Subject: Re: [yocto] [PATCH 0/1][linux-yocto] Remove Cedartrail Machine >>> >>> Thanks for the reply, Chris! Feel free to let us know if you have any >>> questions. Hope your project will go well. >>> >>> Song >>> >>> -Original Message- >>> From: Chris Tapp [mailto:opensou...@keylevel.com] >>> Sent: Monday, February 11, 2013 1:17 PM >>> To: Liu, Song >>> Cc: Bodke, Kishore K; Bruce Ashfield; Darren Hart; Saxena, Rahul; Zanussi, >>> Tom; Yocto Discussion Mailing List >>> Subject: Re: [yocto] [PATCH 0/1][linux-yocto] Remove Cedartrail Machine >>> >>> Hi Song / Kishore, >>> >>> On 11 Feb 2013, at 18:47, Liu, Song wrote: >>> >>>> Hi Chris, >>>> >>>> Intel is still supporting critical fixes for the Cedar Trail BSP on >> Yocto Project >>> 1.3 release. If you need additional support for your project, I can >> connect you >>> with some Intel sales/support people who can help. At the same time, would >>> you be able to share more information about your project with me? It will >>> help when I ask them for additional support. >>> >>> Thanks, that's good news. >>> >>> The only slight down side from my perspective is we won't get the benefits >>> from 1.4 (and future) improvements. However, it will give me an excuse to >>> move the hardware on as new platforms become available ;-) >>> >>> >>>> Song >>>> >>>> -Original Message- >>>> From: Chris Tapp [mailto:opensou...@keylevel.com] >>>> Sent: Saturday, February 09, 2013 1:33 AM >>>> To: Bodke, Kishore K >>>> Cc: bruce.ashfi...@windriver.com; dvh...@linux.intel.com; Saxena, >>>> Rahul; Liu, Song; Zanussi, Tom; linux-yo...@yoctoproject.org; >>>> yocto@yoctoproject.org >>>> Subject: Re: [yocto] [PATCH 0/1][linux-yocto] Remove Cedartrail >>>> Machine >>>> >>>> >>>> On 8 Feb 2013, at 23:18, kishore.k.bo...@intel.com wrote: >>>> >>>>> From: Kishore Bodke >>>>> >>>>> >>>>> Hi, >>>>> >>>>> This patch set is to remove the Cedartail Machine from >>>>> Linux-yocto-3.4 Kernel. >>>>> Cedartrail BSP will not be supported for Yocto 1.4 Release. >>>> >>>> Hi Kishore, >>>> >>>> Are there any plans to bring support back in? We recently committed a >>> project to using this BSP for the Intel DN2800MT... >>>> >>>>> Also Please remove the standard/cedartrail branch. >>>>> >>>>> Please pull into linux-yocto-3.4/meta branch. >>>>> >>>>> Thanks >>>>> Kishore. >>>>> >>>>> The following changes since commit >>> f697e099bc76d5df3a307a5bc0cc25021dd6dfe0: >>>>> >>>>> meta: bump to v3.4.28, rt-40 (2013-02-04 00:14:21 -0500) >>>>> >>>>> are available in the git repository at: >>>>> >>>>> git://git.pokylinux.org/linux-yocto-contrib kishore/cedartrail_remove >>>>> http://git.pokylinux.org/cgit.cgi/linux-yocto-contrib/log/?h=kishore/ >>>>> c >>>>> edartrail_remove >>>>> >>>>> Kishore Bodke (1): >>>>> meta: Remove Cedartrail Machine >>>>> >>>>> .../bsp/cedartrail/cedartrail-preempt-rt.scc | 13 -- >>>>> .../bsp/cedartrail/cedartrail-standard.scc |8 >>>>> .../cfg/kernel-cache/bsp/cedartrail/cedartrail.cfg | 46 >> >>>>> .../cfg/kernel-cache/bsp/cedartrail/cedartrail.scc | 15 --- >>>>> 4 files changed, 82 deletions(-) >>>>> delete mode 100755 >>>>> meta/cfg/kernel-cache/bsp/cedartrail/cedartrail-preempt-rt.scc >>>>> delete mode 100755 >>>>> meta/cfg/kernel-cache/bsp/cedartrail/cedartrail-standard.scc >>>>> delete mo
[yocto] Licencing OpenSource fonts
Sorry if this is off-topic for this list, but I'm hoping that someone on here may be able to help with a licensing question. I am working on a document which is to be published using the Google 'Open Sans' font. This is licensed under an Apache Licence. The licence lists all the 'usual' things to do when distributing / modifying the font, but it doesn't say what to do if the font is used. We plan to add something like "This document was typeset using OpenSans; this font is distributed under the terms of the Apache licence — see www.apache.org/licenses/LICENSE-2.0.html" to the acknowledgements section of the document. Would we need to go further than this? Any pointers would be greatly appreciated! Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Licencing OpenSource fonts
On 8 Mar 2013, at 10:18, Chris Tapp wrote: > Sorry if this is off-topic for this list, but I'm hoping that someone on here > may be able to help with a licensing question. > > I am working on a document which is to be published using the Google 'Open > Sans' font. This is licensed under an Apache Licence. > > The licence lists all the 'usual' things to do when distributing / modifying > the font, but it doesn't say what to do if the font is used. > > We plan to add something like "This document was typeset using OpenSans; this > font is distributed under the terms of the Apache licence — see > www.apache.org/licenses/LICENSE-2.0.html" to the acknowledgements section of > the document. Would we need to go further than this? In the 7 hours it's taken this to get to the list (no ideas where it got stuck!) we've changed our words to reflect the information in the font itself: "This document was typeset using Open Sans. Open Sans is a trademark of Google and may be registered in certain jurisdictions. Digitized data copyright © 2010-2011, Google Corporation. Licensed under the Apache License, Version 2.0" Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Possible Cedartrail PVR build race
I think I have a build race condition for a project: 1) Using the meta-intel/cedartrail BSP; 2) Building under Danny 8.0; 3) Custom image; 4) Custom task; 5) OpenGLES application which runs under 'X'. If I do a clean build (i.e. after deleting tmp/ sstate-cache/) then my application produces 'fuzz' on the screen - some vertical strips visible, but nothing recognisable. If I then 'cleanall' the image, task and application and rebuild the image I get an image with an application that works as expected. I suspect this is something to do with some warning messages I get during the clean build: WARNING: The recipe is trying to install files into a shared area when those files already exist. Those files are: /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/KHR/khrplatform.h /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/GLES/gl.h /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/GLES/egl.h /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/GLES/glext.h /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/GLES/glplatform.h /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/EGL/egl.h /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/EGL/eglplatform.h /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/EGL/eglext.h /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/GLES2/gl2platform.h /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/GLES2/gl2.h /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/GLES2/gl2ext.h /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/lib/libGLESv1_CM.so /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/lib/libGLESv2.so.2 /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/lib/libGLESv2.so /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/lib/libGLESv1_CM.so.1 /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/lib/libEGL.so.1 /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/lib/libEGL.so Is there something I can add to my image/task/application .bb to prevent this? Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Possible Cedartrail PVR build race
Hi Ross, On 21 Mar 2013, at 09:09, Burton, Ross wrote: > On 21 March 2013 09:01, Chris Tapp wrote: >> I think I have a build race condition for a project: >> >> 1) Using the meta-intel/cedartrail BSP; >> 2) Building under Danny 8.0; >> 3) Custom image; >> 4) Custom task; >> 5) OpenGLES application which runs under 'X'. >> >> If I do a clean build (i.e. after deleting tmp/ sstate-cache/) then my >> application produces 'fuzz' on the screen - some vertical strips visible, >> but nothing recognisable. >> >> If I then 'cleanall' the image, task and application and rebuild the image I >> get an image with an application that works as expected. >> >> I suspect this is something to do with some warning messages I get during >> the clean build: >> >> WARNING: The recipe is trying to install files into a shared area when those >> files already exist. Those files are: >> >> /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/KHR/khrplatform.h >> >> /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/GLES/gl.h >> >> /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/GLES/egl.h >> >> /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/GLES/glext.h >> >> /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/GLES/glplatform.h >> >> /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/EGL/egl.h >> >> /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/EGL/eglplatform.h >> >> /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/EGL/eglext.h >> >> /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/GLES2/gl2platform.h >> >> /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/GLES2/gl2.h >> >> /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/GLES2/gl2ext.h >> >> /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/lib/libGLESv1_CM.so >> >> /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/lib/libGLESv2.so.2 >> >> /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/lib/libGLESv2.so >> >> /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/lib/libGLESv1_CM.so.1 >> >> /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/lib/libEGL.so.1 >> >> /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/lib/libEGL.so >> >> Is there something I can add to my image/task/application .bb to prevent >> this? > > If you were using master you'd see some more useful output, such as > the recipes that are conflicting. I'm 99% certain that in this case > it's pvr-cdt-driver and mesa-dri. On CDT you really don't want > mesa-dri. > > I suspect this is coming through the xserver-xorg package which > defaults to enabling GLX, which requires mesa-dri. Inspecting your > dependency tree with depexp should confirm this. Presumably your GLES > application is using EGL and not GLX? > > I'm always forgetting the exact syntax here, but try setting > PACKAGECONFIG_pn-xserver-xorg = "udev" in your local.conf. This > should disable the glx options, and drop the mesa-dri dependency. Thanks, that's helped a bit. depexp was showing: xserver-xorg, libva, mesa-dri, packagegroup-core-x11-xserver. Your setting gets rid of 'xserver-xorg' and I assume 'mesa-dri' will go when mesa-dri isn't needed. So, that just leaves libva and the packagegroup. > Ross Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] No keyboard in X
I've got a system (Danny, meta-intel-cedartrail) with a custom /etc/mini_x/session file which is used to run an application at startup. This all works to the extent that the application starts and runs, but the keyboard doesn't work - 'Esc' should cause the application to terminate and the X session to end. The Xorg log shows that the session is "Using VT number 2". If I kill the session manually, login on the tty and restart (using 'init 4', 'init 5') then the application runs as before but this time the keyboard works as expected. inittab runs a getty on tty1 to tty4. Any idea what's going on here? Is it because tty2 isn't active when X starts, or is it something like a permissions problem which means the keyboard can't be used until a user is authenticated on the VT that's being used? Would running the X session on the tty0 (console) work? If so, how can I force it to be used? Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] No keyboard in X
On 21 Mar 2013, at 20:38, Tomas Frydrych wrote: > On 21/03/13 20:11, Chris Tapp wrote: >> I've got a system (Danny, meta-intel-cedartrail) with a custom >> /etc/mini_x/session file which is used to run an application at >> startup. >> >> This all works to the extent that the application starts and runs, >> but the keyboard doesn't work - 'Esc' should cause the application to >> terminate and the X session to end. The Xorg log shows that the >> session is "Using VT number 2". >> >> If I kill the session manually, login on the tty and restart (using >> 'init 4', 'init 5') then the application runs as before but this time >> the keyboard works as expected. >> >> inittab runs a getty on tty1 to tty4. > > Could be permissions; if you are not starting X as root, you have to > make sure the X user has rw permissions to /dev/ttyN and /dev/input/* Looking at the S09xserver-nodm script in rc5.d, it's started using: su -l -c '/etc/X11/Xserver&' $username where 'username' is set to 'root', so it looks like that should be ok. Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Possible Cedartrail PVR build race
On 21 Mar 2013, at 19:22, Chris Tapp wrote: > Hi Ross, > > On 21 Mar 2013, at 09:09, Burton, Ross wrote: > >> On 21 March 2013 09:01, Chris Tapp wrote: >>> I think I have a build race condition for a project: >>> >>> 1) Using the meta-intel/cedartrail BSP; >>> 2) Building under Danny 8.0; >>> 3) Custom image; >>> 4) Custom task; >>> 5) OpenGLES application which runs under 'X'. >>> >>> If I do a clean build (i.e. after deleting tmp/ sstate-cache/) then my >>> application produces 'fuzz' on the screen - some vertical strips visible, >>> but nothing recognisable. >>> >>> If I then 'cleanall' the image, task and application and rebuild the image >>> I get an image with an application that works as expected. >>> >>> I suspect this is something to do with some warning messages I get during >>> the clean build: >>> >>> WARNING: The recipe is trying to install files into a shared area when >>> those files already exist. Those files are: >>> >>> /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/KHR/khrplatform.h >>> >>> /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/GLES/gl.h >>> >>> /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/GLES/egl.h >>> >>> /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/GLES/glext.h >>> >>> /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/GLES/glplatform.h >>> >>> /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/EGL/egl.h >>> >>> /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/EGL/eglplatform.h >>> >>> /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/EGL/eglext.h >>> >>> /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/GLES2/gl2platform.h >>> >>> /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/GLES2/gl2.h >>> >>> /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/GLES2/gl2ext.h >>> >>> /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/lib/libGLESv1_CM.so >>> >>> /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/lib/libGLESv2.so.2 >>> >>> /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/lib/libGLESv2.so >>> >>> /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/lib/libGLESv1_CM.so.1 >>> >>> /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/lib/libEGL.so.1 >>> >>> /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/lib/libEGL.so >>> >>> Is there something I can add to my image/task/application .bb to prevent >>> this? >> >> If you were using master you'd see some more useful output, such as >> the recipes that are conflicting. I'm 99% certain that in this case >> it's pvr-cdt-driver and mesa-dri. On CDT you really don't want >> mesa-dri. >> >> I suspect this is coming through the xserver-xorg package which >> defaults to enabling GLX, which requires mesa-dri. Inspecting your >> dependency tree with depexp should confirm this. Presumably your GLES >> application is using EGL and not GLX? >> >> I'm always forgetting the exact syntax here, but try setting >> PACKAGECONFIG_pn-xserver-xorg = "udev" in your local.conf. This >> should disable the glx options, and drop the mesa-dri dependency. > > Thanks, that's helped a bit. depexp was showing: > > xserver-xorg, libva, mesa-dri, packagegroup-core-x11-xserver. > > Your setting gets rid of 'xserver-xorg' and I assume 'mesa-dri' will go when > mesa-dri isn't needed. > > So, that just leaves libva and the packagegroup. The packagegroup is a problem: | error: Failed dependencies: | xserver-xorg-extension-glx is needed by packagegroup-core-x11-xserver-1.0-r39.cedartrail | xserver-xorg-extension-dri is needed by packagegroup-core-x11-xserver-1.0-r39.cedartrail | ERROR: Function failed: do_rootfs (see /media/SSD-RAID/build-danny-cedartrail/tmp/work/cedartrail-poky-linux/opty4gles-image-1.0-r0/temp/log.do_rootfs.10973 for further information) Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problem creating bootable flash
Hi Paul, On 22 Mar 2013, at 07:25, Paul D. DeRocco wrote: > I've successfully (theoretically) built core-image-base-cedartrail-nopvr. I > plugged a 1GB eUSB SSD onto one of my USB headers, Ubuntu automounted the > empty drive /dev/sdb1 as /media/somethingorother, I unmounted it, and then > followed the instructions on the Yocto page for the cedartrail BSP: I used > dd to copy the image to /dev/sdb1, synced, ejected it, and rebooted. I got > the dreaded "Error loading operating system" from the BIOS. > > Waitaminnit, I thought, isn't this image supposed to include the partition > table, too? After all, the example given in the instructions showed the > image being copied to /dev/sdf, not sdf1. I went back into Ubuntu, saw that > /dev/sdb1 had been mounted as /mnt/boot_, and it contained initrd and the > four other files. I unmounted it, and this time used dd to copy the image to > /dev/sdb, synced, ejected it, and rebooted. This time, the BIOS wouldn't > recognize the drive at all, so all I could do was go back into Ubuntu. > > Now, Ubuntu had mounted /dev/sdb as /mnt/boot_, and it still contained the > five files. That suggests to me that the image doesn't contain a partition > table, and that there is now no partition table on this drive, just a single > file system, like an old floppy. I ran parted, end it says the partition > table type is "loop", with a single FAT16 partition running from 0.00B to > 1028MB, the entire drive. Is "loop" just a name for an implied partition > table that lists the entire drive, when there is no actual table? > > Apparently, my BIOS (a modern Intel D2700MUD Atom mobo) looks at this USB > drive and decides it isn't bootable. So what's the right way to do this? I've had a few issues using the Cedartrail PRV images on an eUSB drive on an DN2800MT. I'm not installing the same way as you: 1) I use dd to copy the hddimg to a USB stick; 2) I use this to boot the system using the 'install' syslinux item (have to be quick at boot time to catch the prompt). Everything worked great using a mini-PCIe drive, but was failing to install to the eUSB most of the time as the drive wasn't detected - I expect it takes too long to be ready before the install script gives up. A couple of changes to the script fixed this and the image would then install. However, it wouldn't boot. I found two issues: 1) The install script configured grub to use sdb. This was where the eUSB was when the script ran, but it's sda when used as the boot device. Another install script fixed this. 2) I also needed to add 'rootwait' to the kernel command line or else the rootfs wasn't ready at boot time, resulting in a kernel panic. The issues with the installer are recorded in the bug tracker at https://bugzilla.yoctoproject.org/show_bug.cgi?id=4059. It's possible that you may need 'rootwait', but I'm not sure anything else that I found is related to what you're seeing. Can you try dd'ing the image on to a USB stick to see if that will boot? If it does, that would at least show that the image is good and it's the eUSB that is causing the pain, as it was for me. Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Need help understanding GLES segfault on Cedartrail
I've got some code that uses gstreamer to capture video frames (using appsink) and then render them to the screen using textures under GLES. The code basically does: 1) Grab image; 2) Use one call per image row to glTexSubImage2D to update the texture 3) Render the texture to a quad. Sometime this runs ok (for weeks). Sometimes it crashes. When it crashes a segfault is thrown in openGLES.so (using PRV drivers). It looks as if this happens in the call to glTexSubImage2D. I also suspect that some calls never return. I've found that I need to add a call to glFinish() after the call to glTexSubImage2D. If I don't, some of the lines are sometimes filled with 'static'. To me this looks like some sort of memory/timing issue. Do I need to perform some sort of manual GPU/CPU synchronisation? Adding significant amounts of diagnostic output (to std::cerr) makes the problem a heisenbug! Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Perplexed by boot mechanism
On 22 Mar 2013, at 23:05, Paul D. DeRocco wrote: > I'm trying to get a core-image-base-cedartrail-nopvr image to boot from an > eUSB SSD on an Intel Atom mobo. I'm following the instructions in > > <https://www.yoctoproject.org/download/intel-atom-n2600n2800d2550-wnm10-chip > set-cedar-trail> > > which tell me to dd the .hddimg file onto the flash drive. But apparently, > the image isn't an image of a regular bootable system drive, but is a "live > image" of a smaller system that can either boot the real system from a > virtualized file system in RAM whose image is read from a single file in the > first level, or it can install the real system to a different drive. > (Correct me if I'm mistaken about any of this.) > > What's the point of all this? It seems like a completely unnecessary layer > of complexity and inefficiency. I have a very vague understanding of the > whole concept of running a live image off a virtual file system, and it > seems to make sense when you're booting off a readonly medium like a DVD, > but this is a writable flash drive. Why doesn't the .hddimg file just > contain the real target root file system partition in it? Or is that what > some of those other files in the build/tmp/deploy/images directory > represent? If the latter, is there a way I can just directly create the > flash drive the way it will ultimately be used in the final system, without > using this "live image" stuff? > > I'd really like to be able to create the flash, mount it under Ubuntu, and > not see the five files the implement the live image, but see the full root > file system of my target. Have a look at meta/recipes-core/initrdscripts/files/init-install.sh. This shows how the 'install' boot option of the 'live usb image' gives exactly what you want. It basically: 1) Partitions the eUSB; 2) Copies the root filesystem (one of you five files) to the eUSB (given the caveats I mentioned in my last message); 3) Installs and configures grub to boot this. The live image is a quick way to get a system up and running. It allows someone to 'try stuff' and still get back to a working system if they make an error. It's 'install' option allows you to install to a target in a more conventional way - i.e. with all the files/directories you are expecting to see. I use the live usb image to install my images to target hardware. I've modified the script so I can also use it to install to a sequence of eUSB drives that I plug into an external adaptor when I need to program a load for a production run. Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problem creating bootable flash
Hi Paul, On 29 Mar 2013, at 23:15, Paul D. DeRocco wrote: > I'm still having no luck booting my system. I've built > core-image-base-cedartrail-nopvr, with only one modification (added samba > from OE), and I'm trying to boot it on an Intel DN2800MT mobo from a 1GB > eUSB SSD. Here's what I've done: > > Opened gparted, selected /dev/sdb, which is the SSD. > > Created a fresh MSDOS partition table. > > Selected the 979MB unallocated space, created a new 949MB FAT16 partition. > > Selected the remaining 30MB unallocated space, created a new FAT16 > partition, which will hold my application data. > > Invoked the pending operations. > > Selected the first partition, set the "boot" flag. > > Exited gparted. > > In terminal, went into my images directory, and did > >sudo dd if=core-image-base-cedartrail-nopvr.hddimg of=/dev/sdb1 This should end of=/dev/sdb The hddimg file includes the partition info and both partitions, so you don't need any of the other steps. > After a few seconds, it finished. I'm assuming you did a 'sync' or similar at this point. > I then unplugged and plugged the SSD from > the USB header, and it automounted the two partitions and popped up two > windows showing their contents. Closed the second one, and examined the > first one. It contained the usual five files for booting a live image. > > Opened syslinux.cfg in an editor. It showed that syslinux is configured to > use a serial port, which is wrong for my system. Also, it showed two boot > choices, one called "boot" for running the live image, and the other called > "install". > > Eventually, I'll get the build to supply a custom syslinux.cfg, but for now, > I figured I'd just manually edit it. Since I want it to interact with the > screen and keyboard, and not a serial port, I removed "serial 1 115200". The > default is supposedly "console 1", which I would expect would use the video > and keyboard from the text mode it inherits from the BIOS. I also removed > the "install" section. > > The options on the minimal boot kernel included "console=ttyS0,115200" and > "console=tty0 video=vesafb vga=0x318". Since I don't know what my mobo > supports for VGA video, I figured I'd just let it use text mode, so I > replaced them both with just "console=tty0". The final contents of > syslinux.cfg were: > >ALLOWOPTIONS 1 >DEFAULT boot >TIMEOUT 10 >PROMPT 1 >LABEL boot >KERNEL /vmlinuz >APPEND initrd=/initrd LABEL=boot root=/dev/ram0 console=tty0 > > I did a "Safely remove" on the device, unplugged it, plugged it into my test > motherboard, and fired it up. > > I went into the BIOS boot menu, to make sure the BIOS recognized it as a > bootable device, and it did. I hit Enter to boot it. All I got was a > standard black VGA text mode screen with a blinking gray cursor. At that > point, Ctrl-Alt-Del wouldn't reboot. > > If my device wasn't bootable, I'd expect the BIOS to complain. If it was > still in the BIOS, I'd expect to be able to reboot with Ctrl-Alt-Del. If it > actually ran ldlinux.sys, and yet didn't properly use the video, I'd expect > it to time out and boot the live image. But I don't see any evidence that > it's doing that. I think you've got a bootable device because you configured it to be, above. You shouldn't need to do this as the 'dd' should set it all up for you. > > Does my syslinux.cfg look correct for showing the syslinux stuff on the text > mode output? Do my kernel options look correct for getting the live image > boot kernel to talk to the screen in text mode? Can anyone see anything else > that might be wrong? > > -- > > Ciao, Paul D. DeRocco > Paulmailto:pdero...@ix.netcom.com > > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to partition a flash drive (was: Problem creating bootable flash)
Hi Paul, On 1 Apr 2013, at 05:16, Paul D. DeRocco wrote: >> From: Chris Tapp >> >> This should end >> of=/dev/sdb >> >> The hddimg file includes the partition info and both >> partitions, so you don't need any of the other steps. > > Actually, the .hddimg is a single FAT16 volume, with no partition table, > which contains files for creating a couple of different RAM disk images, > which are part of the live-image mechanism. Sorry, I was trying to do too many things late at night! I confused myself with the image created using the 'install' boot option ;-) > I am leaning toward using this live-image mechanism in my project > permanently, because it almost eliminates the possibility of anything > corrupting the OS in any persistent way. My application does have a small > amount of persistent data, and I don't want to use the union or overlay file > system as a way of adding persistence to the live image, because that sort > of defeats the security of the live image. So I do indeed want to use a > truly partitioned flash drive, and put my application data on a separate > small partition. Good choice, as unionfs isn't supported in the 3.0 kernel in Yocto. I've used it before to give persistence using a read-only partition with some scripts to make it writeable to allow configuration files (etc) to be updated whilst still giving a decent level of protection. > > What's going wrong is that the code in the MBR created by gparted (and I > assume by parted) unconditionally uses drive number 0x80 (the first hard > disk) when it tries to load the zeroth sector from the bootable partition. > The BIOS, however, is treating this eUSB SSD as a removable drive, and > calling it drive zero. So it's crashing at the point where the MBR code > jumps to what is supposed to be the zeroth sector of the partition. > > The code in the boot sector for the FAT16 volume uses whatever drive number > is in the DL register on entry, and this works fine when booting directly > from the BIOS into this code with no intervening MBR, so the solution is to > modify the MBR boot code to do the same thing. This simply involves NOP-ing > out the MOV DL, 80H instruction. Then, it should successfully boot a > partitioned flash drive as though it were a hard disk. > > -- > > Ciao, Paul D. DeRocco > Paulmailto:pdero...@ix.netcom.com > > Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Disabling udev NIC renaming
I use a USB drive to boot systems for testing and to install the image. This works ok for the first, but 'eth0' gets renamed to 'eth1' on the second system (etc). Is there an option I can set to stop udev creating rules which result in the NIC name changing, or should I just add an empty /etc/udev/rules.d/75-peristent-net-generator.rules file to my image? Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Disabling udev NIC renaming
Hi Khem, On 16 Jun 2013, at 21:05, Khem Raj wrote: > On Sun, Jun 16, 2013 at 4:09 AM, Chris Tapp wrote: >> I use a USB drive to boot systems for testing and to install the image. This >> works ok for the first, but 'eth0' gets renamed to 'eth1' on the second >> system (etc). >> >> Is there an option I can set to stop udev creating rules which result in the >> NIC name changing, or should I just add an empty >> >> /etc/udev/rules.d/75-peristent-net-generator.rules >> >> file to my image? > > thats one way. If you are using systemd then systemd already have the > feature to use persistent IF names. see > http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ Thanks, that's useful into. I've not got systemd yet, but that certainly looks like the way to go. >> >> Chris Tapp >> >> opensou...@keylevel.com >> www.keylevel.com >> >> >> >> ___ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Danny/Cedartrail psplash not showing
I've got a custom Cedartrail image which works great, but I can't get the psplash screen to show on boot. I see a message like "cannot mmap framebuffer" scroll up the screen, but this isn't in the message log so I don't get the full context. I've tried looking at the code for pspash-fb.c, but there aren't a lot of clues (for me!). Is this something to do with the pixel format, as hinted at by the comment referring to 'line_length'? Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Danny/Cedartrail psplash not showing
On 16 Jun 2013, at 22:51, Chris Tapp wrote: > I've got a custom Cedartrail image which works great, but I can't get the > psplash screen to show on boot. > > I see a message like "cannot mmap framebuffer" scroll up the screen, but this > isn't in the message log so I don't get the full context. > > I've tried looking at the code for pspash-fb.c, but there aren't a lot of > clues (for me!). Is this something to do with the pixel format, as hinted at > by the comment referring to 'line_length'? Looks like it might be - adding 'video=1024x768-32@60' to the kernel command line means that the psplash screen shows. Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Cedartrail and Dylan?
Hi Tom, On 18 Jun 2013, at 15:04, Tom Zanussi wrote: > On Mon, 2013-06-17 at 16:56 -0700, Paul D. DeRocco wrote: >> I've been using the Intel meta-cedartrail layer with Danny 8.0.1. Is this >> layer likely to be unusable with Dylan 9.0? Or unusable without lots of >> tinkering that's probably beyond my abilities? >> >> And if I were to try Dylan, is it best to start from scratch, in a >> completely new directory? >> > > Hi, > > I believe the main problem would be the graphics driver - it would need > porting to the 3.8 kernel - the rest would probably be straightforward. > > The cedartrail BSP was discontinued following danny, but I'm cc:ing the > maintainers in case they might have any further input. > > I was thinking of creating a meta-intel/staging area for things like > this i.e. discontinued BSPs that people are still using, which would > contain best-effort updates but completely without promise of any kind > of support. If there's enough interest, and there seems to be judging > from the number of questions about cedartrail we continue to keep > getting, I'll try to find some free time to take a stab at moving it to > dylan... I'm certainly interested and happy to help out if I can. I also see that ASRock are now making a board (http://www.asrock.com/IPC/overview.asp?Model=DN2800MT) that looks exactly the same as the Intel one with the same name aimed at signage and thin-client applications, so hardware will be about for a good few years yet, > Thanks, > > Tom > > > > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Danny/Cedartrail psplash not showing
On 19 Jun 2013, at 03:53, Haw, Foo Chien wrote: > Hi Chris, > > Did you manage to get the psplash screen show after adding the kernel > argument? Yes, that seems to have fixed it. Though I'm not sure why ;-) > > Regards, > FC > > -Original Message- > Date: Sun, 16 Jun 2013 23:31:53 +0100 > From: Chris Tapp > To: Yocto Discussion Mailing List > Subject: Re: [yocto] Danny/Cedartrail psplash not showing > Message-ID: > Content-Type: text/plain; charset=us-ascii > > > On 16 Jun 2013, at 22:51, Chris Tapp wrote: > > > I've got a custom Cedartrail image which works great, but I can't get the > > psplash screen to show on boot. > > > > I see a message like "cannot mmap framebuffer" scroll up the screen, but > > this isn't in the message log so I don't get the full context. > > > > I've tried looking at the code for pspash-fb.c, but there aren't a lot of > > clues (for me!). Is this something to do with the pixel format, as hinted > > at by the comment referring to 'line_length'? > > Looks like it might be - adding 'video=1024x768-32@60' to the kernel command > line means that the psplash screen shows. > > Chris Tapp > > opensou...@keylevel.com > www.keylevel.com > Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Openembedded-core
Simple question - Is openembedded-core included in one of the Yocto meta layers, or do I need to download it from the OE git repository? Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Openembedded-core
Thanks Paul / Elizabeth, On 21 Jun 2013, at 17:53, Paul Eggleton wrote: > On Friday 21 June 2013 17:47:13 Chris Tapp wrote: >> Simple question - Is openembedded-core included in one of the Yocto meta >> layers, or do I need to download it from the OE git repository? > > It comes as part of the poky repository if you're using that. The alternative > is to use bitbake and OE-Core separately. I thought it was, but I can't get meta-fsl-arm-extras to build and thought it was worth checking this out first ;-) Time to dig... > Cheers, > Paul > > -- > > Paul Eggleton > Intel Open Source Technology Centre Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Using meta-fsl-arm with 'danny'
I'm trying to get core-image-minimal to build using meta-fsl-arm / meta-fsl-arm-extras under 'danny' for the 'wandboard-dual' machine. However, I can't find a tag/branch that works with 'danny'. Specifically, when I use the 'danny' branch there is a udev_173.bbappend in meta-fsl-arm, but 'danny' only supports udev_164. I also find a similar problem with meta-fsl-arm-extras. I must be missing something here... Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Using meta-fsl-arm with 'danny'
On 26 Jun 2013, at 22:17, Flanagan, Elizabeth wrote: > On Wed, Jun 26, 2013 at 1:59 PM, Chris Tapp wrote: >> I'm trying to get core-image-minimal to build using meta-fsl-arm / >> meta-fsl-arm-extras under 'danny' for the 'wandboard-dual' machine. >> >> However, I can't find a tag/branch that works with 'danny'. Specifically, >> when I use the 'danny' branch there is a udev_173.bbappend in meta-fsl-arm, >> but 'danny' only supports udev_164. > > > Is this perhaps what you are hitting? > > from the meta-fsl-arm danny branch: > > http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/README?h=danny > > To avoid the meta-oe dependency add to local.conf: > > BBMASK = "udev_.*\.bbappend$" Thanks, that's it. Not sure how I missed that one ! > -b > >> >> I also find a similar problem with meta-fsl-arm-extras. >> >> I must be missing something here... >> >> Chris Tapp >> >> opensou...@keylevel.com >> www.keylevel.com >> >> >> >> ___ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto > > > > -- > Elizabeth Flanagan > Yocto Project > Build and Release Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Problems building core-image-minimal for meta-fsl-asm-extra / 'wandboard-dual'
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
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Bitbake requires Python 2.7.3
I'm experimenting with meta-fsl-arm and I need to use 'master' for some of the latest updates. However, when I build I get told that "Bitbake requires Python 2.7.3". My development system is Ubuntu 11.10, which only has 2.7.2 (and is out of support, so no updates!) and the "latest" "Quick Start" manual simply says that 2.7 is required. Is 2.7.3 now a hard requirement (in which case the documentation could do with a minor change), or is the version test being too specific? Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Bitbake requires Python 2.7.3
On 28 Jun 2013, at 10:06, ChenQi wrote: > On 06/28/2013 04:55 PM, Chris Tapp wrote: >> I'm experimenting with meta-fsl-arm and I need to use 'master' for some of >> the latest updates. However, when I build I get told that "Bitbake requires >> Python 2.7.3". >> >> My development system is Ubuntu 11.10, which only has 2.7.2 (and is out of >> support, so no updates!) and the "latest" "Quick Start" manual simply says >> that 2.7 is required. >> >> Is 2.7.3 now a hard requirement (in which case the documentation could do >> with a minor change), or is the version test being too specific? > > I run into the same problem on Ubuntu 11.10, and I installed python2.7.5. > Everything's been working out well so far. I've done this and all's well. Thanks. > > //Chen Qi >> Chris Tapp >> >> opensou...@keylevel.com >> www.keylevel.com >> >> >> >> ___ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto >> >> > > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] bbappend - Where should my file be?
I've got a linux-wrs_git.bbappend file in a layer (under poky laverne
4.0.1) that contains:
COMPATIBLE_MACHINE_Vortex86DX = "Vortex86DX"
WRMACHINE_Vortex86DX = "common_pc"
FILESEXTRAPATHS := "${THISDIR}/${PN}"
SRC_URI += " file://defconfig"
Where should the defconfig file be relative to the bbappend?
I've tried:
MyLayer
+--- recipies
+--- linux
+--- linux-wrs_git.bbappend
+--- linux-wrs_git
+--- defconfig
However, my defconfig file isn't being picked up during do_unpack:
cp: cannot stat `/home/chris/yocto/yocto-versions/laverne-4.0.1/meta/
recipes-kernel/linux/files/defconfig': No such file or directory
NOTE: Unpacking /home/chris/yocto/yocto-downloads/
git_git.pokylinux.org.linux-2.6-windriver.git.tar.gz to /home/chris/
yocto/mbox-3300-build/tmp/work/Vortex86DX-poky-linux/linux-
wrs
-2.6.34
+
git0
+
b67e060194a38c6331da1532bd06446087a42b3b_0
+0431115c9d720fee5bb105f6a7411efb4f851d26-r12/
NOTE: Unpacking /home/chris/yocto/yocto-versions/laverne-4.0.1/meta/
recipes-kernel/linux/files/defconfig to /home/chris/yocto/mbox-3300-
build/tmp/work/Vortex86DX-poky-linux/linux-
wrs
-2.6.34
+
git0
+
b67e060194a38c6331da1532bd06446087a42b3b_0
+0431115c9d720fee5bb105f6a7411efb4f851d26-r12/
ERROR: Task failed:
Which seems to show that it's not looking in FILESEXTRAPATHS.
The .bbappend file seems to be processed, as commenting out the
SRC_URI line gets rid of the error.
What have I got wrong?
Chris Tapp
opensou...@keylevel.com
www.keylevel.com
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bbappend - Where should my file be?
Scott / Bruce, On 12 Aug 2011, at 00:57, Scott Garman wrote: cp: cannot stat `/home/chris/yocto/yocto-versions/laverne-4.0.1/meta/recipes-kernel/ linux/files/defconfig': No such file or directory It looks like this is where the file is expected. I believe also meta/recipes-kernel/linux/linux/defconfig should also work. I should have mentioned that ;-) As the bbappend file is in my layer, I was expecting (and want) the defconfig file to be stored/found in it. I created this layer by copying another one that I've got. It's unpack log shows: NOTE: Unpacking /home/chris/yocto/yocto-downloads/ git_git.pokylinux.org.linux-2.6-windriver.git.tar.gz to /home/chris/ yocto/sjs-build/tmp/work/LX800-poky-linux/linux- wrs -2.6.34 + git0 + b67e060194a38c6331da1532bd06446087a42b3b_0 +0431115c9d720fee5bb105f6a7411efb4f851d26-r12/ NOTE: Unpacking /home/chris/yocto/meta-keylevel-sjs/recipes/linux/ linux-wrs/defconfig to /home/chris/yocto/sjs-build/tmp/work/LX800-poky- linux/linux- wrs -2.6.34 + git0 + b67e060194a38c6331da1532bd06446087a42b3b_0 +0431115c9d720fee5bb105f6a7411efb4f851d26-r12/ I suspect I've got something configured wrong with the new layer, but... On 12 Aug 2011, at 01:28, Bruce Ashfield wrote: I believe also meta/recipes-kernel/linux/linux/defconfig should also work. Yep, bitbake is telling us where it is looking. The -wrs_git is the extension to the recipe, so that isn't where it is looking. Sorry Bruce, that was a typo (see working log above for a layer that works). I've tried using: MyLayer/recipies/linux/defconfig MyLayer/recipies/linux/files/defconfig (with no FILESEXTRAPATHS) MyLayer/recipies/linux/linux-wrs/defconfig On another note, there's been a lot of fixes to the kern tools to improve the process for adding BSPs and extending the tree (and one defconfig bug fix), so I'll be interested to hear how this goes. I'm planning to give it a try after the next release. I'm currently just trying to migrate an existing (4.0.1) project to a new platform and decided to add a new layer rather than change version at the same time. Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bbappend - Where should my file be?
On 12 Aug 2011, at 13:59, Bruce Ashfield wrote: NOTE: Unpacking /home/chris/yocto/yocto-downloads/git_git.pokylinux.org.linux-2.6- windriver.git.tar.gz to /home/chris/yocto/sjs-build/tmp/work/LX800-poky-linux/linux- wrs -2.6.34 + git0 + b67e060194a38c6331da1532bd06446087a42b3b_0 +0431115c9d720fee5bb105f6a7411efb4f851d26-r12/ NOTE: Unpacking /home/chris/yocto/meta-keylevel-sjs/recipes/linux/linux-wrs/ defconfig to /home/chris/yocto/sjs-build/tmp/work/LX800-poky-linux/linux- wrs -2.6.34 + git0 + b67e060194a38c6331da1532bd06446087a42b3b_0 +0431115c9d720fee5bb105f6a7411efb4f851d26-r12/ That does look right! What are the rules for naming layers? I renamed the root for my new layer from 'meta-ebox-3300' to 'meta- ebox3300', updated this in bblayers.conf and now my defconf file is found as I was expecting... It seems as if having - at the end stops things working. Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Configuring a layer to support multiple targets
What is the best way to configure a layer to support multiple targets
that share a common base?
For example, a set of targets that use the Vortex86DX SOC share common
peripherals and also have per-variant peripherals.
I was thinking:
1) Have a conf/machine file for each variant;
2) Make these use an include for the Vortex86DX SOC.
However, I can't work out how to get a per-machine defconfig file. Is
there some way of using the machine name to do this? Can I just use
FILESEXTRAPATHS := "${THISDIR}/${PN}/${MACHINE}"
in a kernel .bbappend file?
Chris Tapp
opensou...@keylevel.com
www.keylevel.com
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Configuring a layer to support multiple targets
On 13 Aug 2011, at 02:22, Bruce Ashfield wrote: What's your yocto release / base kernel ? IF you happen to be using linux-yocto there are several ways to avoid using defconfigs at all, and share your common base of kernel configuration items. Plan is to move to linux-yocto (currently using wrs). How do I configure it without using a defconfig? Also, is it possible to use a .config rather than a defconfig? I've got a lot of stuff turned off to reduce the size of the kernel, but a defconfig doesn't quite do. For example, if I have # CONFIG_USB_SERIAL is not set in a defconfig, then this gets in to the .config at build time. However, this doesn't disable any dependencies that are enabled in linux-wrs. This means that modules for the likes of the ftdi and pl2303 USB serial devices are still included in the kernel image. The use of a complete .config would stop this. Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Configuring a layer to support multiple targets
On 17 Aug 2011, at 16:18, Bruce Ashfield wrote: In this sense, the defconfig is simply a name to trigger specific processing. Just capture and call your .config 'defconfig' and you'll get a translation of those settings into the build. That's what I've done. I used 'make xconfig' to modify the .config file (resulting from bitbake -c compile virtual/kernel). However, turning off CONFIG_USB_SERIAL and saving the result as a defconfig isn't quite what's needed. Consider the .config fragment: CONFIG_USB_SERIAL=y CONFIG_USB_SERIAL_FTDI_SIO=y The corresponding defconfig fragment produced when usb serial is disabled in xconfig results is simply: # CONFIG_USB_SERIAL is not set When the defconfig is merged with the .config I get: # CONFIG_USB_SERIAL is not set CONFIG_USB_SERIAL_FTDI_SIO=y This means the FTDI module is still present in the kernel. I can get rid of these by manually adding 'not set' entries in the defconfig, but it would be easier if I could replace the .config rather than patch it. Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Configuring a layer to support multiple targets
On 17 Aug 2011, at 20:15, Bruce Ashfield wrote: The model is that you must explicitly chose values to modify them, otherwise, they flow through. Last through the gate wins. If you don't speak, others parts speak for the configuration. That's what I was trying to say ;-) In this case, you must be inheriting the common-pc kernel configuration. I am. The solutions two this are: ... - inherit from a base branch vs common-pc (assuming that I guessed right) Sounds like a plan. Where can I find a list of the branches in the 4.0.1 meta data? I'm using the following to select one at the moment: WRMACHINE_Vortex86DX = "common_pc" --- I'm guessing I need something else here. SRCREV_machine_pn-linux-wrs_Vortex86DX ?= "0431115c9d720fee5bb105f6a7411efb4f851d26" - convince us that the common-pc shouldn't be turning this on and trickle this option out to the leaf BSPs. No, it seems perfectly reasonable to have this in 'common-pc'. Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Configuring a layer to support multiple targets
On 17 Aug 2011, at 21:24, Bruce Ashfield wrote: I have to head out for the day, but I'll loop around on this. Technically I'm out of the office for the next 2 days, but can sneak this in. I just need to double check a couple things in the 2.6.34 support to see if inheriting from 'standard' directly will work for you .. and if it won't, I can give you patch to carry locally for a bit. Thanks, but please don't speed too much time on it if 'standard' isn't going to work. This is only a research project at the moment and I can patch my defconf easily enough for now (especially as it seems I need to re-enable USB_SERIAL with USB_SERIAL_GENERIC to get the CM119 usb audio on the SoC to work, which means a defconf will now do what I want). It would be nice to have a proper (generic) solution going forward, but I plan to switch to linux-yocto-stable in the pending release. Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Strange USB behavior
I'm running on a platform using the Vortex86DX SoC which includes a CM119 USB audio interface. I've got a kernel configuration that recognizes and initializes this ok (dmesg reports it as an ALSA device). However, this is only the case if I also have a USB storage device connected when it boots! 1) The audio works if I boot the kernel from the USB device; 2) The audio works if I boot from the system SD card and any USB storage device is connected (it's not booting from this accidentally); 3) The audio does not work if I boot from the SD card without a USB storage device. Can anyone give me an idea where I should start looking to try and understand what's going on here? Kernel is a modified 'common-pc' 2.6.34 wrs that has been built using Yocto 0.9. Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Strange USB behavior
On 18 Aug 2011, at 09:19, Chris Tapp wrote: I'm running on a platform using the Vortex86DX SoC which includes a CM119 USB audio interface. I've got a kernel configuration that recognizes and initializes this ok (dmesg reports it as an ALSA device). However, this is only the case if I also have a USB storage device connected when it boots! 1) The audio works if I boot the kernel from the USB device; 2) The audio works if I boot from the system SD card and any USB storage device is connected (it's not booting from this accidentally); 3) The audio does not work if I boot from the SD card without a USB storage device. Can anyone give me an idea where I should start looking to try and understand what's going on here? Kernel is a modified 'common-pc' 2.6.34 wrs that has been built using Yocto 0.9. Looks like this is just a kernel load order issue. The USB storage device seems to cause the sound device to initialise earlier in the boot so it's ready when ALSA loads. Without it, it's not loaded before ALSA, so a 'No sound card' message is produced in the log - but there is one once the system is up. Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Strange USB behavior
On 18 Aug 2011, at 22:06, Darren Hart wrote: I asked Sarah Sharp if she had any thoughts, she responded in part: One thing I might suspect is a problem with the host controller going into suspend. I think 2.6.34 didn't have support for USB suspend for mass storage devices, so booting with a mass storage device would keep the USB host controller from going into suspend. This would also be true of mice, since they did support suspend in 2.6.34, but it was disabled by default. Does it help if he disables USB device suspend in the kernel config? I'll give it a try (will be a while as I've moved to the 5.0.1 release and the build has just started!). Thanks for the suggestion :-) Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Build fails moving from 4.0.1 to 5.0.1
I've got a configuration that builds ok under 4.0.1, but when I build under 5.0.1 I get the following right at the end: Installing task-poky-boot (1.0-r7) to root... Downloading file:/home/chris/yocto/ebox3300-build/tmp/deploy/ipk/ Vortex86DX/task-poky-boot_1.0-r7_Vortex86DX.ipk. Installing task-sjs (1.0-r0) to root... Downloading file:/home/chris/yocto/ebox3300-build/tmp/deploy/ipk/ Vortex86DX/task-sjs_1.0-r0_Vortex86DX.ipk. Unknown package 'run-postinsts'. Collected errors: * satisfy_dependencies_for: Cannot satisfy the following dependencies for task-poky-boot: * tinylogin * busybox * modutils-initscripts * initscripts * console-tools * initscripts * udev * sysvinit * netbase * base- passwd * * opkg_install_cmd: Cannot install package task-poky-boot. * satisfy_dependencies_for: Cannot satisfy the following dependencies for task-sjs: * yocto-wallboard * psplash * syslinux * * opkg_install_cmd: Cannot install package task-sjs. * opkg_install_cmd: Cannot install package run-postinsts. ERROR: Function 'do_rootfs' failed (see ... If I look in tmp/work, it looks as if the missing dependencies have all been built and packaged within their work areas. I tried cleaning and rebuilding 'task-sjs', but that made no difference to the errors reported against it. Where should I start looking to work out what's going wrong here? Is it as simple as needing to add something like RDEPENDS? Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build fails moving from 4.0.1 to 5.0.1
On 19 Aug 2011, at 17:16, Richard Purdie wrote: On Fri, 2011-08-19 at 08:29 +0100, Chris Tapp wrote: I've got a configuration that builds ok under 4.0.1, but when I build under 5.0.1 I get the following right at the end: Installing task-poky-boot (1.0-r7) to root... Downloading file:/home/chris/yocto/ebox3300-build/tmp/deploy/ipk/ Vortex86DX/task-poky-boot_1.0-r7_Vortex86DX.ipk. Installing task-sjs (1.0-r0) to root... Downloading file:/home/chris/yocto/ebox3300-build/tmp/deploy/ipk/ Vortex86DX/task-sjs_1.0-r0_Vortex86DX.ipk. Unknown package 'run-postinsts'. Collected errors: * satisfy_dependencies_for: Cannot satisfy the following dependencies for task-poky-boot: * tinylogin * busybox * modutils-initscripts * initscripts * console-tools * initscripts * udev * sysvinit * netbase * base- passwd * * opkg_install_cmd: Cannot install package task-poky-boot. * satisfy_dependencies_for: Cannot satisfy the following dependencies for task-sjs: * yocto-wallboard * psplash * syslinux * * opkg_install_cmd: Cannot install package task-sjs. * opkg_install_cmd: Cannot install package run-postinsts. ERROR: Function 'do_rootfs' failed (see ... If I look in tmp/work, it looks as if the missing dependencies have all been built and packaged within their work areas. I tried cleaning and rebuilding 'task-sjs', but that made no difference to the errors reported against it. Where should I start looking to work out what's going wrong here? Is it as simple as needing to add something like RDEPENDS? This sounds like the machine specific packages are failing to be found so it sounds like a package feed issue. Is sounds like PACKAGE_ARCHS isn't listing everything it needs to (such as the machine name) or the package system isn't finding a group of packages for some other reason. Thanks, but that's way over my head at the moment ;-) I've searched through the meta data for PACKAGE_ARCHS, but that's not thrown anything up to make me think there was anything I should look at. I'm using my own machine recipe. Is this were I should be looking? Chris ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build fails moving from 4.0.1 to 5.0.1
On 19 Aug 2011, at 21:49, Richard Purdie wrote:
On Fri, 2011-08-19 at 20:43 +0100, Chris Tapp wrote:
On 19 Aug 2011, at 17:16, Richard Purdie wrote:
On Fri, 2011-08-19 at 08:29 +0100, Chris Tapp wrote:
I've got a configuration that builds ok under 4.0.1, but when I
build
under 5.0.1 I get the following right at the end:
Installing task-poky-boot (1.0-r7) to root...
Downloading file:/home/chris/yocto/ebox3300-build/tmp/deploy/ipk/
Vortex86DX/task-poky-boot_1.0-r7_Vortex86DX.ipk.
Installing task-sjs (1.0-r0) to root...
Downloading file:/home/chris/yocto/ebox3300-build/tmp/deploy/ipk/
Vortex86DX/task-sjs_1.0-r0_Vortex86DX.ipk.
Unknown package 'run-postinsts'.
Collected errors:
* satisfy_dependencies_for: Cannot satisfy the following
dependencies for task-poky-boot:
* tinylogin * busybox * modutils-initscripts * initscripts *
console-tools * initscripts * udev * sysvinit * netbase *
base-
passwd *
* opkg_install_cmd: Cannot install package task-poky-boot.
* satisfy_dependencies_for: Cannot satisfy the following
dependencies for task-sjs:
* yocto-wallboard * psplash * syslinux *
* opkg_install_cmd: Cannot install package task-sjs.
* opkg_install_cmd: Cannot install package run-postinsts.
ERROR: Function 'do_rootfs' failed (see ...
If I look in tmp/work, it looks as if the missing dependencies have
all been built and packaged within their work areas.
I tried cleaning and rebuilding 'task-sjs', but that made no
difference to the errors reported against it.
Where should I start looking to work out what's going wrong here?
Is
it as simple as needing to add something like RDEPENDS?
This sounds like the machine specific packages are failing to be
found
so it sounds like a package feed issue. Is sounds like PACKAGE_ARCHS
isn't listing everything it needs to (such as the machine name) or
the
package system isn't finding a group of packages for some other
reason.
Thanks, but that's way over my head at the moment ;-)
I've searched through the meta data for PACKAGE_ARCHS, but that's not
thrown anything up to make me think there was anything I should
look at.
I'm using my own machine recipe. Is this were I should be looking?
Yes, I suspect something about your machine config is resulting in
this
but its hard to me to say what.
You can do things like "bitbake -e | grep ^PACKAGE_ARCHS" to see the
contents of variables. I'm curious if your machine name is listed in
that list.
chris@ubuntu:~/yocto/ebox3300-build$ bitbake -e |grep "PACKAGE_ARCHS"
# PACKAGE_ARCHS=all any noarch ${PACKAGE_EXTRA_ARCHS} ${MACHINE_ARCH}
PACKAGE_ARCHS="all any noarch x86 Vortex86DX"
ipkg_archs = bb.data.getVar('PACKAGE_ARCHS',d)
bb.error("PACKAGE_ARCHS missing")
My machine is "Vortex86DX"
Chris Tapp
opensou...@keylevel.com
www.keylevel.com
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build fails moving from 4.0.1 to 5.0.1
On 19 Aug 2011, at 22:22, Richard Purdie wrote:
On Fri, 2011-08-19 at 21:58 +0100, Chris Tapp wrote:
On 19 Aug 2011, at 21:49, Richard Purdie wrote:
On Fri, 2011-08-19 at 20:43 +0100, Chris Tapp wrote:
On 19 Aug 2011, at 17:16, Richard Purdie wrote:
On Fri, 2011-08-19 at 08:29 +0100, Chris Tapp wrote:
I've got a configuration that builds ok under 4.0.1, but when I
build
under 5.0.1 I get the following right at the end:
Installing task-poky-boot (1.0-r7) to root...
Downloading file:/home/chris/yocto/ebox3300-build/tmp/deploy/ipk/
Vortex86DX/task-poky-boot_1.0-r7_Vortex86DX.ipk.
Installing task-sjs (1.0-r0) to root...
Downloading file:/home/chris/yocto/ebox3300-build/tmp/deploy/ipk/
Vortex86DX/task-sjs_1.0-r0_Vortex86DX.ipk.
Unknown package 'run-postinsts'.
Collected errors:
* satisfy_dependencies_for: Cannot satisfy the following
dependencies for task-poky-boot:
* tinylogin * busybox * modutils-initscripts * initscripts
*
console-tools * initscripts * udev * sysvinit * netbase *
base-
passwd *
* opkg_install_cmd: Cannot install package task-poky-boot.
* satisfy_dependencies_for: Cannot satisfy the following
dependencies for task-sjs:
* yocto-wallboard * psplash * syslinux *
* opkg_install_cmd: Cannot install package task-sjs.
* opkg_install_cmd: Cannot install package run-postinsts.
ERROR: Function 'do_rootfs' failed (see ...
If I look in tmp/work, it looks as if the missing dependencies
have
all been built and packaged within their work areas.
I tried cleaning and rebuilding 'task-sjs', but that made no
difference to the errors reported against it.
Where should I start looking to work out what's going wrong here?
Is
it as simple as needing to add something like RDEPENDS?
This sounds like the machine specific packages are failing to be
found
so it sounds like a package feed issue. Is sounds like
PACKAGE_ARCHS
isn't listing everything it needs to (such as the machine name) or
the
package system isn't finding a group of packages for some other
reason.
Thanks, but that's way over my head at the moment ;-)
I've searched through the meta data for PACKAGE_ARCHS, but that's
not
thrown anything up to make me think there was anything I should
look at.
I'm using my own machine recipe. Is this were I should be looking?
Yes, I suspect something about your machine config is resulting in
this
but its hard to me to say what.
You can do things like "bitbake -e | grep ^PACKAGE_ARCHS" to see the
contents of variables. I'm curious if your machine name is listed in
that list.
chris@ubuntu:~/yocto/ebox3300-build$ bitbake -e |grep "PACKAGE_ARCHS"
# PACKAGE_ARCHS=all any noarch ${PACKAGE_EXTRA_ARCHS} ${MACHINE_ARCH}
PACKAGE_ARCHS="all any noarch x86 Vortex86DX"
ipkg_archs = bb.data.getVar('PACKAGE_ARCHS',d)
bb.error("PACKAGE_ARCHS missing")
My machine is "Vortex86DX"
What does "ls /home/chris/yocto/ebox3300-build/tmp/deploy/ipk" say?
drwxr-xr-x 2 chris chris 4096 2011-08-19 21:12 all
drwxr-xr-x 2 chris chris 143360 2011-08-19 21:12 i586
-rw-r--r-- 1 chris chris 0 2011-08-19 21:12 Packages
-rw-r--r-- 1 chris chris 0 2011-08-19 21:12 Packages.filelist
-rwxr--r-- 1 chris chris 0 2011-08-19 03:19 Packages.flock
-rwxr--r-- 1 chris chris 20 2011-08-19 21:12 Packages.gz
-rw-r--r-- 1 chris chris 0 2011-08-19 21:12 Packages.stamps
drwxr-xr-x 2 chris chris 4096 2011-08-19 21:12 Vortex86DX
Chris
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build fails moving from 4.0.1 to 5.0.1
On 21 Aug 2011, at 10:19, Chris Tapp wrote: What does "ls /home/chris/yocto/ebox3300-build/tmp/deploy/ipk" say? drwxr-xr-x 2 chris chris 4096 2011-08-19 21:12 all drwxr-xr-x 2 chris chris 143360 2011-08-19 21:12 i586 -rw-r--r-- 1 chris chris 0 2011-08-19 21:12 Packages -rw-r--r-- 1 chris chris 0 2011-08-19 21:12 Packages.filelist -rwxr--r-- 1 chris chris 0 2011-08-19 03:19 Packages.flock -rwxr--r-- 1 chris chris 20 2011-08-19 21:12 Packages.gz -rw-r--r-- 1 chris chris 0 2011-08-19 21:12 Packages.stamps drwxr-xr-x 2 chris chris 4096 2011-08-19 21:12 Vortex86DX I don't know if it helps, but all the missing dependencies have .ipk files in the i586 directory shown above. Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Configuring a layer to support multiple targets
On 22 Aug 2011, at 19:52, Bruce Ashfield wrote: As it turns out, you would need some tweaks to the kern tools (backports) to get this working. There's low value in this, so as you said, if you don't need it. I'll consider this a closed issue and I can help on newer releases (and have some docs) to show you what is required. Thanks Bruce, that sounds good it me :-) Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Missing patch files in SRC_URIs
bitbake doesn't seem to be detecting missing patch files. In
a .bbappend file (for linux-wrs_git) I have:
SRC_URI += " file://defconfig"
SRC_URI_append_Vortex86DX = "\
file://there-is-no.patch;patch=1 "
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}"
bitbake -c patch -f virtual/kernel
runs without reporting any errors, even though linux-wrs_Vortex86DX/
does not contain 'there-is-no.patch'.
However, if I change the append to specify a (non-existent) file:
SRC_URI_append_Vortex86DX = "\
file://there-is-no-file "
then bitbake reports an error, as I would expect.
Am I doing something wrong here?
Bitbake version is 1.11.0 and MACHINE is Vortex86DX.
Chris Tapp
opensou...@keylevel.com
www.keylevel.com
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Missing patch files in SRC_URIs
Hi Paul, On 24 Aug 2011, at 12:11, Paul Eggleton wrote: Hi Chris, On Wednesday 24 August 2011 08:59:15 Chris Tapp wrote: bitbake doesn't seem to be detecting missing patch files. In a .bbappend file (for linux-wrs_git) I have: SRC_URI += " file://defconfig" SRC_URI_append_Vortex86DX = "\ file://there-is-no.patch;patch=1 " FYI patch=1 is no longer necessary as of quite some time ago - the .patch (or .diff) extension is enough to indicate that it's a patch. It seems as if it's this that's causing the problem. I had a 'real' patch file in place and it wasn't being processed during do_unpack. Removing the 'patch=1' fixed this and it was processed as expected. It seems as if adding the 'patch=1' to the file means it's not used as a file or patch and is simply ignored, which would explain what I was seeing. A 'missing' file without 'patch=1' is reported as an error. bitbake -c patch -f virtual/kernel runs without reporting any errors, even though linux-wrs_Vortex86DX/ does not contain 'there-is-no.patch'. Are you sure there is no patch of this name elsewhere in the search path for this recipe? This is buggy behaviour if there isn't. (bitbake -e linux-wrs | grep "^FILESPATH" will give you the entire path it is using.) In any case the directory it should search for the patch in is linux-wrs/Vortex86DX not linux- wrs_Vortex86DX. I'm certain - I made this file name up specially for testing ;-) My, doesn't FILESPATH get complicated ! I'd also recommend for consistency if it's not too difficult to change at this point that you use an all-lowercase machine name. Easily done, as this is only experimental at the moment. I'll try and remember to change it when I finish later on so I can run a complete rebuild over night. Thanks for the pointer. Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Adding X to image
What do I need to add where to get 'X' in to my image? I've built poky-image-base (under 4.0.1) and things like xinit have been built and are in the tmp/work tree. What do I need to add so that xinit (and dependencies) are added to the image? Should I be building a different image? Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Adding X to image
On 25 Aug 2011, at 20:15, Gary Thomas wrote: On 2011-08-25 13:07, Chris Tapp wrote: What do I need to add where to get 'X' in to my image? I've built poky-image-base (under 4.0.1) and things like xinit have been built and are in the tmp/work tree. What do I need to add so that xinit (and dependencies) are added to the image? Should I be building a different image? Try core-image-sato - it has a full-up X [matchbox based] X desktop Thanks Gary, I can't find that one, bit I'm trying task-poky-x11-sato... Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Adding X to image
On 25 Aug 2011, at 20:36, Gary Thomas wrote: On 2011-08-25 13:33, Chris Tapp wrote: On 25 Aug 2011, at 20:15, Gary Thomas wrote: On 2011-08-25 13:07, Chris Tapp wrote: What do I need to add where to get 'X' in to my image? I've built poky-image-base (under 4.0.1) and things like xinit have been built and are in the tmp/work tree. What do I need to add so that xinit (and dependencies) are added to the image? Should I be building a different image? Try core-image-sato - it has a full-up X [matchbox based] X desktop Thanks Gary, I can't find that one, bit I'm trying task-poky-x11-sato... If you're not using the bleeding-edge-master, it might be named poky- image-sato task-poky-x11-sato is just a collection of packages needed for X. It won't build a final root file system. Sure. I should have mentioned that I will add this to my project image ;-) However, poky-image-sato sounds like it's worth a try first. Building... Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Best way to override EXTRA_OECONF
I'm using libGL provided by mesa-xlib, which includes mesa-common. I also want to use libglu, but mesa-common says: EXTRA_OECONF = "--disable-glu \ Is there a way I can override this without having to alter mesa- common.inc. Would a mesa-xlib.bbappend file with EXTRA_OECONF += "--enable-glu \ do it? Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bbappend - Where should my file be?
On 30 Aug 2011, at 19:07, Richard Purdie wrote:
On Fri, 2011-08-12 at 00:51 +0100, Chris Tapp wrote:
I've got a linux-wrs_git.bbappend file in a layer (under poky laverne
4.0.1) that contains:
COMPATIBLE_MACHINE_Vortex86DX = "Vortex86DX"
WRMACHINE_Vortex86DX = "common_pc"
FILESEXTRAPATHS := "${THISDIR}/${PN}"
SRC_URI += " file://defconfig"
Where should the defconfig file be relative to the bbappend?
I've tried:
MyLayer
+--- recipies
+--- linux
+--- linux-wrs_git.bbappend
+--- linux-wrs_git
+--- defconfig
However, my defconfig file isn't being picked up during do_unpack:
cp: cannot stat `/home/chris/yocto/yocto-versions/laverne-4.0.1/meta/
recipes-kernel/linux/files/defconfig': No such file or directory
NOTE: Unpacking /home/chris/yocto/yocto-downloads/
git_git.pokylinux.org.linux-2.6-windriver.git.tar.gz to /home/chris/
yocto/mbox-3300-build/tmp/work/Vortex86DX-poky-linux/linux-
wrs
-2.6.34
+
git0
+
b67e060194a38c6331da1532bd06446087a42b3b_0
+0431115c9d720fee5bb105f6a7411efb4f851d26-r12/
NOTE: Unpacking /home/chris/yocto/yocto-versions/laverne-4.0.1/meta/
recipes-kernel/linux/files/defconfig to /home/chris/yocto/mbox-3300-
build/tmp/work/Vortex86DX-poky-linux/linux-
wrs
-2.6.34
+
git0
+
b67e060194a38c6331da1532bd06446087a42b3b_0
+0431115c9d720fee5bb105f6a7411efb4f851d26-r12/
ERROR: Task failed:
Which seems to show that it's not looking in FILESEXTRAPATHS.
The .bbappend file seems to be processed, as commenting out the
SRC_URI line gets rid of the error.
What have I got wrong?
I've just been looking at the open bug related to this
(http://bugzilla.yoctoproject.org/show_bug.cgi?id=1379) and I can't
reproduce an issue with layers ending with -numeric causing a
problem :/.
In the above example,
recipies/linux/linux-wrs/defconfig
is the correct path since PN == "linux-wrs". (you had linux-wrs_git).
Could you check whether the layer numeric part is a red herring please
and whether the above path works?
Hi Richard,
Sorry for the delay in looking at this again.
I can't re-create the behaviour here either, though it was repeatable
before. However, since then I've made quite a few changes to the
recipe and done a complete re-build.
It was also failing with the correct paths - I was trying all sorts of
combinations when the correct one wasn't working!
I'll try and do some more testing here (with what I think the recipe
was at the time) to see if I can get it to show again. I've only got a
slow build machine, so it may take a while ;-)
Chris Tapp
opensou...@keylevel.com
www.keylevel.com
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Splitting processor and target in BSPs
How should meta data be structured so that a layer can support a set of systems using a set of processors? For example, many of the 'eBox' systems use variants of the Vortex86 SoC. So, a set of machine files are needed for these (e.g. ebox-3300, ebox-3500mx, etc.). These have different peripherals available (e.g. some have serial, some don't) and use different SoC variants with different cpu, sound, etc. It would therefore make sense for the machine configuration to inherit the SoC attributes (for the common features) and add (or remove) machine specific attributes (e.g. serial) to these. This can be done by putting the SoC bits in to an include. However, kernel configuration becomes a little bit more complicated as this is done by machine name. A kernel recipe will be needed for each machine (e.g. for the different sound drivers), but I can't work out how to do this using a base configuration for the SoCs that are shared and then adding machine specific parts. I can do it using (for example) a .defconfig for each machine, but that would require updates to multiple files to change the SoC configuration. I guess what I'm really asking is, is it possible to have a base CPU configuration and add a machine configuration to this ? I've recently seen discussion of .cfg kernel fragment files. Are these what I should be looking at? Are these available in the releases or only in the development branch? Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Splitting processor and target in BSPs
On 2 Sep 2011, at 16:49, McClintock Matthew-B29882 wrote: On Fri, Sep 2, 2011 at 2:26 AM, Chris Tapp wrote: However, kernel configuration becomes a little bit more complicated as this is done by machine name. A kernel recipe will be needed for each machine (e.g. for the different sound drivers), but I can't work out how to do this using a base configuration for the SoCs that are shared and then adding machine specific parts. I can do it using (for example) a .defconfig for each machine, but that would require updates to multiple files to change the SoC configuration. I guess what I'm really asking is, is it possible to have a base CPU configuration and add a machine configuration to this ? I've recently seen discussion of .cfg kernel fragment files. Are these what I should be looking at? Are these available in the releases or only in the development branch? I think this is a good solution for you. It's a little confusing to find were this work is but you can look in the linux-yocto kernel tree - then the actual cfg fragment stuff on different branches. http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.0/ meta branch contains meta/ which contains a lot of the cfg fragments, and patches, etc. Thanks, I can see what they look like now ;-) What are 'the rules' for cfg files? I.e.: 1) Does adding #CONFIG_this_bit not set disable a node and its dependencies? For example, if I turn off usb serial support do the usb serial drivers get disabled as well or do I have to do this manually? 2) Similarly, if a node is enabled what happens to the dependent nodes? Do they all need to be covered, or only the ones that need to be enabled? I've also noticed that there are scc files. These seem to pull features in to sets? How do these work? meta/cfg/kernel-cache/bsp/common-pc/hardware.cfg contains CONFIG_ATH5K CONFIG_ATH_COMMON ... CONFIG_SERIAL_8250_CONSOLE It seems as if this file does something else, as these don't look like valid kernel configuration options. There is also a document in the git repo as well which is worth a look. I couldn't see one, but there's a lot in there ;-) Sorry for all the questions, but there's a lot to understand for someone new :-) Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] poky consume all memory on redhat-based linux in virtualbox
On 22 Sep 2011, at 10:28, 蔡振军 wrote: Hi all, When I tried to build image on Fedora and Scientific , I encountered same problem that poky consume all memory and then system became very slow. The poky process also moved on hardly. After killing poky process, memory wasn’t freed. I had noticed that some process like “cc1” brought up by poky process were still alive. Anybody know what’s the problem? How much memory do you have? I've seen the build process peak at something like 2.5GB. I started running with a VM that only had 1GB allocated and had the same problem as this caused lots of swap file activity. It was mainly the compiler/linker that was using most of the memory, which would explain why you see 'cc1'. Don't forget that the build process fires off multiple processes. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Adding mp3 support to gstreamer
I'm trying to add mp3 support to gstreamer. I've got a task that RDEPENDS on gst-meta-audio. The image produced includes gstreamer, as expected. However, there is no mp3 decoder included. I've tried setting: COMMERCIAL_AUDIO_PLUGINS = "gst-plugins-ugly-mad", but there was still no mp3 support. I then tried adding an RDEPENDS on gst-ffmpeg. gst-inspect -b showed this as 'blacklisted'. So, I then tried gst-fluendo-mp3, but I get a "nothing provides" error at build time. What do I need to do to get mp3 decoding added to the image? Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Adding mp3 support to gstreamer
On 14 Oct 2011, at 01:26, Khem Raj wrote: On Thu, Oct 13, 2011 at 4:36 PM, Chris Tapp wrote: I'm trying to add mp3 support to gstreamer. I've got a task that RDEPENDS on gst-meta-audio. The image produced includes gstreamer, as expected. However, there is no mp3 decoder included. I've tried setting: COMMERCIAL_AUDIO_PLUGINS = "gst-plugins-ugly-mad", but there was still no mp3 support. I then tried adding an RDEPENDS on gst-ffmpeg. gst-inspect -b showed this as 'blacklisted'. So, I then tried gst-fluendo-mp3, but I get a "nothing provides" error at build time. What do I need to do to get mp3 decoding added to the image? what does COMMERCIAL_LICENSE has in it ? You might want to see that package is part of this variable or not bitbake -e reports: COMMERCIAL_LICENSE="lame gst-fluendo-mp3 libmad mpeg2dec ffmpeg qmmp" Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Adding mp3 support to gstreamer
On 14 Oct 2011, at 17:17, Joshua Lock wrote: On 10/14/2011 12:18 AM, Chris Tapp wrote: On 14 Oct 2011, at 01:26, Khem Raj wrote: On Thu, Oct 13, 2011 at 4:36 PM, Chris Tapp wrote: I'm trying to add mp3 support to gstreamer. I've got a task that RDEPENDS on gst-meta-audio. The image produced includes gstreamer, as expected. However, there is no mp3 decoder included. I've tried setting: COMMERCIAL_AUDIO_PLUGINS = "gst-plugins-ugly-mad", but there was still no mp3 support. I then tried adding an RDEPENDS on gst-ffmpeg. gst-inspect -b showed this as 'blacklisted'. So, I then tried gst-fluendo-mp3, but I get a "nothing provides" error at build time. What do I need to do to get mp3 decoding added to the image? what does COMMERCIAL_LICENSE has in it ? You might want to see that package is part of this variable or not bitbake -e reports: COMMERCIAL_LICENSE="lame gst-fluendo-mp3 libmad mpeg2dec ffmpeg qmmp" Right, I'm struggling to find documentation further than what's in the code[1] and bugzilla[2] (there's probably stuff in the mail archives too) but, COMMERCIAL_LICENSE is a blacklist - so you have to remove items from that list to acknowledge that there are likely commercial implications of using those recipes. Furthermore, there are white lists of permitted commercially licensed packages, to which you need to add the output of COMMERCIAL_LICENSE recipes that you want to include in images (by way of appending them to default installation targets in various recipes). COMMERCIAL_AUDIO_PLUGINS, COMMERCIAL_VIDEO_PLUGINS, and COMMERCIAL_QT Hope this helps, It does. Thanks. However, I'm now even more confused ;-) I've got it working by using the gstreamer recipe from 5.0.1 (I'm building under 4.0.1). However, bitbake -e still reports as above and I can't see ffmpeg in any context other than RECIPE_STATUS_pn-gst-ffmpeg="red". Still, it's working :-) Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] unionfs, initrd, switch_root ...
I'm booting using the rootfs produced by bitbake as in initrd. This works nicely and gives a read-only boot device and a system that runs from RAM. What I want to do now is allow changes to be made to some files (e.g. network configuration) and have these saved on the boot device so that they can be restored at startup. To do this I plan to use unionfs to join / and something like /var/tmp/ufs. e.g. mkdir /var/tmp/ufs mount -t unionfs -o dirs=/var/tmp/ufs=rw:/=ro unionfs /media/union This all works as expected. However, I now need to make /media/union the system root so that the system sees the ufs union copies of files. I think I need to 'switch_root'. However, switch_root /media/union /sbin/init 3 gives errors like: switch_root: failed to mount moving /proc to /media/union/proc: No such file or directory This is where I get lost and I can't seem to find anything on the web that helps. A 'grep' of meta hasn't thrown anything up that helps - does anyone have a good web reference I can go and read? Lots of learning to do... Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] How do I tell when a USB disk is ready?
I've got a minimal root file system that will be used to install a poky image from a USB stick. The init script this uses mounts sda1 (from where it's just booted), but sda1 isn't ready when it tries to do this - I can see the bus enumeration messages on the console after the mount fails. How can my script test to see when the device is ready? Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How do I tell when a USB disk is ready?
On 25 Oct 2011, at 09:45, Gary Thomas wrote: On 2011-10-24 18:10, Chris Tapp wrote: I've got a minimal root file system that will be used to install a poky image from a USB stick. The init script this uses mounts sda1 (from where it's just booted), but sda1 isn't ready when it tries to do this - I can see the bus enumeration messages on the console after the mount fails. How can my script test to see when the device is ready? You could try looking for /dev/sda1 in /proc/partitions like in attached script. Thanks Gary, that's just what's needed :-) Chris ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Which filesystem for target?
A bit of an open-ended question, but... Which is the 'best' filesystem to use for an embedded device that's using a CF card? It needs to survive loss-of-power, have a RO root filesystem, allow user configuration data to persist and (ideally) only use 'Busybox' commands. This seems to imply the use of a partition for booting (mount RO) and a second partition or a loop-device on the boot partition for persistent storage. I would normally go for ext3, but Busybox doesn't support it (afaik). The Busybox tune2fs also only supports -L, so I can't stop 'disk needs checking after mounts' messages. Is btrfs a suitable alternative? Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Which filesystem for target?
On 31 Oct 2011, at 10:16, Paul Eggleton wrote: On Friday 28 October 2011 23:11:22 Chris Tapp wrote: Which is the 'best' filesystem to use for an embedded device that's using a CF card? ... Arnd Bergmann gave a talk at ELCE on flash drive performance (something he has done quite a lot of research on); I did not attend but Darren and I spoke to him later on, and if I recall correctly in his tests btrfs performed the best. Hopefully the talk video will be available soon thanks to the folks at Free Electrons; in the mean time there's an earlier article by Arnd on this topic here: http://lwn.net/Articles/428584/ Thanks, that's a very good article that may explain some issues I've been seeing. Chris ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Change splash screen
On 4 Nov 2011, at 21:44, Marc Ferland wrote:
Hi,
What's the proper way to change the splash screen in Yocto? I have
re-generated the psplash-poky-img.h file but I don't know where to
put this file in my local layer. I guess this question also applies
to all recipes containing references to local files in the SRC_URI.
I could replace the current file with the one I just generated but
that doesn't seem right...!
I did it by creating a .bbappend file in an overlay (which holds all
my changes):
overlay-directory/recipes/psplash/psplash_svn.bbappend:
FILESEXTRAPATHS := "${THISDIR}/files"
-
overlay-directory/recipes/psplash/files/psplash-poky-img.h --- your
new image file
Chris Tapp
opensou...@keylevel.com
www.keylevel.com
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto usability questions
On 16 Nov 2011, at 22:07, Jeff Osier-Mixon wrote: Mark & everyone else listening: Would you say that (1) the need for a recipe and (2) the requirement to cross-compile are two of the most major usability or learning- curve disadvantages of working with the Yocto Project (and oe-core)? What would be a third disadvantage from a usability standpoint? Another way to put it: if you could change three things about the Yocto Project to make it more approachable for someone who has never used it before, what would they be? As another very experienced embedded systems developer who is relatively new to embedded linux I would say that documentation and worked examples are what I would really be after. It can be really frustrating when you can't get something going because you don't understand the phrases / terminology that's being used and it isn't readily available via the documentation. I've seen quite a few posts on here relating to the documentation and it does look like good progress is being made. As someone said earlier in this thread, it would be good it run stuff through new (or relatively new) adopters to see if they can get the examples to work without a fight. I'm more than happy to help (and learn!). I to started with OE and failed to get a build to complete. Yocto got me there first time, so it is already much better for a novice 'baker' ! Some worked examples for 'how to do xxx' would also be nice. E.g. 1) How do I configure the kernel ? 2) What do I need to do when I change my recipe to ensure that the changes make it in to the image ? 3) How do I change and add startup scripts ? 4) How do I add data files to the image ? 5) How do I make sure dependencies (e.g. libraries) are included in the image ? i.e. what do DEPENDS, RDEPENDS, etc. do. 6) How can I use a layer to hold my project files ? 7) Do I need to delete tmp/ and rebuild to ensure I've got a valid project build configured ? (i.e. it doesn't rely on staged items that don't build when I bitbake MyProject). 8) How do I make my existing autobuild project in to a recipe ? 9) How do I set / change the root password ? These items would help explain how to create a recipe and to use bbappend. Ideally they should be worded so that they can be followed by someone with a general embedded background who has minimal exposure to embedded linux. However, it probably doesn't want to be an embedded linux primer. This project is already easier to use than many others and is supported by a really knowledgeable group who are willing to help newcomers out. As it grows it would be unreasonable to expect the same (relatively small) group to be able to support a much wider user-base. Comprehensive documentation and non-trivial worked example should help to reduce the workload and allow the group to assist those who have a genuine need of help. Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] xserver-kdrive keyboard support
Do I need to do anything other than have: PREFERED_PROVIDER-virtual/xserver = "xserver-kdrive" XSERVER = "xserver-kdrive-fbdev" to get a working keyboard under kdrive? I've got a system that boots in to an application, but I can't use Ctrl +Alt+Backspace to terminate it... Keyboard works just fine on console screens. Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto usability questions
On 18 Nov 2011, at 21:31, Osier-mixon, Jeffrey wrote: I have created a Cookbook page on the wiki at https://wiki.yoctoproject.org/wiki/Cookbook If you have tested procedures that work with the Yocto Project, please add them to this page. That'll teach me to keep quiet ;-) I'll have a go at drafting something on startup scripts. Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto usability questions
Hi Joshua, On 22 Nov 2011, at 16:49, Joshua Lock wrote: On 22/11/11 04:52, Rainer Koenig wrote: Hi Tom, On 18.11.2011 21:54, Tom Zanussi wrote: I'd be happy to work with anyone who wants to in helping getting something like that started, whether it be a variation on the above, or something from scratch, whatever. I just added a few FAQ entries to the wiki. I used the questions from Chris Tapp and what came to my mind recently. And I used categories, so that there is a hope for a sort of workflow. See https://wiki.yoctoproject.org/wiki/Category:FAQ Any feedback from you, Chris or anyone else as to whether the documentation I linked to for some of those questions is sufficient? If not I can work on enhancing that documentation. Yes, that looks good to me. I've already started a draft for the startup scripts FAQ under the https://wiki.yoctoproject.org/wiki/Cookbook page that Jeffrey started at the end of last week. Where should it go? PS Sorry it's taken a while to reply - Yocto is the night job, not the day one ;-) Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Raspberry Pi
Is anyone on this list considering (or working on) a BSP for the Raspberry Pi (http://www.raspberrypi.org/faqs) ? For those that haven't seen it, it's a credit-card sized 'home pc' aimed primarily at educational users that includes a 700MHz ARM11 core, HDMI, OpenGL ES 2.0, ethernet and audio for about $35. It will be supporting Debian, Fedora and ArchLinux at launch. Looks like a good board for people that want to get in to Yocto / embedded linux. Also looks like it's a good platform for some of my stuff... I would be interested in working on a BSP / distro if anyone is working on it or would like to work on it. Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Raspberry Pi
On 15 Dec 2011, at 22:18, Ilya Dmitrichenko wrote: I'll be happy to join you, Chris :) Thanks. Keep an eye on this list ;-) On 15 Dec 2011, at 22:23, Richard Purdie wrote: I'm not aware of anyone working on this but I like the idea of a BSP for it and it shouldn't be too hard to do. I'd be happy to ensure we have a repository somewhere on git.yoctoproject.org to support this (and any other similar BSP efforts) if that would help? Thanks Richard, that sounds like a good idea. On 16 Dec 2011, at 01:14, Bruce Ashfield wrote: We can also help here @ Wind River. This board is one that's on my short list for the BSP refresh covered by: http://bugzilla.pokylinux.org/show_bug.cgi?id=1634 So I'd like to see it right in the yocto kernel as a hardware reference platform. I'm about to finalize a suggested list of boards and after that, we can see what resources/people want to collaborate on some BSPs. Use as a hardware reference platform is exactly the sort of thing I was think of. On 16 Dec 2011, at 01:28, Jeff Osier-Mixon wrote: Looks like the Raspberry Pi is not quite available yet, sadly! Hopefully we can do one for 1.2. Not quite. It's been due 'any time now' for a couple of months, but it looks as if it's now going to be early 2012. It looks like a few of us are going to be busy in the New Year... Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto & long-term reproducibility of rebuilds
On 30 Jan 2012, at 18:34, Flanagan, Elizabeth wrote: On Mon, Jan 30, 2012 at 8:34 AM, wrote: Hi, I am investigating Yocto for a build system here. Part of my requirements for a build system is auditable/traceable builds that can be replicated long into the future (our company has a 10 year warranty on our products, and we build products for the multidecade term). Initial examination of Yocto shows that it builds packages from a number of different domains online, which will not meet our requirements - we'll have to store these packages to ensure these packages exist in the correct version long into the future. I know we can manually edit the SRC_URI setting in .bb files, but the more general problem of package archiving exists. I would avoid manually editing SRC_URI. Set up PREMIRRORS and BB_FETCH_PREMIRRORONLY. That would ensure that you avoided any upstream contamination. I am interested in any information or recommendations other users of the Yocto system have on how they have solved this sort of design constraint. This sounds like a good a good article for the 'How Do I...' section on the wiki. Or is there already something similar on there? Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Problem building mesa-xlib
I'm trying to build mesa-xlib_7.8.2 under poky-4.0.1 for a legacy system. This has built in the past, but now I'm getting: make[3]: ../../../../../src/glsl/apps/compile: Command not found when I force a complete rebuild on a new system in an attempt to validate that I can build... Any idea why this is happening? The logs don't really show anything more than the above. I can still build the on the old system, but I suspect that's because mesa-xlib has not required a rebuild. It's possible that mesa-xlib was originally built with different options (PREFERED_PROVIDER_virtual/server and/or XSERVER) if that helps. Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Not booting on BeagleBoard xM 0x2
On 4 Apr 2012, at 19:49, Robert Berger wrote: > Garry/Andrea, > > I am currently giving a training based on the Beagle-XM an this error > happened at the same time on 5 boards with a 3.1 kernel. > > >> error pattern. It hangs at this point: >> Waiting for root device /dev/mmcblk0p2... >> mmc0: error -110 whilst initialising SD card >> > > The fix was to change the SD cards and use cards from a different > manufacturer, so yes, it seems to be related to some funny SD card timings. Not sure if it help, but the Raspberry Pi team have been having problems with SD cards as well. Some work, some don't - even when they have the same part numbers. Seems as if some silicon / firmware revision along the way has changed something somewhere... Chris ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Edison BSP SRCREV
I've been following the "BSP Development Example" section of the "Yocto Project Development Manual" for a new BSP called "mybsp". This results in the following in linux-yocto_3.0.bbappend: COMPATIBLE_MACHINE_mybsp = "mybsp" KMACHINE_mybsp = "yocto/standard/common-pc/base" KERNEL_FEATURES_append_mybsp += " cfg/smp.scc" SRCREV_machine_pn-linux-yocto_mybsp ?= "f153b0eb8264dc1e69f59d4c9173619feb4d5bd9" SRCREV_meta_pn-linux-yocto_mybsp ?= "a4ac64fe873f08ef718e2849b88914725dc99c1c" as I'm trying to base the BSP on common-pc/base. However, when I build I get an error telling me that the machine SRCREV is not valid: Log data follows: | ERROR f153b0eb8264dc1e69f59d4c9173619feb4d5bd9 is not a valid commit ID. | The kernel source tree may be out of sync | ERROR: Function 'do_validate_branches' failed (see ... The value is the commit tag I get at http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.0/commit/?h=yocto/standard/common-pc/base I'm guessing I've got the wrong commit ID here ;-) What should I be using? Do I need the commit ID for the 3.0.18 tagged commit at http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.0/tag/?h=yocto/standard/common-pc/base&id=v3.0.18 or something else ? I'm using the tarball method described in the example, not local git. Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Edison BSP SRCREV
On 5 Apr 2012, at 03:49, Bruce Ashfield wrote: > On 12-04-04 6:36 PM, Chris Tapp wrote: >> I've been following the "BSP Development Example" section of the "Yocto >> Project Development Manual" for a new BSP called "mybsp". This results in >> the following in linux-yocto_3.0.bbappend: >> >> COMPATIBLE_MACHINE_mybsp = "mybsp" >> KMACHINE_mybsp = "yocto/standard/common-pc/base" >> KERNEL_FEATURES_append_mybsp += " cfg/smp.scc" >> >> SRCREV_machine_pn-linux-yocto_mybsp ?= >> "f153b0eb8264dc1e69f59d4c9173619feb4d5bd9" >> SRCREV_meta_pn-linux-yocto_mybsp ?= >> "a4ac64fe873f08ef718e2849b88914725dc99c1c" >> >> as I'm trying to base the BSP on common-pc/base. >> >> However, when I build I get an error telling me that the machine SRCREV is >> not valid: >> >> Log data follows: >> | ERROR f153b0eb8264dc1e69f59d4c9173619feb4d5bd9 is not a valid commit ID. >> | The kernel source tree may be out of sync >> | ERROR: Function 'do_validate_branches' failed (see ... >> >> The value is the commit tag I get at >> http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.0/commit/?h=yocto/standard/common-pc/base >> >> I'm guessing I've got the wrong commit ID here ;-) What should I be using? >> Do I need the commit ID for the 3.0.18 tagged commit at >> http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.0/tag/?h=yocto/standard/common-pc/base&id=v3.0.18 >> or something else ? >> >> I'm using the tarball method described in the example, not local git. > > It's like that in edison we switched to a kernel repo that only takes > -stable updates (not unlike the upstream -stable). > > So look for the commit IDs here: > > git://git.yoctoproject.org/linux-yocto-3.0-1.1.x.git > > Sounds like a doc might need a tweak. Thanks, that's got it sorted. And yes, it would be nice if the doc explained how to get the IDs for a base kernel :-) Just need to go through the kernel configuration steps now... Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
