[yocto] adding meta-oracle-java
In looking at the meta-oracle-java README, I see the notes about adding the License statement and switching to .deb packaging. With that done, I get a clean build, but my image boots and I can’t see any evidence that java was included. What am I missing. I have a web app server that in all inclusive and can be setup just by running “java -jar .jar”. But can’t run it without java installed. Jim A -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] adding all the pieces of WiFi to core-image-minimal
On Jan 23, 2015, at 12:37 PM, Gary Thomas g...@mlbassoc.com wrote: On 2015-01-23 10:24, Jim Abernathy wrote: I'm starting a project mostly for self-education. I have already done the project using Ubuntu Server 14.04 using a Intel NUC and a Pandaboard as targets. Now I want to see how easy it is to move it to Yocto. Starting with the NUC, I can boot Dizzy 1.7.1 core-image-minimal and core-image-sato, both built with bitbake and not the prebuilt images. However, core-image-minimal doesn't have WiFi and core-image-sato does, but I don't need all the GUI stuff. It's a headless application. So what is recommended; eliminating the GUI from sato or adding wifi and wpa-supplicant, etc to minimal?? Also any pointers to how to do the adding/subtracting would be most helpful. Once this is working all I have to do is put apache-tomcat, and openjdk-7-jre, then my application. We use just iw wpa-supplicant and set up the configuration files manually (e.g. the wpa-supplicant configurations). Could you help with a little more details. What I envision is adding an append statement of some kind to local.conf to load in the wireless related files to core-image-minimal, same with openjdk-7-jre and tomcat7, but my first efforts have generated some unintelligible error for me. So that’s why I’m looking for direction on where to start with this. Jim A -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] adding all the pieces of WiFi to core-image-minimal
On Jan 26, 2015, at 10:52 AM, Gary Thomas g...@mlbassoc.com wrote: On 2015-01-26 08:26, James Abernathy wrote: On Jan 26, 2015, at 8:49 AM, Gary Thomas g...@mlbassoc.com mailto:g...@mlbassoc.com wrote: On 2015-01-26 06:29, James Abernathy wrote: On Jan 23, 2015, at 12:37 PM, Gary Thomas g...@mlbassoc.com mailto:g...@mlbassoc.com wrote: On 2015-01-23 10:24, Jim Abernathy wrote: I'm starting a project mostly for self-education. I have already done the project using Ubuntu Server 14.04 using a Intel NUC and a Pandaboard as targets. Now I want to see how easy it is to move it to Yocto. Starting with the NUC, I can boot Dizzy 1.7.1 core-image-minimal and core-image-sato, both built with bitbake and not the prebuilt images. However, core-image-minimal doesn't have WiFi and core-image-sato does, but I don't need all the GUI stuff. It's a headless application. So what is recommended; eliminating the GUI from sato or adding wifi and wpa-supplicant, etc to minimal?? Also any pointers to how to do the adding/subtracting would be most helpful. Once this is working all I have to do is put apache-tomcat, and openjdk-7-jre, then my application. We use just iw wpa-supplicant and set up the configuration files manually (e.g. the wpa-supplicant configurations). Could you help with a little more details. What I envision is adding an append statement of some kind to local.conf to load in the wireless related files to core-image-minimal, same with openjdk-7-jre and tomcat7, but my first efforts have generated some unintelligible error for me. So that’s why I’m looking for direction on where to start with this. What was the error you got? I'll bet it was for 'iw' which is a package from meta-oe, so you'll need to add that layer Once you've added the meta-oe layer, you should be able to put this line in your local.conf: CORE_IMAGE_EXTRA_INSTALL += iw wpa-supplicant” Okay, what I don’t get is the fact that without any additional layers, bitbake core-image-sato builds all the WiFi features I need. bitbake core-image-minimal does not. So I’m thinking that there is some CORE_IMAGE_EXTRA_INSTALL statement that can just add what is needed without extra layers. I guess it just doesn’t make sense to me right now. Try using CORE_IMAGE_EXTRA_INSTALL += packagegroup-base-wifi which will bring in 'wireless-tools' and 'wpa-supplicant'. I prefer 'iw' to 'wireless-tools' as it is newer and [IMO] simpler to use. Thanks, I found that I can clean build with just the wpa-supplicant added and I’m hoping that will bring in the wifi drivers. If it does, all I want to do is edit the /etc/interfaces file with the Static IP of the wlan0, the static IP of the eth0 and the wpa-xxx for the WKPA2_PSK information. Do I really need the tools? I don’t need CLI commands to change any network parameters later. Jim A -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] adding all the pieces of WiFi to core-image-minimal
On Jan 26, 2015, at 8:49 AM, Gary Thomas g...@mlbassoc.com wrote: On 2015-01-26 06:29, James Abernathy wrote: On Jan 23, 2015, at 12:37 PM, Gary Thomas g...@mlbassoc.com wrote: On 2015-01-23 10:24, Jim Abernathy wrote: I'm starting a project mostly for self-education. I have already done the project using Ubuntu Server 14.04 using a Intel NUC and a Pandaboard as targets. Now I want to see how easy it is to move it to Yocto. Starting with the NUC, I can boot Dizzy 1.7.1 core-image-minimal and core-image-sato, both built with bitbake and not the prebuilt images. However, core-image-minimal doesn't have WiFi and core-image-sato does, but I don't need all the GUI stuff. It's a headless application. So what is recommended; eliminating the GUI from sato or adding wifi and wpa-supplicant, etc to minimal?? Also any pointers to how to do the adding/subtracting would be most helpful. Once this is working all I have to do is put apache-tomcat, and openjdk-7-jre, then my application. We use just iw wpa-supplicant and set up the configuration files manually (e.g. the wpa-supplicant configurations). Could you help with a little more details. What I envision is adding an append statement of some kind to local.conf to load in the wireless related files to core-image-minimal, same with openjdk-7-jre and tomcat7, but my first efforts have generated some unintelligible error for me. So that’s why I’m looking for direction on where to start with this. What was the error you got? I'll bet it was for 'iw' which is a package from meta-oe, so you'll need to add that layer Once you've added the meta-oe layer, you should be able to put this line in your local.conf: CORE_IMAGE_EXTRA_INSTALL += iw wpa-supplicant” Okay, what I don’t get is the fact that without any additional layers, bitbake core-image-sato builds all the WiFi features I need. bitbake core-image-minimal does not. So I’m thinking that there is some CORE_IMAGE_EXTRA_INSTALL statement that can just add what is needed without extra layers. I guess it just doesn’t make sense to me right now. Jim A -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] adding all the pieces of WiFi to core-image-minimal
I get a clean build when I add: CORE_IMAGE_EXTRA_INSTALL += packagegroup-base-wifi” However, I have no wireless drivers. I must have to add something to add the drivers and firmware to the kernel. Not sure what though. Jim A On Jan 26, 2015, at 11:09 AM, James Abernathy jfaberna...@outlook.com wrote: On Jan 26, 2015, at 10:52 AM, Gary Thomas g...@mlbassoc.com wrote: On 2015-01-26 08:26, James Abernathy wrote: On Jan 26, 2015, at 8:49 AM, Gary Thomas g...@mlbassoc.com mailto:g...@mlbassoc.com wrote: On 2015-01-26 06:29, James Abernathy wrote: On Jan 23, 2015, at 12:37 PM, Gary Thomas g...@mlbassoc.com mailto:g...@mlbassoc.com wrote: On 2015-01-23 10:24, Jim Abernathy wrote: I'm starting a project mostly for self-education. I have already done the project using Ubuntu Server 14.04 using a Intel NUC and a Pandaboard as targets. Now I want to see how easy it is to move it to Yocto. Starting with the NUC, I can boot Dizzy 1.7.1 core-image-minimal and core-image-sato, both built with bitbake and not the prebuilt images. However, core-image-minimal doesn't have WiFi and core-image-sato does, but I don't need all the GUI stuff. It's a headless application. So what is recommended; eliminating the GUI from sato or adding wifi and wpa-supplicant, etc to minimal?? Also any pointers to how to do the adding/subtracting would be most helpful. Once this is working all I have to do is put apache-tomcat, and openjdk-7-jre, then my application. We use just iw wpa-supplicant and set up the configuration files manually (e.g. the wpa-supplicant configurations). Could you help with a little more details. What I envision is adding an append statement of some kind to local.conf to load in the wireless related files to core-image-minimal, same with openjdk-7-jre and tomcat7, but my first efforts have generated some unintelligible error for me. So that’s why I’m looking for direction on where to start with this. What was the error you got? I'll bet it was for 'iw' which is a package from meta-oe, so you'll need to add that layer Once you've added the meta-oe layer, you should be able to put this line in your local.conf: CORE_IMAGE_EXTRA_INSTALL += iw wpa-supplicant” Okay, what I don’t get is the fact that without any additional layers, bitbake core-image-sato builds all the WiFi features I need. bitbake core-image-minimal does not. So I’m thinking that there is some CORE_IMAGE_EXTRA_INSTALL statement that can just add what is needed without extra layers. I guess it just doesn’t make sense to me right now. Try using CORE_IMAGE_EXTRA_INSTALL += packagegroup-base-wifi which will bring in 'wireless-tools' and 'wpa-supplicant'. I prefer 'iw' to 'wireless-tools' as it is newer and [IMO] simpler to use. Thanks, I found that I can clean build with just the wpa-supplicant added and I’m hoping that will bring in the wifi drivers. If it does, all I want to do is edit the /etc/interfaces file with the Static IP of the wlan0, the static IP of the eth0 and the wpa-xxx for the WKPA2_PSK information. Do I really need the tools? I don’t need CLI commands to change any network parameters later. Jim A -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org mailto:yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org mailto:yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] adding all the pieces of WiFi to core-image-minimal
On Jan 26, 2015, at 3:36 PM, Moore, Thomas (FtWorth) thomas.moo...@atk.com wrote: Try building core-image-base or adding packagegroup-base-extended to your IMAGE_INSTALL. This should add the modules and firmware. core-image-minimal is just that and only includes just enough to boot the system. P.S. if you add wifi to your DISTRO_FEATURES, then packagegroup-base-wifi should automatically get added to the image. Checkout meta/recipes-core/packagegroups/packagegroup-base.bb to see how that works. Thomas Interesting! are we talking about doing this in the local.conf? or are we talking about modifying existing recipes? I’d like to do this cleanly and not mess up what’s in the default files. Maybe create my own layer?? Jim A From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Chris Tapp Sent: Monday, January 26, 2015 2:28 PM To: James Abernathy Cc: yocto@yoctoproject.org; Gary Thomas Subject: Re: [yocto] adding all the pieces of WiFi to core-image-minimal On 26 Jan 2015, at 19:31, James Abernathy jfaberna...@outlook.com wrote: I get a clean build when I add: CORE_IMAGE_EXTRA_INSTALL += packagegroup-base-wifi However, I have no wireless drivers. I must have to add something to add the drivers and firmware to the kernel. Not sure what though. I'm not an expert here, but I think that adding kernel-modules and linux-firmware to your extra_install should give you what you need. Jim A On Jan 26, 2015, at 11:09 AM, James Abernathy jfaberna...@outlook.com wrote: On Jan 26, 2015, at 10:52 AM, Gary Thomas g...@mlbassoc.com wrote: On 2015-01-26 08:26, James Abernathy wrote: On Jan 26, 2015, at 8:49 AM, Gary Thomas g...@mlbassoc.com mailto:g...@mlbassoc.com wrote: On 2015-01-26 06:29, James Abernathy wrote: On Jan 23, 2015, at 12:37 PM, Gary Thomas g...@mlbassoc.com mailto:g...@mlbassoc.com wrote: On 2015-01-23 10:24, Jim Abernathy wrote: I'm starting a project mostly for self-education. I have already done the project using Ubuntu Server 14.04 using a Intel NUC and a Pandaboard as targets. Now I want to see how easy it is to move it to Yocto. Starting with the NUC, I can boot Dizzy 1.7.1 core-image-minimal and core-image-sato, both built with bitbake and not the prebuilt images. However, core-image-minimal doesn't have WiFi and core-image-sato does, but I don't need all the GUI stuff. It's a headless application. So what is recommended; eliminating the GUI from sato or adding wifi and wpa-supplicant, etc to minimal?? Also any pointers to how to do the adding/subtracting would be most helpful. Once this is working all I have to do is put apache-tomcat, and openjdk-7-jre, then my application. We use just iw wpa-supplicant and set up the configuration files manually (e.g. the wpa-supplicant configurations). Could you help with a little more details. What I envision is adding an append statement of some kind to local.conf to load in the wireless related files to core-image-minimal, same with openjdk-7-jre and tomcat7, but my first efforts have generated some unintelligible error for me. So that's why I'm looking for direction on where to start with this. What was the error you got? I'll bet it was for 'iw' which is a package from meta-oe, so you'll need to add that layer Once you've added the meta-oe layer, you should be able to put this line in your local.conf: CORE_IMAGE_EXTRA_INSTALL += iw wpa-supplicant Okay, what I don't get is the fact that without any additional layers, bitbake core-image-sato builds all the WiFi features I need. bitbake core-image-minimal does not. So I'm thinking that there is some CORE_IMAGE_EXTRA_INSTALL statement that can just add what is needed without extra layers. I guess it just doesn't make sense to me right now. Try using CORE_IMAGE_EXTRA_INSTALL += packagegroup-base-wifi which will bring in 'wireless-tools' and 'wpa-supplicant'. I prefer 'iw' to 'wireless-tools' as it is newer and [IMO] simpler to use. Thanks, I found that I can clean build with just the wpa-supplicant added and I'm hoping that will bring in the wifi drivers. If it does, all I want to do is edit the /etc/interfaces file with the Static IP of the wlan0, the static IP of the eth0 and the wpa-xxx for the WKPA2_PSK information. Do I really need the tools? I don't need CLI commands to change any network parameters later. Jim A -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto
Re: [yocto] adding all the pieces of WiFi to core-image-minimal
On Jan 26, 2015, at 3:28 PM, Chris Tapp opensou...@keylevel.com wrote: On 26 Jan 2015, at 19:31, James Abernathy jfaberna...@outlook.com mailto:jfaberna...@outlook.com wrote: I get a clean build when I add: CORE_IMAGE_EXTRA_INSTALL += packagegroup-base-wifi” However, I have no wireless drivers. I must have to add something to add the drivers and firmware to the kernel. Not sure what though. I'm not an expert here, but I think that adding kernel-modules and linux-firmware to your extra_install should give you what you need. Well you are right! All I added was: CORE_IMAGE_EXTRA_INSTALL += “ packagegroup-base-wifi kernel-modules linux-firmware” After booting this image via USB on a NUC, I had all the drivers for LAN and WiFi devices and the 80211 firmware so I should be able to make it work now. Thanks all, Jim A Jim A On Jan 26, 2015, at 11:09 AM, James Abernathy jfaberna...@outlook.com mailto:jfaberna...@outlook.com wrote: On Jan 26, 2015, at 10:52 AM, Gary Thomas g...@mlbassoc.com mailto:g...@mlbassoc.com wrote: On 2015-01-26 08:26, James Abernathy wrote: On Jan 26, 2015, at 8:49 AM, Gary Thomas g...@mlbassoc.com mailto:g...@mlbassoc.com mailto:g...@mlbassoc.com mailto:g...@mlbassoc.com wrote: On 2015-01-26 06:29, James Abernathy wrote: On Jan 23, 2015, at 12:37 PM, Gary Thomas g...@mlbassoc.com mailto:g...@mlbassoc.com mailto:g...@mlbassoc.com mailto:g...@mlbassoc.com wrote: On 2015-01-23 10:24, Jim Abernathy wrote: I'm starting a project mostly for self-education. I have already done the project using Ubuntu Server 14.04 using a Intel NUC and a Pandaboard as targets. Now I want to see how easy it is to move it to Yocto. Starting with the NUC, I can boot Dizzy 1.7.1 core-image-minimal and core-image-sato, both built with bitbake and not the prebuilt images. However, core-image-minimal doesn't have WiFi and core-image-sato does, but I don't need all the GUI stuff. It's a headless application. So what is recommended; eliminating the GUI from sato or adding wifi and wpa-supplicant, etc to minimal?? Also any pointers to how to do the adding/subtracting would be most helpful. Once this is working all I have to do is put apache-tomcat, and openjdk-7-jre, then my application. We use just iw wpa-supplicant and set up the configuration files manually (e.g. the wpa-supplicant configurations). Could you help with a little more details. What I envision is adding an append statement of some kind to local.conf to load in the wireless related files to core-image-minimal, same with openjdk-7-jre and tomcat7, but my first efforts have generated some unintelligible error for me. So that’s why I’m looking for direction on where to start with this. What was the error you got? I'll bet it was for 'iw' which is a package from meta-oe, so you'll need to add that layer Once you've added the meta-oe layer, you should be able to put this line in your local.conf: CORE_IMAGE_EXTRA_INSTALL += iw wpa-supplicant” Okay, what I don’t get is the fact that without any additional layers, bitbake core-image-sato builds all the WiFi features I need. bitbake core-image-minimal does not. So I’m thinking that there is some CORE_IMAGE_EXTRA_INSTALL statement that can just add what is needed without extra layers. I guess it just doesn’t make sense to me right now. Try using CORE_IMAGE_EXTRA_INSTALL += packagegroup-base-wifi which will bring in 'wireless-tools' and 'wpa-supplicant'. I prefer 'iw' to 'wireless-tools' as it is newer and [IMO] simpler to use. Thanks, I found that I can clean build with just the wpa-supplicant added and I’m hoping that will bring in the wifi drivers. If it does, all I want to do is edit the /etc/interfaces file with the Static IP of the wlan0, the static IP of the eth0 and the wpa-xxx for the WKPA2_PSK information. Do I really need the tools? I don’t need CLI commands to change any network parameters later. Jim A -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org mailto:yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org mailto:yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org mailto:yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- Chris Tapp opensou...@keylevel.com mailto:opensou...@keylevel.com
Re: [yocto] adding all the pieces of WiFi to core-image-minimal
Okay, here’s the answer for me. It should never have been core-image-minimal. I just view that as not core-image-sato, meaning no gui. If you take standard dizzy and change machine to nuc, then bitbake core-image-base, you get all the wifi, wpa-supplicant that you need. So the trivial answer was that core-image-base is the console, CLI version I needed to start with all along. Thanks for all the help. Jim A On Jan 26, 2015, at 6:22 PM, Paul Eggleton paul.eggle...@linux.intel.com wrote: On Monday 26 January 2015 16:37:37 Jim Abernathy wrote: From: thomas.moo...@atk.com To: jfaberna...@outlook.com CC: opensou...@keylevel.com; yocto@yoctoproject.org; g...@mlbassoc.com Subject: RE: [yocto] adding all the pieces of WiFi to core-image-minimal Date: Mon, 26 Jan 2015 21:04:54 + For now, I'd just get everything working with the local.conf: DISTRO_FEATURES += wifi bitbake core-image-base Ultimately, you may want to make a custom machine and distro config and incorporate all of the things you've specified in local.conf in those configs. For example, I have a system that's an intel-based single-board computer with several expansion cards. I've created a machine configuration to define the basic hardware components (features, drivers, etc). I've also created a custom distro because we prefer system over systemv and to include some other non-machine specific packages. Finally, I've created a custom image that includes some other extras. The power of local.conf is nice, but it's a little tricky transitioning from that to more of a BSP approach like I described above because most people just say to add it to your local.conf, but that's not really how it should be done at the end. Think global variables vs classes. P.S. Never edit anything in the poky folder. If you want to modify an existing recipe, create a new layer with a bbappend and modify away. Thomas I tried just adding DISTRO_FEATURES += wifi to the local.conf and bitbaking core-image-base, but I got a lot of errors: NOTE: Resolving any missing task queue dependencies ERROR: Nothing PROVIDES 'glibc' ERROR: glibc was skipped: missing required distro feature 'ipv4' (not in DISTRO_FEATURES) ERROR: Required build target 'core-image-base' has no buildable providers. Missing or unbuildable dependency chain was: You're getting this error because you're actually replacing the value with wifi not adding it, because the default value is actually set *after* local.conf is parsed using ?=, so having set a value in local.conf, it's already set and thus ?= has no effect. Then we get to parsing the glibc recipe and that immediately fails because it states that all features in DISTRO_FEATURES_LIBC are required, and you've removed those. (As a side note I really dislike how this latter bit has been implemented, but at least it breaks early rather than what used to happen where it would get up to compiling glibc and then fail). The correct way to add to DISTRO_FEATURES in local.conf would be to use DISTRO_FEATURES_append = ... (and don't forget the leading space in the value). However, that said, I'd guess that if your configuration is the default poky or reasonably close to it, DISTRO_FEATURES already contains wifi, so there shouldn't even be a need to add it; particularly as you've already suggested wifi was working with core-image-sato. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Meta Intel / Cedartrail / Denzil - how to get unionfs in the kernel
On Mon, Oct 8, 2012 at 12:28 PM, Saxena, Rahul rahul.sax...@intel.comwrote: -Original Message- From: Bruce Ashfield [mailto:bruce.ashfi...@gmail.com] Sent: Monday, October 08, 2012 7:00 AM To: Chris Tapp Cc: Saxena, Rahul; yocto@yoctoproject.org Project Subject: Re: [yocto] Meta Intel / Cedartrail / Denzil - how to get unionfs in the kernel On Mon, Oct 8, 2012 at 3:58 AM, Chris Tapp opensou...@keylevel.com wrote: On 7 Oct 2012, at 22:41, Bruce Ashfield wrote: On Sun, Oct 7, 2012 at 6:08 PM, Chris Tapp opensou...@keylevel.com wrote: On 7 Oct 2012, at 03:00, Saxena, Rahul wrote: Try adding the unionfs feature (below) to your kernel: http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.0/tree/meta /cfg/kernel-cache/features/unionfs?h=meta create a file my_cedartrail.scc with following line: include features/unionfs/unionfs.scc put this file in a dir linux-yocto, the dir being created in meta-cedartrail/recipes-kernel/linux add following line in meta-cedartrail/recipes-kernel/Linux/linux-yocto_3.0.bbappend SRC_URI +=file://my_cedartrail.scc Thanks - I thought just running 'menuconfig' would allow me to enable it (for a quick test). However, this still doesn't seem to be working. I can see that 'my_cedartrail.scc' gets fetched in to the build area, but I still don't see CONFIG_UNION_FS if I run 'menuconfig'. There is also no 'unionfs' folder in fs/ of the build tree. Also, if I specify an invalid feature (e.g. feature2/unionfs/unionfs.scc) I'm not seeing any diagnostic. unionfs was never merged to the 3.0 kernel, I re-added it to the development trees for 3.2 and the 3.4 kernel (aufs for the 3.6 tree at the moment). The meta data is carried forward from the older kernels as a placeholder and is documented in the .scc file itself: --- kconf non-hardware unionfs.cfg # commented pending update to a newer version ported to 2.6.35+ # patch unionfs-2.5.4-integration.patch --- So to get unionfs in the 3.0 kernel, we'd need a port .. but since we've moved on quite a bit past 3.0, I don't know of any pending ports myself. Thanks Bruce. I guess I need to ask the Intel guys if there are any plans to move Cedartrail on from 3.0 ? It will have to happen post yocto 1.3 (as far as I know), since the 3.0 kernel will be dropped at that point. For the short term, it's likely easier to backport/update unionfs than it would be to update the BSP .. but I can't speak for the time to be spent doing it :) Cheers, Bruce Chris, There are no plans to port Cedartrail BSP to support any other Kernel other than 3.0. The reason is that the Cedartrail PVR Graphics driver is supported only for 3.0 kernel. Rahul 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. Jim A Cheers, Bruce -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Chris Tapp Sent: Saturday, October 06, 2012 5:43 PM To: yocto@yoctoproject.org Project Subject: [yocto] Meta Intel / Cedartrail / Denzil - how to get unionfs in the kernel I' trying to enable unionfs in the 3.0.32 kernel for the cedartrail BSP under Denzil 7.0.1. However, the CONFIG_UNION_FS config flag isn't in the .config ... Is there something else I need to enable, or do I need to find another way? 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 -- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end Chris Tapp opensou...@keylevel.com www.keylevel.com -- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Correct procedure for rebuilding after a git pull
So I'm looking for the right way to do this. Here's the scenario. I do a complete build of the image core-image-cdv-media for the cedartrail machine. No changes from the basic BSP, except for the addition of my meta-layer that include test audios and videos to help test the media playback using gst-launch. I'm tracking the latest Denzil branch. So everything works well to this point. Now I see a bunch of patches pushed to Denzil branch and I want to test them. My build directory is untouched since the successful build before. What do I do to rebuild my project to include the latest patches. I've tried things like bitbake -c cleansstate core-image-cdv-media before the new bitbake core-image-cdv-media and I've tried just rebaking by itself. Something always fails. I've learned that to really test I have to completely delete my build directory saving only my local.conf and bblayer.conf. Am I missing something or is a complete rebuild the only way to get the new patches in and a successful build?? Jim A ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Correct procedure for rebuilding after a git pull
On Wed, Oct 3, 2012 at 9:21 AM, Burton, Ross ross.bur...@intel.com wrote: On 3 October 2012 14:05, James Abernathy jfaberna...@gmail.com wrote: Now I see a bunch of patches pushed to Denzil branch and I want to test them. My build directory is untouched since the successful build before. What do I do to rebuild my project to include the latest patches. I've tried things like bitbake -c cleansstate core-image-cdv-media before the new bitbake core-image-cdv-media and I've tried just rebaking by itself. Something always fails. I've learned that to really test I have to completely delete my build directory saving only my local.conf and bblayer.conf. Just git pull ; bitbake should work -- all of the packages that changed will rebuild without any problems. That's the theory, and everyone who works against oe-core/poky master does this ever day (including me). Can you give an example of something that fails? The most recent patch update to Denzil included some Cedartrail BSP updates to the CDV PVR driver. I was traveling last week and I was out of date on my poky and meta-intel by at least that long. Monday was the pull. So when the rebuild happened, I got a cdv-pvr driver configuration error. I didn't look into why because of my experience of this taking longer than a complete rebuild. So I deleted the build directory and did the rebuild. And I didn't get the error on the rebuild. Everything still works fine for me on that BSP. Jim A Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Denzil / Cedartrail on DN2800MT
I used Denzil branch to pick up the latest GFX drivers changed added recently. Jim A Sent from my iPhone On Sep 7, 2012, at 3:58 PM, Chris Tapp opensou...@keylevel.com wrote: Has anyone used the Cedartrail BSP under Denzil 7.0.1 on a DN2800MT motherboard? I've just built core-image-sato and used the hddimg to boot from a USB drive, but 'X' won't start and reports that it can't find a screen. 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
Re: [yocto] build failures after recent pull
I failed to mention this is on the denzil branch of both poky and meta-intel. JIm A On Thu, Jul 19, 2012 at 3:18 PM, Jim Abernathy jfaberna...@gmail.comwrote: Something that got pushed recently has broken the tools. To keep the debug simple, I went back and tried to just build an old stable platform, the n450. Below is the error: NOTE: Unpacking home/jim/yocto-downloads/gnu-**config-yocto-2011.tgz to /build/baryon-denzil/tmp/work/**x86_64-linux/gnu-config-** native-2011-r1/ tar (child): home/jim/yocto-downloads/gnu-**config-yocto-2011.tgz: Cannot open: No such file or directory tar (child): Error is not recoverable: exiting now tar: Child returned status 2 tar: Error is not recoverable: exiting now ERROR: Function failed: Unpack failure for URL: 'http://downloads.** yoctoproject.org/releases/gnu-**config/gnu-config-yocto-**2011.tgzhttp://downloads.yoctoproject.org/releases/gnu-config/gnu-config-yocto-2011.tgz'. Unpack command PATH=/build/baryon-denzil/**tmp/sysroots/x86_64-linux/usr/ **bin/core2-linux:/build/baryon-**denzil/tmp/sysroots/x86_64-** linux/usr/bin:/build/baryon-**denzil/tmp/sysroots/x86_64-** linux/usr/sbin:/build/baryon-**denzil/tmp/sysroots/x86_64-** linux/usr/bin:/build/baryon-**denzil/tmp/sysroots/x86_64-** linux/sbin:/build/baryon-**denzil/tmp/sysroots/x86_64-** linux//bin:/home/jim/poky/**scripts/native-intercept:/** home/jim/poky/bitbake/bin/:/**home/jim/poky/scripts:/home/** jim/poky/bitbake/bin/:/home/**jim/poky/scripts:/home/jim/** poky/bitbake/bin/:/home/jim/**poky/scripts:/home/jim/poky/** bitbake/bin/:/usr/lib/lightdm/**lightdm:/usr/local/sbin:/usr/** local/bin:/usr/sbin:/usr/bin:/**sbin:/bin:/usr/games:/home/**jim/poky/scripts tar xz --no-same-owner -f home/jim/yocto-downloads/gnu-**config-yocto-2011.tgz failed with return value 2 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] build failures after recent pull
On Thu, Jul 19, 2012 at 3:33 PM, James Abernathy jfaberna...@gmail.comwrote: I failed to mention this is on the denzil branch of both poky and meta-intel. This does not happen on Denzil 7.0.1 tarball. Jim A JIm A On Thu, Jul 19, 2012 at 3:18 PM, Jim Abernathy jfaberna...@gmail.comwrote: Something that got pushed recently has broken the tools. To keep the debug simple, I went back and tried to just build an old stable platform, the n450. Below is the error: NOTE: Unpacking home/jim/yocto-downloads/gnu-**config-yocto-2011.tgz to /build/baryon-denzil/tmp/work/**x86_64-linux/gnu-config-** native-2011-r1/ tar (child): home/jim/yocto-downloads/gnu-**config-yocto-2011.tgz: Cannot open: No such file or directory tar (child): Error is not recoverable: exiting now tar: Child returned status 2 tar: Error is not recoverable: exiting now ERROR: Function failed: Unpack failure for URL: 'http://downloads.** yoctoproject.org/releases/gnu-**config/gnu-config-yocto-**2011.tgzhttp://downloads.yoctoproject.org/releases/gnu-config/gnu-config-yocto-2011.tgz'. Unpack command PATH=/build/baryon-denzil/** tmp/sysroots/x86_64-linux/usr/**bin/core2-linux:/build/baryon-** denzil/tmp/sysroots/x86_64-**linux/usr/bin:/build/baryon-** denzil/tmp/sysroots/x86_64-**linux/usr/sbin:/build/baryon-** denzil/tmp/sysroots/x86_64-**linux/usr/bin:/build/baryon-** denzil/tmp/sysroots/x86_64-**linux/sbin:/build/baryon-** denzil/tmp/sysroots/x86_64-**linux//bin:/home/jim/poky/** scripts/native-intercept:/**home/jim/poky/bitbake/bin/:/** home/jim/poky/scripts:/home/**jim/poky/bitbake/bin/:/home/** jim/poky/scripts:/home/jim/**poky/bitbake/bin/:/home/jim/** poky/scripts:/home/jim/poky/**bitbake/bin/:/usr/lib/lightdm/** lightdm:/usr/local/sbin:/usr/**local/bin:/usr/sbin:/usr/bin:/** sbin:/bin:/usr/games:/home/**jim/poky/scripts tar xz --no-same-owner -f home/jim/yocto-downloads/gnu-**config-yocto-2011.tgz failed with return value 2 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-baryon flexibility
On Tue, Jul 17, 2012 at 6:19 PM, Joshua Lock j...@linux.intel.com wrote:
On Tue, 2012-07-17 at 15:24 -0400, Jim Abernathy wrote:
In an effort to explore how independent a layer could be to the
underlying hardware, I took the meta-baryon NAS layer and got it built
from master using the n450 BSP. With that working I decided to replace
the n450 with sugarbay. While the n450 can support X11 and sato, it was
not generated by design in the baryon build.
However, when I changed to sugarbay, the build stops because X11 is
needed. To get around this I had to comment out some things in the
conf/machine/sugarbay.conf file in the BSP.
#XSERVER ?= ${XSERVER_IA32_BASE} \
# ${XSERVER_IA32_EXT} \
# ${XSERVER_IA32_I965} \
#
#VA_FEATURES ?= gst-va-intel va-intel
#MACHINE_EXTRA_RRECOMMENDS += ${VA_FEATURES}
Why didn't I have to do this in the n450??
The key piece is the MACHINE_EXTRA_RRECOMMENDS, which is telling Poky to
recommend the gst-va-intel and va-intel recipes when building this
machine.
RRECOMMENDS are automatically installed as a dependency (in this case,
of task-machine-base, see task-base.bbclass) but can be removed without
causing the package which pulled it in to be removed (see the Poky
reference manual glossary on *_RRECOMMENDS).
http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html
I'd suggest the RRECOMMENDS actually be added at a more granular level
than the machine. Perhaps you could file a bug against the BSP?
So if I understand this, it would be better for one of the image.bb files
that focused on media to include this particular RRECOMMENDS statement.
That way others not interested in media and graphic could still use the BSP
unchanged.
In my case the baryon build would work without modifiying the BSP
Jim A
Cheers,
Joshua
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] menuconfig vs. config fragments?
my goal of this test was to see if I could use the n450 BSP as a starting point for a BSP to support my Acer Aspire One n450 based netbook. The core-image-sato will boot from USB key on the netbook if I use the ZIP drive format for the USB key, but the current n450 BSP doesn't include the drivers for the networking hardware in the netbook. I found by testing, using the menuconfig option documented in the Developer Manual Appendix B example, that I needed to add 2 parameters to the .config: CONFIG_ATH9K_PCI CONFIG_ATL1C To make this change easier to manage and more permanent, I thought about creating a config fragment. I put the config parameters in a file, myconfig, in the linux-yocto directory at the same level as the linux-yocto_3.2.bbappend file, where I added: SRC_URI += file//myconfig I can see from the tmp/work directory that bitbake found my myconfig file and copied it over, but the .config file used in the building of the kernel didn't have the parameters listed and obviously, the drivers didn't make it. Is there something else to do to get these config parameters included as config fragments? Is there some tool reviewing the config parameters and throwing my 2 out for some reason? The only way I've gotten this to work is with the bitbake linux-yocto -c menuconfig command and manually adding the parameters. Jim A ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] menuconfig vs. config fragments?
On Mon, Jul 9, 2012 at 8:07 AM, Bruce Ashfield bruce.ashfi...@gmail.comwrote: On Mon, Jul 9, 2012 at 6:42 AM, Andrei Gherzan and...@gherzan.ro wrote: On Mon, Jul 9, 2012 at 1:39 PM, James Abernathy jfaberna...@gmail.com wrote: my goal of this test was to see if I could use the n450 BSP as a starting point for a BSP to support my Acer Aspire One n450 based netbook. The core-image-sato will boot from USB key on the netbook if I use the ZIP drive format for the USB key, but the current n450 BSP doesn't include the drivers for the networking hardware in the netbook. I found by testing, using the menuconfig option documented in the Developer Manual Appendix B example, that I needed to add 2 parameters to the .config: CONFIG_ATH9K_PCI CONFIG_ATL1C To make this change easier to manage and more permanent, I thought about creating a config fragment. I put the config parameters in a file, myconfig, in the linux-yocto directory at the same level as the linux-yocto_3.2.bbappend file, where I added: SRC_URI += file//myconfig Try to use myconfig.cfg. This would be the key part, since as a few noted, .cfg is what triggers the fragment processing to actually notice the file and stack it after the base / defined configuration. Cheers, Bruce I'm testing it now, but it sound like the problem. So the Developer Manual uses the .cfg in the example, but the BSP Guide does not. That's an area to fix. Since this is critical,it needs to be pointed out, in my mind. JIm A @g ___ 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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Documentation improvement
On Fri, Jul 6, 2012 at 5:06 PM, Rifenbark, Scott M scott.m.rifenb...@intel.com wrote: Jim, ** ** I am looking at that section in the BSP Guide and it is actually out of date regarding the 1.2.10 section. In the section it lists the linux-yocto_3.0.bbappend file (which is probably lagging as it should be 3.2). Anyway, the listing uses KERNEL_FEATURES and I believe that KBRANCH is now used. I am going to work on this section and get it up to speed and then address the issue you originally brought up, which is getting the best description for config fragments inside the dev manual. ** ** ScottR ** Scott, I found out over the weekend that the config fragment file needs to have the .cfg extension. This would agree with the example in the Developer Manual, but make the BSP Guide in error, as it uses no extension. A note to the .cfg requirement would seem to be a required addition. JIm A ** *From:* yocto-boun...@yoctoproject.org [mailto: yocto-boun...@yoctoproject.org] *On Behalf Of *jfabernathy *Sent:* Friday, July 06, 2012 11:59 AM *To:* yocto@yoctoproject.org *Subject:* [yocto] Documentation improvement ** ** I was looking at the Yocto Development Manual (Latest), section 4.6.2. Creating Config Fragments. I was confused about the file statement and the naming of the directory to locate the fragment file until I found a similar discussion in the BSP Guide (lastest) section 1.2.10. Linux Kernel Configuration. The section there is much more understandable. I think we need to modify the development manual or have it point to the BSP manual. The text from there (below) I think is better. I still think it's confusing about the naming of the subdirectory where the myconfig goes. Maybe a complete example would be good. For example, suppose you had a set of configuration options in a file called myconfig. If you put that file inside a directory named linux-yoctoand then added a SRC_URI statement such as the following to the append file, those configuration options will be picked up and applied when the kernel is built. SRC_URI += file://myconfig As mentioned earlier, you can group related configurations into multiple files and name them all in the SRC_URI statement as well. For example, you could group separate configurations specifically for Ethernet and graphics into their own files and add those by using a SRC_URI statement like the following in your append file: SRC_URI += file://myconfig \ file://eth.cfg \ file://gfx.cfg ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] menuconfig vs. config fragments?
On Mon, Jul 9, 2012 at 8:13 AM, James Abernathy jfaberna...@gmail.comwrote: On Mon, Jul 9, 2012 at 8:07 AM, Bruce Ashfield bruce.ashfi...@gmail.comwrote: On Mon, Jul 9, 2012 at 6:42 AM, Andrei Gherzan and...@gherzan.ro wrote: On Mon, Jul 9, 2012 at 1:39 PM, James Abernathy jfaberna...@gmail.com wrote: my goal of this test was to see if I could use the n450 BSP as a starting point for a BSP to support my Acer Aspire One n450 based netbook. The core-image-sato will boot from USB key on the netbook if I use the ZIP drive format for the USB key, but the current n450 BSP doesn't include the drivers for the networking hardware in the netbook. I found by testing, using the menuconfig option documented in the Developer Manual Appendix B example, that I needed to add 2 parameters to the .config: CONFIG_ATH9K_PCI CONFIG_ATL1C To make this change easier to manage and more permanent, I thought about creating a config fragment. I put the config parameters in a file, myconfig, in the linux-yocto directory at the same level as the linux-yocto_3.2.bbappend file, where I added: SRC_URI += file//myconfig Try to use myconfig.cfg. This would be the key part, since as a few noted, .cfg is what triggers the fragment processing to actually notice the file and stack it after the base / defined configuration. Cheers, Bruce I'm testing it now, but it sound like the problem. So the Developer Manual uses the .cfg in the example, but the BSP Guide does not. That's an area to fix. Since this is critical,it needs to be pointed out, in my mind. JIm A Adding the .cfg extension does indeed fix my problem. Thanks for the help. Jim A @g ___ 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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] build failure on denzil-7.0 n450 part 2
On Jul 8, 2012, at 1:46 AM, Tom Zanussi wrote: On Sat, 2012-07-07 at 12:08 -0500, Tom Zanussi wrote: On Sat, 2012-07-07 at 11:59 -0400, jfabernathy wrote: Since I started over on my build from the long thread on this subject, I thought I'd start another thread on the issue. I took the tarball for poky-denzil-7.0 and extracted it into my home directory. After cd'ing into poky-denzil-7.0, I extracted the n450-denzil-7.0 tarball. I setup to run a standard default n450 core-image-sato, only changing the linux-yocto_3.2.bbappend by adding in: SRCREV_machine_pn-linux-yocto_n450 = 9d32bb075e349cc69c7af42b60f6715c5d8c972e SRCREV_meta_pn-linux-yocto_n450 ?= ee78519365bdb25287703bbc31c06b193263c654 I still get build errors similar to the ones I got with the git repository cloned poky. Log file below: NOTE: make -C /build/n450-denzil/tmp/work/n450-poky-linux/linux-yocto-3.2.11+git1+ee78519365bdb25287703bbc31c06b193263c654_1+9d32bb075e349cc69c7af42b60f6715c5d8c972e-r1/linux/tools/perf CC=i586-poky-linux-gcc -m32-march=core2 -msse3 -mtune=generic -mfpmath=sse --sysroot=/build/n450-denzil/tmp/sysroots/n450 LD=i586-poky-linux-ld --sysroot=/build/n450-denzil/tmp/sysroots/n450 prefix=/usr NO_NEWT=1 NO_DWARF=1 make: Entering directory `/build/n450-denzil/tmp/work/n450-poky-linux/linux-yocto-3.2.11+git1+ee78519365bdb25287703bbc31c06b193263c654_1+9d32bb075e349cc69c7af42b60f6715c5d8c972e-r1/linux/tools/perf' Makefile:493: libperl not found, disables Perl scripting support. Please install libperl-dev or perl-devel PERF_VERSION = 3.2.11.629.g382eda3 make: Leaving directory `/build/n450-denzil/tmp/work/n450-poky-linux/linux-yocto-3.2.11+git1+ee78519365bdb25287703bbc31c06b193263c654_1+9d32bb075e349cc69c7af42b60f6715c5d8c972e-r1/linux/tools/perf' make: Entering directory `/build/n450-denzil/tmp/work/n450-poky-linux/linux-yocto-3.2.11+git1+ee78519365bdb25287703bbc31c06b193263c654_1+9d32bb075e349cc69c7af42b60f6715c5d8c972e-r1/linux/tools/perf' Makefile:493: libperl not found, disables Perl scripting support. Please install libperl-dev or perl-devel Yeah, you're still getting the new kernel commits, though you shouldn't be, I'll try the same thing here... I tried the same thing here, poky denzil and n450 denzil and it built fine with no changes at all. Somehow your setup is causing the last SRCREVS to be picked up instead of what should be - since n450 specifies no SRCREVs, the default SRCREVs from linux-yocto_3.2.bb should be getting picked up, and you should see those in the build directory name for the kernel as well: recipes-kernel/linux/linux-yocto_3.2.bb:SRCREV_meta ?= b14a08f5c7b469a5077c10942f4e1aec171faa9d recipes-kernel/linux/linux-yocto_3.2.bb:SRCREV_machine ?= 01e948c2bdf7f5ad9f2b30047a8d3493a1a2880a build/tmp/work/n450-poky-linux/linux-yocto-3.2.11+git1+b14a08f5c7b469a5077c10942f4e1aec171faa9d_1+01e948c2bdf7f5ad9f2b30047a8d3493a1a2880a-r1 Since the default SRCREVs use ?= to assign, the likely problem is that you already have them assigned to something else before those. Tom Well, that is strange. Before I started I deleted the /build directory, so there are no previous build on the computer. I deleted the common download area, so there are no previous downloads. I started with the BSP tarballs for poky denzil and n450 denzil. Not sure where it could be getting assigned. I'm using Ubuntu 12.04. Jim A Tom GEN common-cmds.h * new build flags or prefix CC perf.o CC builtin-annotate.o CC builtin-bench.o CC bench/sched-messaging.o CC bench/sched-pipe.o CC bench/mem-memcpy.o CC builtin-diff.o CC builtin-evlist.o CC builtin-help.o CC builtin-sched.o CC builtin-buildid-list.o CC builtin-buildid-cache.o CC builtin-list.o CC builtin-record.o CC builtin-report.o CC builtin-stat.o CC builtin-timechart.o CC builtin-top.o CC builtin-script.o CC builtin-probe.o CC builtin-kmem.o CC builtin-lock.o CC builtin-kvm.o CC builtin-test.o CC builtin-inject.o CC util/abspath.o CC util/alias.o CC util/annotate.o CC util/build-id.o CC util/config.o CC util/ctype.o CC util/debugfs.o CC util/environment.o CC util/event.o CC util/evlist.o CC util/evsel.o CC util/exec_cmd.o CC util/help.o CC util/levenshtein.o CC util/parse-options.o CC util/parse-events.o CC util/path.o CC util/rbtree.o CC util/bitmap.o CC util/hweight.o CC util/run-command.o CC util/quote.o CC util/strbuf.o CC util/string.o CC util/strlist.o CC util/strfilter.o CC util/top.o CC util/usage.o CC util/wrapper.o CC util/sigchain.o CC util/symbol.o CC util/color.o CC util/pager.o CC util/header.o CC util/callchain.o CC util/values.o CC util/debug.o
Re: [yocto] build failure on denzil - n450
On Fri, Jul 6, 2012 at 4:01 PM, Tom Zanussi tom.zanu...@intel.com wrote: On Fri, 2012-07-06 at 15:48 -0400, jfabernathy wrote: On 07/06/2012 02:57 PM, Tom Zanussi wrote: On Fri, 2012-07-06 at 14:48 -0400, jfabernathy wrote: On 07/06/2012 02:35 PM, Tom Zanussi wrote: On Fri, 2012-07-06 at 13:36 -0400, jfabernathy wrote: On 07/06/2012 10:59 AM, Tom Zanussi wrote: On Fri, 2012-07-06 at 10:47 -0400, jfabernathy wrote: On 07/06/2012 10:44 AM, Tom Zanussi wrote: On Fri, 2012-07-06 at 10:20 -0400, jfabernathy wrote: Something has changes very recently. I was building with a fresh clone of poky and meta-intel. checked out Denzil on both. only modified to support the meta-n450 layer, the parallel options and the local download directory. Are you using a local clone of the kernel i.e. using AUTOREV? There are currently a few patches that you'd only get with AUTOREV that the offical SRCREVs in the recipe prevent from getting into normal builds at the moment. Tom I have local kernels on the system, but I hope I'm not using them. The last good build I did used a local kernel. However, I started by blowing away the poky dir and the /build dir. I did a new clone of poky and meta-intel and checkout the denzil branch in both (not tag) Oh, I see now, 450 doesn't specify a kernel SRCREV like the other BSPs. You can fix that locally by changing the empty SRCREVs in the n450 kernel recipe e.g. SRCREV_machine_pn-linux-yocto_n450 = 9d32bb075e349cc69c7af42b60f6715c5d8c972e SRCREV_meta_pn-linux-yocto_n450 ?= ee78519365bdb25287703bbc31c06b193263c654 This is exactly the reason it's not good to use floating kernel SRCREVs. So this fixes the issue, but I just want to know how you knew which commit strings to use is this case? I finally found them, but not sure why you pick these particular ones. Well, it's kind of a long story already. Basically, there was a patchset yesterday that got partially pulled in, and part of that was a set of changes to the kernel. If you have a hard-coded SRCREV, this isn't a problem, for the n450 that's not the case. So how I figured out which ones to use was that I looked at the n450 machine branch and the meta branch and picked out the SRCREVs immediately preceding those changes. Tom It's interesting. I got the standard build to complete without any changes except the SRCREV statements. It booted on the Netbook just fine, but without networking. I went back to the bbappend file and added: SRC_URI += file://my_wifi.cfg Then created the my_wifi.cfg file to say: CONFIG_ATH9K_PCI=y after cleaning sstate and bitbake linux-yocto -c compile -f successfully, I couldn't seem to continue. That when I got the libperl error again like I did originally before I added the SRCREV. OK, I have no idea what happened there, but I can say that that if you're seeing that message, you're seeing commits that you shouldn't be according to the SRCREV i.e. that libperl message was itself added as part of the patchset: http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.2/commit/?h=standard/baseid=18ad076590b30347af31224304ee58986bd178cf Tom So you're really not going to like hearing this :-) I ran the default n450 build from the tarball BSPs same libperl error. I'm going to blow everything away including my download directory and start from the beginning of time. Actually, that would be expected - the n450 BSP is using whatever the latest SRCREVs from the kernel, regardless of whether the BSP itself is in a tarball or from a git repo or whatever - it's still pointing at the same kernel either way, and getting the same commits... Tom I went back and added the SRCREVs but that didn't fix it. Maybe the cleansstate doesn't clean enough up to allow me to continue. I'll add the srcrevs to the tarball version when I restart my testing. But this time, I've poured me a Blanton's bourbon, so it should go much better :-) Jim A Jim A Jim A Jim A Tom Jim A I got an error compiling the kernel. It didn't fail yesterday early, but now I get the same failure on Ubuntu 12.04 and Fedora 16. Jim A NOTE: make -C /build/n450-denzil/tmp/work/n450-poky-linux/linux-yocto-3.2.18+git1+49f931bc294d5b6be60502bbd448cff5aa766235_1+8b8cfaaab2b8d79ac56e8c9a85bad9ae7bca399c-r1/linux/tools/perf CC=i586-poky-linux-gcc -m32-march=core2 -msse3 -mtune=generic -mfpmath=sse --sysroot=/build/n450-denzil/tmp/sysroots/n450 LD=i586-poky-linux-ld --sysroot=/build/n450-denzil/tmp/sysroots/n450 prefix=/usr NO_NEWT=1 NO_DWARF=1 make: Entering directory `/build/n450-denzil/tmp/work/n450-poky-linux/linux-yocto-3.2.18+git1+49f931bc294d5b6be60502bbd448cff5aa766235_1+8b8cfaaab2b8d79ac56e8c9a85bad9ae7bca399c-r1/linux/tools/perf'
Re: [yocto] Documentation improvement
Cool! Sent from my iPhone On Jul 6, 2012, at 5:06 PM, Rifenbark, Scott M scott.m.rifenb...@intel.com wrote: Jim, I am looking at that section in the BSP Guide and it is actually out of date regarding the 1.2.10 section. In the section it lists the linux-yocto_3.0.bbappend file (which is probably lagging as it should be 3.2). Anyway, the listing uses KERNEL_FEATURES and I believe that KBRANCH is now used. I am going to work on this section and get it up to speed and then address the issue you originally brought up, which is getting the best description for config fragments inside the dev manual. ScottR From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of jfabernathy Sent: Friday, July 06, 2012 11:59 AM To: yocto@yoctoproject.org Subject: [yocto] Documentation improvement I was looking at the Yocto Development Manual (Latest), section 4.6.2. Creating Config Fragments. I was confused about the file statement and the naming of the directory to locate the fragment file until I found a similar discussion in the BSP Guide (lastest) section 1.2.10. Linux Kernel Configuration. The section there is much more understandable. I think we need to modify the development manual or have it point to the BSP manual. The text from there (below) I think is better. I still think it's confusing about the naming of the subdirectory where the myconfig goes. Maybe a complete example would be good. For example, suppose you had a set of configuration options in a file called myconfig. If you put that file inside a directory named linux-yocto and then added a SRC_URI statement such as the following to the append file, those configuration options will be picked up and applied when the kernel is built. SRC_URI += file://myconfig As mentioned earlier, you can group related configurations into multiple files and name them all in the SRC_URI statement as well. For example, you could group separate configurations specifically for Ethernet and graphics into their own files and add those by using a SRC_URI statement like the following in your append file: SRC_URI += file://myconfig \ file://eth.cfg \ file://gfx.cfg ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto Development Manual Appendix B question
Yes I did cleansstate. Sent from my iPhone On Jun 26, 2012, at 4:43 PM, Rifenbark, Scott M scott.m.rifenb...@intel.com wrote: Jim, Did you cleansstate before building and using menuconfig? There is a bug (2256) that prevents configurations made using menuconfig from sticking. Scott -Original Message- From: jfabernathy [mailto:jfaberna...@gmail.com] Sent: Tuesday, June 26, 2012 1:40 PM To: Rifenbark, Scott M Cc: yocto@yoctoproject.org Subject: Re: [yocto] Yocto Development Manual Appendix B question On 06/26/2012 04:21 PM, Rifenbark, Scott M wrote: Jim, Yes - I am still running the very last part of my test. If that is the change then I will make it to the 1.2 version of the manual and publish it to the website. Scott While I had this working I thought I'd complete the Appendix B example for the CONFIG_SMP change. I'm finding problems with the compile step after menuconfig is run to turn off SMP. I get a mismatch that I don't understand: Value requested for CONFIG_SMP not in final .config Requested value: CONFIG_SMP=y Actual value set: # CONFIG_SMP is not set There must be another setting of CONFIG_SMP that is conflicting with the .config file Jim A -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of jfabernathy Sent: Tuesday, June 26, 2012 12:50 PM To: yocto@yoctoproject.org Subject: Re: [yocto] Yocto Development Manual Appendix B question On 06/26/2012 02:07 PM, Rifenbark, Scott M wrote: When I attempted to rebuild minimal I hit the same error you did Jim regarding kern-tools-native. This would be expected as Bruce pointed out that problem is alive in denzil. I am going to set the poky-extras branch to 'denzil' and retry that part of the example. Scott -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Rifenbark, Scott M Sent: Tuesday, June 26, 2012 10:44 AM To: Bruce Ashfield Cc: yocto@yoctoproject.org Subject: Re: [yocto] Yocto Development Manual Appendix B question I am on task 1507 of 1606 of a minimal build (from the example). No issues so far. So now that Denzil has a branch in poky-extra, the only doc change is to add the checkout -b denzil statement for the poky-extra directory. Everything else is correct. Jim A -Original Message- From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com] Sent: Tuesday, June 26, 2012 10:42 AM To: Rifenbark, Scott M Cc: jfabernathy; yocto@yoctoproject.org Subject: Re: [yocto] Yocto Development Manual Appendix B question On 12-06-26 12:30 PM, Rifenbark, Scott M wrote: I am going to run through the B.1 example verbatim from the current version of the manual and see what happens. Fixing the license check was just a matter of me locking the SRCREV for the tools to a value that works for denzil. I just pushed a denzil branch to poky-extras that built and booted the yocto kernel for me. Cheers, Bruce Scott -Original Message- From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com] Sent: Tuesday, June 26, 2012 9:28 AM To: Rifenbark, Scott M Cc: jfabernathy; yocto@yoctoproject.org Subject: Re: [yocto] Yocto Development Manual Appendix B question On 12-06-26 12:26 PM, Rifenbark, Scott M wrote: This is a good point. In looking at the example it does not say what branch you should be dealing with for poky-extras. And I'm configuring a test right now and will create a denzil branch, once I see it works. Cheers, Bruce -Original Message- From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com] Sent: Tuesday, June 26, 2012 9:24 AM To: jfabernathy Cc: Rifenbark, Scott M; yocto@yoctoproject.org Subject: Re: [yocto] Yocto Development Manual Appendix B question On 12-06-26 12:11 PM, jfabernathy wrote: On 06/26/2012 12:04 PM, Bruce Ashfield wrote: On 12-06-26 12:00 PM, jfabernathy wrote: On 06/26/2012 10:56 AM, Rifenbark, Scott M wrote: Bruce, Should the example note this? Would it be best to specifically say to uncomment that SRC_URI line? Scott I think some text needs to be added. I uncommented the SRC_URI line and I still fail building the image. The failure is related to kernel tools: ERROR: kern-tools-native: md5 data is not matching for file://git/tools/kgit;beginline=5;endline=9;md5=e2bf4415f3d843f43d2e22b0d91a6fee ERROR: kern-tools-native: The new md5 checksum is d8d1d729a70cd5f52972f8884b80743d ERROR: kern-tools-native: Check if the license information has changed in ERROR: Licensing Error: LIC_FILES_CHKSUM does not match, please fix ERROR: Function failed: do_qa_configure This one is actually fixed on master, but poky-extras .. is just that 'extra', so this may still be alive in that repo. This wouldn't need to be documented, since it's a bug/issue, and not something that would persist. What release are
[yocto] use of build appliance
with the recent discussion on this mailing list on Build Appliance, I thought I'd see what the heck Build Appliance was all about. I quickly realized that I couldn't use it because I have a Macbook Pro as my portable PC and not a Windows PC. A Core i7 Ubuntu desktop is my main development tool. What I do is run VirtualBox on my Mac with a virtual machine for Ubuntu 10.4 LTS. I can run Hob, or any other part of poky-bitbake, etc. What am I missing by doing my solution vs. the Build appliance?? Jim A ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] basic recipe building - iperf
On Mon, Jun 18, 2012 at 10:40 PM, Khem Raj raj.k...@gmail.com wrote: On Monday, June 18, 2012, James Abernathy jfaberna...@gmail.com wrote: On Mon, Jun 18, 2012 at 5:29 PM, jfabernathy jfaberna...@gmail.com wrote: On 06/18/2012 05:21 PM, Marc Ferland wrote: jfabernathyjfaberna...@gmail.com writes: I needed to do some network performance testing on a Crownbay board and needed iperf in that environment. Since I had the core-image-sato-sdk image created, I just booted that and took the tarball from Sourceforge and built it per the readme file instructions: ./configure make make install After I completed my test, I thought about why not put that in my list of personal recipes. I found the previous version of iperf in the openembedded collection of benchmark recipes and just copied it over. It built and worked fine. There were a lot of items in the .bb that I didn't understand, so I thought for fun I'd just try to build a recipe for iperf 2.0.5 and see what happened. My recipe is simple, mostly taken from the openembedded 2.0.4 version had stripped down: Hi JF, I add the same problem you had with the man page stuff, try this patch. Marc thanks, that patch fixed it from a build point of view. now I'll build the image again and see what happens on the hardware. Jim A As expected the new image booted and ran the iperf 2.0.5 just fine. Are there any plans to add this tool to the Yocto project?? You could have just looked into meta-oe/recipes-benchmarks Jim A You must have missed the earlier discussion. I first got the iperf 2.0.4 from meta-oe, but wanted 2.0.5, so I just added it to my private collection of apps. Jim A ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] basic recipe building - iperf
On Tue, Jun 19, 2012 at 10:20 AM, Khem Raj raj.k...@gmail.com wrote: On Tue, Jun 19, 2012 at 2:54 AM, James Abernathy jfaberna...@gmail.com wrote: You must have missed the earlier discussion. I first got the iperf 2.0.4 from meta-oe, but wanted 2.0.5, so I just added it to my private collection of apps. you can post the update patch for meta-oe layer I can pass along what I did for iperf 2.0.5 in Yocto, but I have no idea what to do for OE. All the commands in their 2.0.4, which worked when copied to my meta-jfa directory, didn't mean much to me. I just started from scratch and created a new recipe based on autotools plus the patch that Marc passed along. Jim A ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] basic recipe building - iperf
On Mon, Jun 18, 2012 at 5:29 PM, jfabernathy jfaberna...@gmail.com wrote: On 06/18/2012 05:21 PM, Marc Ferland wrote: jfabernathyjfabernathy@gmail.**com jfaberna...@gmail.com writes: I needed to do some network performance testing on a Crownbay board and needed iperf in that environment. Since I had the core-image-sato-sdk image created, I just booted that and took the tarball from Sourceforge and built it per the readme file instructions: ./configure make make install After I completed my test, I thought about why not put that in my list of personal recipes. I found the previous version of iperf in the openembedded collection of benchmark recipes and just copied it over. It built and worked fine. There were a lot of items in the .bb that I didn't understand, so I thought for fun I'd just try to build a recipe for iperf 2.0.5 and see what happened. My recipe is simple, mostly taken from the openembedded 2.0.4 version had stripped down: Hi JF, I add the same problem you had with the man page stuff, try this patch. Marc thanks, that patch fixed it from a build point of view. now I'll build the image again and see what happens on the hardware. Jim A As expected the new image booted and ran the iperf 2.0.5 just fine. Are there any plans to add this tool to the Yocto project?? Jim A ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] runqemu qemux86
On Tue, May 22, 2012 at 10:45 AM, Autif Khan autif.ml...@gmail.com wrote: On Tue, May 22, 2012 at 7:43 AM, jfabernathy jfaberna...@gmail.com wrote: when testing an image using runqemu qemux86, can you get networking to work?? mine comes up disabled. I want to test an application that requires Internet access. Yes, I am able to get networking to work out of the box (bitbake core-image-sato, etc.) Internetworking does not work out of the box. This is accomplished over tun/tap devices - I do not know much about these virtual networking devices - they have never failed for me :-) The IP address of the emulated machine is 192.168.7.2 - The IP address of host machine is 192.168.7.1 You can not (out of the box) communicate with machines other than the host machine - so that would included internet etc. So, if you have an ssh server or a web-server running on the host machine - you can ssh to the host machine or browse a webpage using the browser. Alternatively, you can run a proxy server on the build machine and use it to get to the internet. You can run ifconfig to see if the network is configured properly on the emulated machine in the terminal. It should show 192.168.7.2 - if you do not see this - you do not have networking working. I can see the tap0 interface on my host at 192.168.7.1 by using ifconfig. I can also see the eth0 on the qemu machine at 192.168.7.2 However, my host has an ip of 10.0.1.54 with a AP gateway at 10.0.1.1. Somehow I need to connect the networks and I'm not sure exactly how to do that so that DNS servers get used and the traffic all flows. Jim A ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] runqemu qemux86
On Tue, May 22, 2012 at 1:04 PM, Scott Garman scott.a.gar...@intel.comwrote: On 05/22/2012 08:15 AM, James Abernathy wrote: On Tue, May 22, 2012 at 10:45 AM, Autif Khan autif.ml...@gmail.com mailto:autif.ml...@gmail.com** wrote: On Tue, May 22, 2012 at 7:43 AM, jfabernathy jfaberna...@gmail.com mailto:jfaberna...@gmail.com** wrote: when testing an image using runqemu qemux86, can you get networking to work?? mine comes up disabled. I want to test an application that requires Internet access. Yes, I am able to get networking to work out of the box (bitbake core-image-sato, etc.) Internetworking does not work out of the box. This is accomplished over tun/tap devices - I do not know much about these virtual networking devices - they have never failed for me :-) The IP address of the emulated machine is 192.168.7.2 - The IP address of host machine is 192.168.7.1 You can not (out of the box) communicate with machines other than the host machine - so that would included internet etc. So, if you have an ssh server or a web-server running on the host machine - you can ssh to the host machine or browse a webpage using the browser. Alternatively, you can run a proxy server on the build machine and use it to get to the internet. You can run ifconfig to see if the network is configured properly on the emulated machine in the terminal. It should show 192.168.7.2 - if you do not see this - you do not have networking working. I can see the tap0 interface on my host at 192.168.7.1 by using ifconfig. I can also see the eth0 on the qemu machine at 192.168.7.2 However, my host has an ip of 10.0.1.54 with a AP gateway at 10.0.1.1. Somehow I need to connect the networks and I'm not sure exactly how to do that so that DNS servers get used and the traffic all flows. Jim A There is some sort of routing or IP forwarding bug in the sato images that is due to be fixed soon. One thing I've found is you can actually get out to the internet for about 30 seconds or so immediately after the image boots. My suspicion is that some conman script is killing the route after boot. core-image-minimal works consistently, and since minimal doesn't use conman, I'm guessing that is the culprit. https://bugzilla.yoctoproject.**org/show_bug.cgi?id=2329https://bugzilla.yoctoproject.org/show_bug.cgi?id=2329 Scott So if I read this right, I don't need any route or bridge commands to make this work. If the bug gets fixed runqemu qemux86 should setup the environment correctly so the web-webkit should get out to the internet via the host machine connection? JIm A -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center __**_ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.**org/listinfo/yoctohttps://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] build error on core-image-sato-sdk
On Mon, Apr 9, 2012 at 6:15 PM, Darren Hart dvh...@linux.intel.com wrote: On 04/09/2012 01:33 PM, jfabernathy wrote: at the end of the build of core-image-sato-sdk I got the following error. I'm using the edison branch with the latest changes and also building the meta-cedartrail. I had previously built core-image-sato successfully with this setup. Any ideas? ERROR: Function 'build_boot_bin' failed (see /build/cdv-edison/tmp/work/cedartrail-poky-linux/core-image-sato-sdk-1.0-r0/temp/log.do_bootimg.25810 for further information) ERROR: Logfile of failure stored in: /build/cdv-edison/tmp/work/cedartrail-poky-linux/core-image-sato-sdk-1.0-r0/temp/log.do_bootimg.25810 Log data follows: | mkdosfs: seek failed Interesting. Can you provide the OE Build Configuration blob that prints at the start of the build - I'm mostly interested in your commit IDs for. Also, please include the HEAD of your poky edison tree. Is there a way to retreive the OE-Build Configuration blob after it rolls off the screen? Or should I just rerun and capture it then? Thanks, -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to change the startup application
Just an observation. the FAQ link that Autif did looks like a How Do I, which is the section in the Wiki right after the FAQ. Does that matter to anyone? Jim A On Tue, Apr 3, 2012 at 5:58 PM, Liu, Song song@intel.com wrote: Thanks, Autif. I guess I missed the last word for the link, but it's strange that the page was there. Anyway, I deleted mine. Song -Original Message- From: Autif Khan [mailto:autif.ml...@gmail.com] Sent: Tuesday, April 03, 2012 2:23 PM To: Liu, Song Cc: yocto@yoctoproject.org Subject: Re: [yocto] How to change the startup application Hi Song, I thought that I already updated the wiki. It seems like you created an extra page. _scripts is missing from the link. It should be there. Source: https://wiki.yoctoproject.org/wiki/Category:FAQ What I added days ago: https://wiki.yoctoproject.org/wiki/FAQ:How_do_I_change_and_add_startup_scripts What you added (which I think should be deleted): https://wiki.yoctoproject.org/wiki/FAQ:How_do_I_change_and_add_startup Agree? On Tue, Apr 3, 2012 at 4:34 PM, Liu, Song song@intel.com wrote: Hi Autif, thanks a lot for providing the answer here. Since no one is showing any objections here, I updated the wiki page with your answer ( https://wiki.yoctoproject.org/wiki/FAQ:How_do_I_change_and_add_startup). Please let me know if there is any suggestions or concerns. Song -Original Message- From: Autif Khan [mailto:autif.ml...@gmail.com] Sent: Thursday, March 29, 2012 4:56 PM To: Liu, Song Cc: yocto@yoctoproject.org Subject: Re: [yocto] How to change the startup application I got a question about how to change the startup application with Yocto for images generated with Yocto. And I googled it and landed on this page: https://wiki.yoctoproject.org/wiki/FAQ:How_do_I_change_and_add_startu p _scripts. Pretty good, someone was thinking about the same thing. But this page turns out to be empty. It seems that we need to get better than this. I'm wondering if someone could update this wiki page or if the information is somewhere else... I do not know of if the information is elsewhere - I had to find this information for my project Here is my stab at it (already updated the wiki): Q: How do I change and add startup scripts? A: Edit meta/recipes-sato/matchbox-sato/matchbox-session-sato/session. Of course, if you have your own meta-layer, append the matchbox-session-sato_0.1.bb recipe. Disable 'matchbox-desktop' and 'matchbox-panel', however, do not disable 'exec matchbox-window-manager ...' Don't forget to run your app as a background process For example, the following code will start the fifteen game: #matchbox-desktop # Lines containing feature-[foo] are removed at build time if the machine # doesn't have the feature foo. #START_APPLETS=showdesktop,windowselector #END_APPLETS=clock,battery,systray,startup-notify,notify #END_APPLETS=openmoko-panel-gsm,$END_APPLETS # feature-phone #matchbox-panel --titlebar --start-applets $START_APPLETS --end-applets $END_APPLETS /usr/games/fifteen exec matchbox-window-manager -theme Sato -use_desktop_mode decorated -use_cursor $SHOWCURSOR $@ ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to find Log
On Feb 14, 2012, at 4:04 AM, Lu, Lianhao wrote:
James W. wrote on 2012-02-14:
How to locate Log file while a error occur.
It's under the directory ${WORKDIR}/temp/. Actually when an error occurs, you
can find the specific log file in the output, something like.
ERROR: Logfile of failure stored in:
/intel/poky/builds/toolchain/tmp/work-shared/gcc-4.6.2+svnr181430-r22/temp/log.do_patch.15156
Best Regards,
Lianhao
I have a similar questions. If the error occurs and the console log information
scrolls too far to get back to, how do I find the error log file then? I know
what directory all the logs will be, but is there an easy way to find the one
with the error??
Jim A
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Building your own UI
This may be a dumb question, but I'll ask anyway. Suppose you have a project where you need a very custom user interface. Not just a series of applications that appear on a desktop like you see in sato, or Gnome, or KDE. Basically your application becomes the UI. I can see 2 approaches to this: 1. Start with core-image-minimal and add the packages you need to support GFX, X11, and your application plus dependencies. 2. Take core-image-sato and change the applications to be your subtasks , and the look-and-feel of the desktop. What are the considerations of both approaches? Is one better, or easier than the other? How would you do this in Yocto? Where do you look for information you need to accomplish this? JIm A ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Unable to fetch file://lib for package emgd in yoctyo 1.2 (aka M2)
On Tue, Feb 7, 2012 at 10:49 AM, Tom Zanussi tom.zanu...@intel.com wrote:
On Tue, 2012-02-07 at 10:12 -0500, autif khan wrote:
I am bitbaking core image sato for machine corwnbay (with the emgd
driver) and the emgd-driver-bin recipe seems to fail.
Here is the error. I searched the archives, but could not find anything.
Please advise.
It looks like the problem may be forgetting to carry out the steps in
section 'II. Special notes for building the meta-crownbay BSP layer' in
the README.
Note that this is no longer necessary if you use master - the
emgd-driver-bin recipe has been upgraded to do the steps there
automatically, which is now possible because it uses the LICENSE_FLAGS,
but which does mean you need to set the LICENSE_FLAGS_WHITELIST as
mentioned in the new README for crownbay in master.
I can confirm that using the master branch is the way to go to make this
easy.
I documented my test of it at :
https://wiki.yoctoproject.org/wiki/How_do_I#Q:_How_do_I_setup_Intel.C2.AE_Atom.E2.84.A2_Processor_E6xx_based_system_for_media_playback.3F
Jim
Tom
Here is the output for bitbake -b
/data/autif/yocto/poky/meta-intel/common/recipes-graphics/xorg-xserver/
emgd-driver-bin_1.8.bb
NOTE: Running task 1 of 12 (ID: 4,
/data/autif/yocto/poky/meta-intel/common/recipes-graphics/xorg-xserver/
emgd-driver-bin_1.8.bb,
do_fetch)
NOTE: package emgd-driver-bin-1.8-r8: task do_fetch: Started
ERROR: Function 'Fetcher failure for URL: 'file://lib'. Unable to
fetch URL file://lib from any source.' failed
ERROR: Logfile of failure stored in:
/ssd/autif/M2/crb/tmp/work/core2-poky-linux/emgd-driver-bin-1.8-r8/temp/log.do_fetch.31621
Log data follows:
| DEBUG: Trying PREMIRRORS
| DEBUG: For url ['file', '', 'lib', '', '', {}] comparing ['bzr',
'.*', '/.*', '', '', {}] to ['http', 'autobuilder.yoctoproject.org',
'/sources/', '', '', {}]
| DEBUG: For url ['file', '', 'lib', '', '', {}] comparing ['cvs',
'.*', '/.*', '', '', {}] to ['http', 'autobuilder.yoctoproject.org',
'/sources/', '', '', {}]
| DEBUG: For url ['file', '', 'lib', '', '', {}] comparing ['git',
'.*', '/.*', '', '', {}] to ['http', 'autobuilder.yoctoproject.org',
'/sources/', '', '', {}]
| DEBUG: For url ['file', '', 'lib', '', '', {}] comparing ['hg',
'.*', '/.*', '', '', {}] to ['http', 'autobuilder.yoctoproject.org',
'/sources/', '', '', {}]
| DEBUG: For url ['file', '', 'lib', '', '', {}] comparing ['osc',
'.*', '/.*', '', '', {}] to ['http', 'autobuilder.yoctoproject.org',
'/sources/', '', '', {}]
| DEBUG: For url ['file', '', 'lib', '', '', {}] comparing ['p4',
'.*', '/.*', '', '', {}] to ['http', 'autobuilder.yoctoproject.org',
'/sources/', '', '', {}]
| DEBUG: For url ['file', '', 'lib', '', '', {}] comparing ['svk',
'.*', '/.*', '', '', {}] to ['http', 'autobuilder.yoctoproject.org',
'/sources/', '', '', {}]
| DEBUG: For url ['file', '', 'lib', '', '', {}] comparing ['svn',
'.*', '/.*', '', '', {}] to ['http', 'autobuilder.yoctoproject.org',
'/sources/', '', '', {}]
| DEBUG: Trying Upstream
| ERROR: Function 'Fetcher failure for URL: 'file://lib'. Unable to
fetch URL file://lib from any source.' failed
NOTE: package emgd-driver-bin-1.8-r8: task do_fetch: Failed
ERROR: Task 4
(/data/autif/yocto/poky/meta-intel/common/recipes-graphics/xorg-xserver/
emgd-driver-bin_1.8.bb,
do_fetch) failed with exit code '1'
ERROR:
'/data/autif/yocto/poky/meta-intel/common/recipes-graphics/xorg-xserver/
emgd-driver-bin_1.8.bb'
failed
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] HOW DO I - new one added for EMGD and Crownbay
On Feb 5, 2012, at 3:19 PM, Darren Hart wrote: On 02/05/2012 11:44 AM, James Abernathy wrote: On Feb 5, 2012, at 2:19 PM, Darren Hart wrote: On 02/04/2012 07:21 AM, jfabernathy wrote: I just added and EMGD example to the How Do I in the wiki. Jim, really appreciate your work here. For those of us not following quite as closely, please provide links to the pages you update so we don't have to go hunting for them. It's the How Do I link on the wiki page: https://wiki.yoctoproject.org/wiki/How_do_I I see. This Question heading seems a bit inconsistent with what you are actually doing. Step 1 of getting EMGD on Crownbay is adding alsa to MACHINE_FEATURES for a BSP called meta-mymachine? This appears to be just trying to get commercial codecs working with accelerated graphics. The reason I raise this, is that while it's good to have these sorts of Tactical guides, if we aren't careful they can dilute the documentation space and end up confusing users more than they help. The README for crownbay covers what is necessary to enable EMGD accelerated graphics. Please consider renaming the title to someting more consistent with what you're trying accomplish. Look, I'm not a documentation expert or understand what the project team is trying to accomplish with their documentation or wiki. A user on the mailing list asked me to summarize what I did to get all the issues resolve related to media acceleration and decoder. What I put in the How Do I was a summation of the questions and answers that were in the email thread. I can just as easily email that user the summary, if it's not appropriate for the wiki. Please feel free to edit what I put there or remove it. Jim A -- Darren I'm interested to see what more was needed for EMGD and Crownbay than is already in the BSP README. In my opinion, we need to think about breaking this one big edit up into individual How Do I's. It would simplify editing and make getting to the individual How Do I's much easier and quicker. I don't know how to do that, but I think it needs doing. Jim A ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] HOW DO I - new one added for EMGD and Crownbay
On Mon, Feb 6, 2012 at 12:32 PM, Darren Hart dvh...@linux.intel.com wrote: On 02/06/2012 09:13 AM, jfabernathy wrote: On 02/06/2012 10:59 AM, Darren Hart wrote: On 02/06/2012 05:00 AM, James Abernathy wrote: On Feb 5, 2012, at 3:19 PM, Darren Hart wrote: On 02/05/2012 11:44 AM, James Abernathy wrote: On Feb 5, 2012, at 2:19 PM, Darren Hart wrote: On 02/04/2012 07:21 AM, jfabernathy wrote: I just added and EMGD example to the How Do I in the wiki. Jim, really appreciate your work here. For those of us not following quite as closely, please provide links to the pages you update so we don't have to go hunting for them. It's the How Do I link on the wiki page: https://wiki.yoctoproject.org/wiki/How_do_I I see. This Question heading seems a bit inconsistent with what you are actually doing. Step 1 of getting EMGD on Crownbay is adding alsa to MACHINE_FEATURES for a BSP called meta-mymachine? This appears to be just trying to get commercial codecs working with accelerated graphics. The reason I raise this, is that while it's good to have these sorts of Tactical guides, if we aren't careful they can dilute the documentation space and end up confusing users more than they help. The README for crownbay covers what is necessary to enable EMGD accelerated graphics. Please consider renaming the title to someting more consistent with what you're trying accomplish. Look, I'm not a documentation expert or understand what the project team is trying to accomplish with their documentation or wiki. A user on the mailing list asked me to summarize what I did to get all the issues resolve related to media acceleration and decoder. What I put in the How Do I was a summation of the questions and answers that were in the email thread. I can just as easily email that user the summary, if it's not appropriate for the wiki. Please don't take the above as a criticism of the How Do I concept, as I said at first, I appreciate you doing it - I understand it takes some considerable additional time to publish it. The goal is clearly to make things easier for others when they attempt what you're doing. I saw something in there that might not fit the goal and raised it as a point of improvement, that's all. Please feel free to edit what I put there or remove it. I've CC'd Scott R. to review and see if he might care to adjust things a bit. I certainly don't want to remove it :) -- Darren What I feel is missing from the standard documentation for EMGD v1.10 integration into the Crownbay BSP is all the other stuff you need. The README file in the meta-crownbay includes exactly what is needed to integrate the EMGD v 1.10 driver. But generally, after that users will have the next level of questions about how do I get video and audio media files to play correctly, or test 3D . This is technically not a driver integration question, but can be anticipated because you wouldn't care about integrating the EMGD driver unless you had media and 3D needs in your application/. Fair enough. As those sorts of things are not BSP specific, I certainly think the How-Do-I pages you're creating are a good way to address that gap. At some point, this sort of tactical documentation might make sense to be rolled up into some more official type of docs. For now, the How-Do-I Question title could be improved were to read How do I enable audio and commerial audio and video codecs? or How do I get the Sato media player to play mp3s? If we could make the How Do I section of the wiki broken into sub-categories so each How Do I is a separate item to be edited. That would make it easier to find, create, and edit these items. Also once an item found it's way into official documentation, it could be removed or edited to point to the official doc. Jim A -- Darren Just my thoughts. Jim A Jim A -- Darren I'm interested to see what more was needed for EMGD and Crownbay than is already in the BSP README. In my opinion, we need to think about breaking this one big edit up into individual How Do I's. It would simplify editing and make getting to the individual How Do I's much easier and quicker. I don't know how to do that, but I think it needs doing. Jim A ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] HOW DO I - new one added for EMGD and Crownbay
On Feb 5, 2012, at 2:19 PM, Darren Hart wrote: On 02/04/2012 07:21 AM, jfabernathy wrote: I just added and EMGD example to the How Do I in the wiki. Jim, really appreciate your work here. For those of us not following quite as closely, please provide links to the pages you update so we don't have to go hunting for them. It's the How Do I link on the wiki page: https://wiki.yoctoproject.org/wiki/How_do_I I'm interested to see what more was needed for EMGD and Crownbay than is already in the BSP README. In my opinion, we need to think about breaking this one big edit up into individual How Do I's. It would simplify editing and make getting to the individual How Do I's much easier and quicker. I don't know how to do that, but I think it needs doing. Jim A ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Gaku music player
I tried all the different mixer options on the Crownbay. It's just not very loud. I'll try an amplifier, but with earphones, it almost not loud enough to hear. I don't remember other Linux's having this issue. Could there be something else software wise? The good news is the built-in GUI Music and Video players work with the H.264 files I've tested as well as the command line stuff. Also got the glxgears works as well. Jim A On Thu, Feb 2, 2012 at 6:54 PM, Saxena, Rahul rahul.sax...@intel.comwrote: You can also use the graphical alsamixer Just Include alsa in MACHINE_FEATURES in meta-cedartrail/conf/cedartrail.conf Rahul -Original Message- From: yocto-boun...@yoctoproject.org [mailto: yocto-boun...@yoctoproject.org] On Behalf Of Tom Zanussi Sent: Thursday, February 02, 2012 3:42 PM To: James Abernathy Cc: yocto@yoctoproject.org Subject: Re: [yocto] Gaku music player On Thu, 2012-02-02 at 17:42 -0500, James Abernathy wrote: On Wed, Feb 1, 2012 at 8:20 PM, Tom Zanussi tom.zanu...@intel.com wrote: On Wed, 2012-02-01 at 19:57 -0500, jfabernathy wrote: On 02/01/2012 07:02 PM, Tom Zanussi wrote: On Wed, 2012-02-01 at 17:39 -0500, jfabernathy wrote: On 02/01/2012 04:47 PM, Tom Zanussi wrote: On Wed, 2012-02-01 at 13:44 -0800, Darren Hart wrote: On 02/01/2012 01:36 PM, Saxena, Rahul wrote: Hi Darren, Thanks for the clarification. I am building on Edison. I found that ogg music files play OK on my gaku player. I think that should be good enough, but just for my information purposes can you help me understand how does one accept the commercial iirc license ? This has changed relatively recently, and I'm not finding the details in the current docs. For example, the gst-fluendo-mp3 recipe includes: LICENSE_FLAGS = commercial Taking a look at the git logs with LICENSE_FLAGS in them, in order to allow for building of such recipes, you must include commercial in the LICENSE_FLAGS_WHITELIST variable. I would attempt this with something like the following in my local.conf: LICENSE_FLAGS_WHITELIST += commercial Tom, can you confirm I've got this right? Yeah, that's right. Tom I'm interested in this subject also. If I use hob to look at a nice display of packages, I see that their are a lot of gst-fluendo-* pckages with MPLv1.1 Licenses. However, I don't see gst-fluendo-mp3 specifically. 1. Is that package not a part of Yocto and a recipe has to be written to get it from somewhere? It is a part of yocto, it probably doesn't show up in HOB because of the restricted license (nothing has changed there, I guess that also would have been the case before with COMMERCIAL_LICENSE). Basically, the documentation hasn't caught up with the change yet (actually it (COMMERCIAL_LICENSE) was never documented, we need to change that in any case). The current 'documentation' for this, which I'll work with Scott on adapting to the actual documentation, is in the text of this poky commit: b68ea543603c35f4e3519d358e0d1e1e24bd5851 and the set of packages that were changed from COMMERCIAL_LICENSE to LICENSE_FLAGS is here: 7b81ef8d95d82c55e3650981d301cd493832 Tom Okay, I found gst-fluendo-mp3 in the meta-recipes-multimedia. So is including it the same as other packages you want in the image, putting the following statements in the local.conf: LICENSE_FLAGS_WHITELIST += commercial POKY_EXTRA_INSTALL += gst-fluendo-mp3 I would think that specifying the media player in the image would bring in the dependent CODECs if the licenses were right, but what do I know. Yes, that LICENSE_FLAGS_WHITELIST line would allow gst-fluendo-mp3 in, and that in turn bring in its dependencies. Tom FYI, I got this working fine. I could create a playlist with .ogg, mp3, m4a file types and all played. I could not adjust the volume. Is there a mixer/volume app for Sato? Something like: # amixer set Master on # amixer set Master 75 has worked for me
Re: [yocto] Gaku music player
On Fri, Feb 3, 2012 at 11:02 AM, James Abernathy jfaberna...@gmail.comwrote: I tried all the different mixer options on the Crownbay. It's just not very loud. I'll try an amplifier, but with earphones, it almost not loud enough to hear. I don't remember other Linux's having this issue. Could there be something else software wise? The good news is the built-in GUI Music and Video players work with the H.264 files I've tested as well as the command line stuff. Also got the glxgears works as well. Jim A To close this one out. The Crownbay seems to have a line level out only and not a port that supports headphones and line level. Once I put minimal Line in level amplfication, the audio works as expected. Thanks for the help. It's good to see nice integration in Yocto of video and music players that actually plays the the H.264 and MP3 files. Jim A ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] needed site is down???
On Thu, Feb 2, 2012 at 2:11 PM, Joshua Lock j...@linux.intel.com wrote: On 02/02/12 09:44, jfabernathy wrote: On 02/02/2012 12:36 PM, jfabernathy wrote: On 02/02/2012 12:06 PM, Mark Hatle wrote: On 2/2/12 10:08 AM, jfabernathy wrote: On 02/01/2012 10:59 PM, jfabernathy wrote: Am I the only one seeing this dead link? I'm building from master and can't get to this link that draws the error: http://cgit.freedesktop.org/**libva/snapshot/libva-1.0.12.**tar.bz2http://cgit.freedesktop.org/libva/snapshot/libva-1.0.12.tar.bz2 This is supposed to be a transient error but so far as I can see the fd.o cgit is still down. Just noticed that what's on the Yocto mirror is libva_0.31.0-1+sds9.1ubuntu1.**tar.gz ), but the recipe is calling for a newer version, libva-1.0.12.tar.bz2 I don't see libva-1.0.12 anywhere in poky or meta-yocto, the mirror is only updated once the autobuilder has seen the recipe and downloaded the object to mirror. After a quick google I can't find a libva newer than 0.32.0+1sds2 - where did you get your libva recipe from? If I checkout master on poky and meta-intel and run the normal crownbay (not the no-EMGD version) I get this error. Also on 1.2_M2 tag. JIm A Cheers, Joshua -- Joshua Lock Yocto Project Johannes factotum Intel Open Source Technology Centre __**_ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.**org/listinfo/yoctohttps://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Gaku music player
On Wed, Feb 1, 2012 at 8:20 PM, Tom Zanussi tom.zanu...@intel.com wrote: On Wed, 2012-02-01 at 19:57 -0500, jfabernathy wrote: On 02/01/2012 07:02 PM, Tom Zanussi wrote: On Wed, 2012-02-01 at 17:39 -0500, jfabernathy wrote: On 02/01/2012 04:47 PM, Tom Zanussi wrote: On Wed, 2012-02-01 at 13:44 -0800, Darren Hart wrote: On 02/01/2012 01:36 PM, Saxena, Rahul wrote: Hi Darren, Thanks for the clarification. I am building on Edison. I found that ogg music files play OK on my gaku player. I think that should be good enough, but just for my information purposes can you help me understand how does one accept the commercial iirc license ? This has changed relatively recently, and I'm not finding the details in the current docs. For example, the gst-fluendo-mp3 recipe includes: LICENSE_FLAGS = commercial Taking a look at the git logs with LICENSE_FLAGS in them, in order to allow for building of such recipes, you must include commercial in the LICENSE_FLAGS_WHITELIST variable. I would attempt this with something like the following in my local.conf: LICENSE_FLAGS_WHITELIST += commercial Tom, can you confirm I've got this right? Yeah, that's right. Tom I'm interested in this subject also. If I use hob to look at a nice display of packages, I see that their are a lot of gst-fluendo-* pckages with MPLv1.1 Licenses. However, I don't see gst-fluendo-mp3 specifically. 1. Is that package not a part of Yocto and a recipe has to be written to get it from somewhere? It is a part of yocto, it probably doesn't show up in HOB because of the restricted license (nothing has changed there, I guess that also would have been the case before with COMMERCIAL_LICENSE). Basically, the documentation hasn't caught up with the change yet (actually it (COMMERCIAL_LICENSE) was never documented, we need to change that in any case). The current 'documentation' for this, which I'll work with Scott on adapting to the actual documentation, is in the text of this poky commit: b68ea543603c35f4e3519d358e0d1e1e24bd5851 and the set of packages that were changed from COMMERCIAL_LICENSE to LICENSE_FLAGS is here: 7b81ef8d95d82c55e3650981d301cd493832 Tom Okay, I found gst-fluendo-mp3 in the meta-recipes-multimedia. So is including it the same as other packages you want in the image, putting the following statements in the local.conf: LICENSE_FLAGS_WHITELIST += commercial POKY_EXTRA_INSTALL += gst-fluendo-mp3 I would think that specifying the media player in the image would bring in the dependent CODECs if the licenses were right, but what do I know. Yes, that LICENSE_FLAGS_WHITELIST line would allow gst-fluendo-mp3 in, and that in turn bring in its dependencies. Tom FYI, I got this working fine. I could create a playlist with .ogg, mp3, m4a file types and all played. I could not adjust the volume. Is there a mixer/volume app for Sato? Jim A Jim A 1. I know I can get the fluendo MP3 for Ubuntu with a click-through license for personal use. Scott, once Tom confirms, this is a mechanism we need to get documented in the reference manual. -- Darren Thanks Rahul -Original Message- From: Darren Hart [mailto:dvh...@linux.intel.com] Sent: Wednesday, February 01, 2012 10:54 AM To: Saxena, Rahul Cc: yocto@yoctoproject.org Subject: Re: [yocto] Gaku music player On 02/01/2012 09:57 AM, Saxena, Rahul wrote: Hello, What type of music files is the Gaku music player on Sato desk top supposed to play ? For me it did not work with mp3 files..however it is playing the soundtrack from a .ogg video file It depends on which licenses you allow (the gstreamer mp3 plugin requires acceptance of the commercial license iirc). Are you building on edison or master? -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Understanding the git commits for Yocto and meta
While I've read enough to think I understand git, I get confused when it's applied to real situations like Yocto. If I look at the Yocto Development Manual, Appendix A, A.5.2.4 Changing Recipes-kernel, It brings up some questions. 1. The way I see it, when you guys commit something to the linux yocto master or meta there is a commit string associated with that commit. Not to any certain branch of the git repository, right? 2. So if I'm building an image for atom-pc using Edison branch, the first SRCREV I'm interested in is yocto/standard/common-pc/atom-pc branch. But the commits I see at http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.0/commit/?h=yocto/standard/common-pc/atom-pc are commits not associated with Edison, but Master, right? 3. How do I find the commit string for a particular branch, like Edison, for something like yocto/standard/common-pc/atom-pc? 4. To me, branches are things like Edison, Bernard, etc. But on the page: http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.0/refs/heads?h=yocto/standard/common-pc/atom-pc yocto/standard/common-pc/atom-pc, master, and meta are all listed as branches. What is the difference?? 5. The second SRCREV seems to be associated with meta. How does that relate to my whole confusion on branches. 6. To me, if you are working with Edison and a particular BSP, then these 2 commit strings should be constant forever, right? ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] normal user for Intel BSPs?
On Jan 25, 2012, at 5:42 PM, Scott Garman wrote: On 01/25/2012 02:18 PM, Darren Hart wrote: On 01/25/2012 09:36 AM, jfabernathy wrote: I've noticed that the meta-intel BSP come up with the default terminal, serial console user, etc. as root. What would it take to make my own BSP that was exactly the same, but the default was a not admin user, but you could su or sudo to root? I'm adding Scott G. who I believe has been working on the useradd scripts and such (to sanity check the following). I believe you should be able to setup new users by extending an image recipe with a new task to make the necessary useradd/mod etc calls on the rootfs prior to packaging it up. Scott, can you offer more detail on how that is done? Hi Jim, Darren: The useradd mechanism is for supporting custom users and groups in recipes. It sounds like what Jim may find more expedient would be to define a recipe which includes a first-boot script which creates the additional users/groups and then sets up custom ownership on the terminal, serial console user, etc. Otherwise you'd have to do this in several recipes. Using the first-boot script approach is documented here: http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#usingpoky-extend-addpkg-postinstalls Whereas using the useradd bitbake class is documented in an example recipe in meta-skeleton/recipes-skeleton/useradd/useradd-example.bb. There is also a slide deck you may find useful here: http://wiki.yoctoproject.org/wiki/images/e/e6/Custom_Users_Groups_in_Yocto1.1.pdf I'll also mention that I'm still shaking out bugs in the useradd mechanism. We have some race conditions that are complicating matters when building from sstate. So if you're using one of our stable releases, the first-boot script approach is probably your safest bet. Scott Thanks for these suggestions. I'll look them over and figure out what I want to do. Jim A -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] tar ball vs. git development questions
On Jan 23, 2012, at 9:01 AM, Bruce Ashfield wrote:
On 12-01-23 08:10 AM, Gary Thomas wrote:
On 2012-01-23 05:51, jfabernathy wrote:
On 01/22/2012 08:12 PM, Gary Thomas wrote:
On 2012-01-22 13:19, James Abernathy wrote:
I have used both git and the tarball methods of bitbaking projects,
all of them derivatives of the examples in the Yocto documentation.
I was having issues using the local clone of
the Yocto kernel git repository this weekend. I had successfully
done that before, but I was rebuilding the PC workstation, and
getting everything setup and tested some of the
meta-intel BSPs to make sure I had everything right. Cloning the
linux-yocto-3.0 repository was successful, but the bakes against it
failed. I made sure I had poky-extras setup
right, but I still had problems. To isolate the problem, I changed
to building with the tarballs and everything worked fine.
So that got me thinking what are the differences between the 2 methods:
* I assume that if I use the tarball method, bitbake, using the
recipes, pulls down files from the online repositories and puts
those files into the centralized local download
directory ($DL_DIR), allowing reuse instead of re-downloading each
time. The content downloaded for linux-yocto-3.0 is exactly what
would be pulled from the local repository if
I used a local clone of the git repository for linux-yocto-3.0.
* If my assumption above is correct, if I'm not modifying the source
code of the kernel (only changing config parameters), then once
you've run at least one build with the
tarball method, the $DL_DIR directory contains all the files you'll
need to build any image with linux-yocto-3.0. So there is no need to
have a local clone of the kernel
repository for speeding up development. Am I right?
* If I have a successful creation of a bare clone of
linux-yocto-3.0.git, how could builds of Edison packages be failing?
That makes me concerned about using git and successfully
repeating builds of stable branches like Edison.
If you set BB_GENERATE_MIRROR_TARBALLS = 1 (e.g. in local.conf)
then you'll get tarballs which hold the git repositories after
download. You can then reuse these (by sharing the DL_DIR or
using a local mirror). Does that help with the issue you're seeing?
I'm not sure it does. I don't want poky to do more work. I have my
download directory, $DL_DIR, outside my build directory so I can keep
it run to run, as mentioned in the comments
in local.conf. I was trying to understand 2 basic questions:
1. what could be causing build failures using a freshly created bare
clone yesterday vs. using the poky-edison-6.0 tarball. It would be
scary if you could clone the linux-yocto-3.0
successfully one day and have it be used in a build successfully, but
clone it another day and it not work. I figured that bitbake/poky
pulled the same information into DL_DIR
regardless of whether you pulled from the bare clone locally or
straight from the on-line repository.
What kind of errors? Some details might help understand what the problem
is.
2. I was trying to look at items to speed up build runs. I thought
that if the downloads in DL_DIR were reused if they existed, it would
speed up a run. It seems to. So the
question is, after the first build, the files I need for
linux-yocto-3.0 are in DL_DIR regardless of whether they came from the
online repository or the local bare clone. right?
I think so, but I'm not 100% sure.
From my experience, this is true. Regardless of the SRCI_URI, the
downloads directory contains everything that poky/bitbake need to
do builds after the initial fetch has been performed. And that's
where subsequent updates are pullled.
Cheers,
Bruce
I'm going to retest all this and try some of these tricks when I have some
time. If I get any more errors with the local repository, I'll post them.
Thanks, Jim A
The way I have my system set up, I never download anything more
than once :-) I have a shared source repository which I point to
using MIRRORS and then all my builds are relative to that. If there
is new code, it gets downloaded and saved (as a tarball) in my sources
repository to be used by subsequent builds. To do this, I just have
these lines in distro.conf
# Provide pre-staged sources
SOURCE_MIRROR_URL ?= file://${COREBASE}/sources/
INHERIT += own-mirrors
BB_GENERATE_MIRROR_TARBALLS = 1
I don't define DL_DIR in local.conf so files only come from my mirror.
This process is so successful that I almost always run with
BB_NO_NETWORK=1
which causes the fetcher to die if it can't find the file locally. If I
find
that I do need to download something new, I disable this and let the
fetcher
download it. I'll then have a saved tarball (either downloaded directly or
synthesized) in build_dir/downloads that I can push to my mirror.
___
yocto mailing list
yocto@yoctoproject.org
https
[yocto] core-image-sato-directdisk
The README.hardware file in the poky directory talks about creating images on 2 types of disk for the Atom based PCs like the n450. The one I've successfully tested is the core-image-sato on a USB key. I have no luck with the directdisk method because the image recipe doesn't exist for core-image-minimal-directdisk or core-image-sato-directdisk. Is there a way to put Yocto on the hard drive on a Atom PC? Jim A ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] build failure on ubuntu 64bits development system
I just built a new development pc and installed Ubuntu 11.10 x64. I wonder if there are any new requirements to building Yocto in that environment? I got an error right off, but then it complete the first 63 task and stopped successfully. error below: jim@ubuntu:~/poky/build-cdv$ bitbake core-image-sato Pseudo is not present but is required, building this first before the main build Parsing recipes: 100% |#| Time: 00:00:25 Parsing of 797 .bb files complete (0 cached, 797 parsed). 1037 targets, 22 skipped, 0 masked, 0 errors. ERROR: Execution of event handler 'run_buildstats' failed Traceback (most recent call last): File run_buildstats(e), line 18, in run_buildstats(e=bb.event.BuildStarted object at 0x4c338d0) File buildstats.bbclass, line 21, in set_device(e=bb.event.BuildStarted object at 0x4c338d0) UnboundLocalError: local variable 'rdev' referenced before assignment Any ideas? JIm A ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] build failure on ubuntu 64bits development system
On Wed, Jan 18, 2012 at 7:55 AM, James Abernathy jfaberna...@gmail.comwrote: I just built a new development pc and installed Ubuntu 11.10 x64. I wonder if there are any new requirements to building Yocto in that environment? I got an error right off, but then it complete the first 63 task and stopped successfully. error below: jim@ubuntu:~/poky/build-cdv$ bitbake core-image-sato Pseudo is not present but is required, building this first before the main build Parsing recipes: 100% |#| Time: 00:00:25 Parsing of 797 .bb files complete (0 cached, 797 parsed). 1037 targets, 22 skipped, 0 masked, 0 errors. ERROR: Execution of event handler 'run_buildstats' failed Traceback (most recent call last): File run_buildstats(e), line 18, in run_buildstats(e=bb.event.BuildStarted object at 0x4c338d0) File buildstats.bbclass, line 21, in set_device(e=bb.event.BuildStarted object at 0x4c338d0) UnboundLocalError: local variable 'rdev' referenced before assignment Any ideas? JIm A I went back and tried using the tarballs for poky edison and cedartrail bsp and the errors don't occur. So I'm guessing the issue isn't related to Ubuntu 32 vs. 64 bit. Jim A ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] build failure on ubuntu 64bits development system
On Wed, Jan 18, 2012 at 9:30 AM, James Abernathy jfaberna...@gmail.comwrote:
On Wed, Jan 18, 2012 at 7:55 AM, James Abernathy jfaberna...@gmail.comwrote:
I just built a new development pc and installed Ubuntu 11.10 x64. I
wonder if there are any new requirements to building Yocto in that
environment? I got an error right off, but then it complete the first 63
task and stopped successfully. error below:
jim@ubuntu:~/poky/build-cdv$ bitbake core-image-sato
Pseudo is not present but is required, building this first before the
main build
Parsing recipes: 100% |#|
Time: 00:00:25
Parsing of 797 .bb files complete (0 cached, 797 parsed). 1037 targets,
22 skipped, 0 masked, 0 errors.
ERROR: Execution of event handler 'run_buildstats' failed
Traceback (most recent call last):
File run_buildstats(e), line 18, in
run_buildstats(e=bb.event.BuildStarted object at 0x4c338d0)
File buildstats.bbclass, line 21, in
set_device(e=bb.event.BuildStarted object at 0x4c338d0)
UnboundLocalError: local variable 'rdev' referenced before assignment
Any ideas?
JIm A
I went back and tried using the tarballs for poky edison and cedartrail
bsp and the errors don't occur. So I'm guessing the issue isn't related to
Ubuntu 32 vs. 64 bit.
I spoke too soon. Same error in edison tarballs. I looked at the code and
I can see an place were rdev could go un assigned. If you fell out of the
for loop without passing any of the if conditions, rdev would be
unassigned. That must be what is happening in Ubuntu 11.10 x64
Anybody building with Ubuntu 11.10 x64? This doesn't happen on x32
Jim A
def set_device(e):
tmpdir = bb.data.getVar('TMPDIR', e.data, True)
try:
os.remove(bb.data.getVar('DEVFILE', e.data, True))
except:
pass
# We look for the volume TMPDIR lives on. To do all disks would make
little
# sense and not give us any particularly useful data. In theory we
could do
# something like stick DL_DIR on a different partition and this would
# throw stats gathering off. The same goes with SSTATE_DIR. However,
let's
# get the basics in here and work on the cornercases later.
device=os.stat(tmpdir)
majordev=os.major(device.st_dev)
minordev=os.minor(device.st_dev)
for line in open(/proc/diskstats, r):
if majordev == int(line.split()[0]) and minordev ==
int(line.split()[1]):
rdev=line.split()[2]
file = open(bb.data.getVar('DEVFILE', e.data, True), w)
file.write(rdev)
file.close()
Jim A
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] build failure on ubuntu 64bits development system
On Wed, Jan 18, 2012 at 9:51 AM, Gary Thomas g...@mlbassoc.com wrote:
On 2012-01-18 07:42, James Abernathy wrote:
On Wed, Jan 18, 2012 at 9:30 AM, James Abernathy
jfaberna...@gmail.commailto:
jfaberna...@gmail.com** wrote:
On Wed, Jan 18, 2012 at 7:55 AM, James Abernathy
jfaberna...@gmail.com mailto:jfaberna...@gmail.com** wrote:
I just built a new development pc and installed Ubuntu 11.10 x64.
I wonder if there are any new requirements to building Yocto in that
environment? I got an error right
off, but then it complete the first 63 task and stopped
successfully. error below:
jim@ubuntu:~/poky/build-cdv$ bitbake core-image-sato
Pseudo is not present but is required, building this first before
the main build
Parsing recipes: 100%
|#**|
Time: 00:00:25
Parsing of 797 .bb files complete (0 cached, 797 parsed). 1037
targets, 22 skipped, 0 masked, 0 errors.
ERROR: Execution of event handler 'run_buildstats' failed
Traceback (most recent call last):
File run_buildstats(e), line 18, in
run_buildstats(e=bb.event.**BuildStarted object at 0x4c338d0)
File buildstats.bbclass, line 21, in set_device(e=bb.event.*
*BuildStarted object at 0x4c338d0)
UnboundLocalError: local variable 'rdev' referenced before
assignment
Any ideas?
JIm A
I went back and tried using the tarballs for poky edison and
cedartrail bsp and the errors don't occur. So I'm guessing the issue isn't
related to Ubuntu 32 vs. 64 bit.
I spoke too soon. Same error in edison tarballs. I looked at the code
and I can see an place were rdev could go un assigned. If you fell out of
the for loop without passing any of
the if conditions, rdev would be unassigned. That must be what is
happening in Ubuntu 11.10 x64
Anybody building with Ubuntu 11.10 x64? This doesn't happen on x32
Jim A
def set_device(e):
tmpdir = bb.data.getVar('TMPDIR', e.data, True)
try:
os.remove(bb.data.getVar('**DEVFILE', e.data, True))
except:
pass
##**##**
# We look for the volume TMPDIR lives on. To do all disks would make
little
# sense and not give us any particularly useful data. In theory we
could do
# something like stick DL_DIR on a different partition and this would
# throw stats gathering off. The same goes with SSTATE_DIR. However,
let's
# get the basics in here and work on the cornercases later.
##**##**
device=os.stat(tmpdir)
majordev=os.major(device.st_**dev)
minordev=os.minor(device.st_**dev)
for line in open(/proc/diskstats, r):
if majordev == int(line.split()[0]) and minordev ==
int(line.split()[1]):
rdev=line.split()[2]
file = open(bb.data.getVar('DEVFILE', e.data, True), w)
file.write(rdev)
file.close()
Can you show what the differences are between /proc/diskstats
on the two systems? That's obviously what's causing the error.
--
on the x64 system it's:
jim@ubuntu:~/poky-edison-6.0/build$ cat /proc/diskstats
1 0 ram0 0 0 0 0 0 0 0 0 0 0 0
1 1 ram1 0 0 0 0 0 0 0 0 0 0 0
1 2 ram2 0 0 0 0 0 0 0 0 0 0 0
1 3 ram3 0 0 0 0 0 0 0 0 0 0 0
1 4 ram4 0 0 0 0 0 0 0 0 0 0 0
1 5 ram5 0 0 0 0 0 0 0 0 0 0 0
1 6 ram6 0 0 0 0 0 0 0 0 0 0 0
1 7 ram7 0 0 0 0 0 0 0 0 0 0 0
1 8 ram8 0 0 0 0 0 0 0 0 0 0 0
1 9 ram9 0 0 0 0 0 0 0 0 0 0 0
1 10 ram10 0 0 0 0 0 0 0 0 0 0 0
1 11 ram11 0 0 0 0 0 0 0 0 0 0 0
1 12 ram12 0 0 0 0 0 0 0 0 0 0 0
1 13 ram13 0 0 0 0 0 0 0 0 0 0 0
1 14 ram14 0 0 0 0 0 0 0 0 0 0 0
1 15 ram15 0 0 0 0 0 0 0 0 0 0 0
7 0 loop0 0 0 0 0 0 0 0 0 0 0 0
7 1 loop1 0 0 0 0 0 0 0 0 0 0 0
7 2 loop2 0 0 0 0 0 0 0 0 0 0 0
7 3 loop3 0 0 0 0 0 0 0 0 0 0 0
7 4 loop4 0 0 0 0 0 0 0 0 0 0 0
7 5 loop5 0 0 0 0 0 0 0 0 0 0 0
7 6 loop6 0 0 0 0 0 0 0 0 0 0 0
7 7 loop7 0 0 0 0 0 0 0 0 0 0 0
8 0 sda 33076 23382 1115462 1829656 31802 9209 2849176 624296 0
190664 2454576
8 1 sda1 32289 23295 1108604 1827592 27505 9200 2848960 560828 0
131548 2388540
8 2 sda2 429 24 3618 1224 18 9 216 64 0 1260 1288
8 3 sda3 2 0 20 108 0 0 0 0 0 108 108
8 5 sda5 191 63 1900 460 0 0 0 0 0 436 456
8 16 sdb 32063 23153 1112192 1760580 25981 8723 2780656 549424 0
134176 2310272
8 17 sdb1 31842 23153 1110554 1759984 21702 8723 2780656 501512 0
88724 2261696
8 18 sdb2 2 0 12 52 0 0 0 0 0 52 52
8 21 sdb5 47 0 250 228 0 0 0 0 0 228 228
11 0 sr0 0 0 0 0 0 0 0 0 0 0 0
9 0 md0 133691 0 2218832 0 67133 0 5629616 0 0 0 0
9 1 md1 235 0
[yocto] Fwd: build failure on ubuntu 64bits development system
-- Forwarded message --
From: William Mills wmi...@ti.com
Date: Wed, Jan 18, 2012 at 9:57 AM
Subject: Re: [yocto] build failure on ubuntu 64bits development system
To: Gary Thomas g...@mlbassoc.com
Cc: yocto@yoctoproject.org
On 01/18/2012 09:51 AM, Gary Thomas wrote:
On 2012-01-18 07:42, James Abernathy wrote:
On Wed, Jan 18, 2012 at 9:30 AM, James Abernathy
jfaberna...@gmail.commailto:
jfaberna...@gmail.com** wrote:
On Wed, Jan 18, 2012 at 7:55 AM, James Abernathy
jfaberna...@gmail.com mailto:jfaberna...@gmail.com** wrote:
I just built a new development pc and installed Ubuntu 11.10 x64.
I wonder if there are any new requirements to building Yocto in that
environment? I got an error right
off, but then it complete the first 63 task and stopped
successfully. error below:
jim@ubuntu:~/poky/build-cdv$ bitbake core-image-sato
Pseudo is not present but is required, building this first before
the main build
Parsing recipes: 100%
|#**|
Time: 00:00:25
Parsing of 797 .bb files complete (0 cached, 797 parsed). 1037
targets, 22 skipped, 0 masked, 0 errors.
ERROR: Execution of event handler 'run_buildstats' failed
Traceback (most recent call last):
File run_buildstats(e), line 18, in
run_buildstats(e=bb.event.**BuildStarted object at 0x4c338d0)
File buildstats.bbclass, line 21, in set_device(e=bb.event.*
*BuildStarted object at 0x4c338d0)
UnboundLocalError: local variable 'rdev' referenced before
assignment
Any ideas?
JIm A
I went back and tried using the tarballs for poky edison and
cedartrail bsp and the errors don't occur. So I'm guessing the issue isn't
related to Ubuntu 32 vs. 64 bit.
I spoke too soon. Same error in edison tarballs. I looked at the code
and I can see an place were rdev could go un assigned. If you fell out of
the for loop without passing any of
the if conditions, rdev would be unassigned. That must be what is
happening in Ubuntu 11.10 x64
Anybody building with Ubuntu 11.10 x64? This doesn't happen on x32
Jim A
def set_device(e):
tmpdir = bb.data.getVar('TMPDIR', e.data, True)
try:
os.remove(bb.data.getVar('**DEVFILE', e.data, True))
except:
pass
##**##**
# We look for the volume TMPDIR lives on. To do all disks would make
little
# sense and not give us any particularly useful data. In theory we
could do
# something like stick DL_DIR on a different partition and this would
# throw stats gathering off. The same goes with SSTATE_DIR. However,
let's
# get the basics in here and work on the cornercases later.
##**##**
device=os.stat(tmpdir)
majordev=os.major(device.st_**dev)
minordev=os.minor(device.st_**dev)
for line in open(/proc/diskstats, r):
if majordev == int(line.split()[0]) and minordev ==
int(line.split()[1]):
rdev=line.split()[2]
file = open(bb.data.getVar('DEVFILE', e.data, True), w)
file.write(rdev)
file.close()
Can you show what the differences are between /proc/diskstats
on the two systems? That's obviously what's causing the error.
If your build dir is encyptfs or a fuse device or anything that is not a
direct block device you will get this error. This is to be fixed in 1.1.1
but encyptfs will still have other problems.
I build the Ubuntu 11.10 x64 system with 2 drives setup as Soft RAID 0. I
picked btrfs as the file system for no particular reason. Should I go back
to ext4 or is RAID 0 the problem?
JIm A
__**_
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.**org/listinfo/yoctohttps://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Fwd: build failure on ubuntu 64bits development system
On Wed, Jan 18, 2012 at 10:15 AM, William Mills wmi...@ti.com wrote:
On 01/18/2012 10:04 AM, James Abernathy wrote:
-- Forwarded message --
From: *William Mills* wmi...@ti.com mailto:wmi...@ti.com
Date: Wed, Jan 18, 2012 at 9:57 AM
Subject: Re: [yocto] build failure on ubuntu 64bits development system
To: Gary Thomas g...@mlbassoc.com mailto:g...@mlbassoc.com
Cc: yocto@yoctoproject.org mailto:yocto@yoctoproject.org**
On 01/18/2012 09:51 AM, Gary Thomas wrote:
On 2012-01-18 07 tel:2012-01-18%2007:42, James Abernathy wrote:
On Wed, Jan 18, 2012 at 9:30 AM, James Abernathy
jfaberna...@gmail.com mailto:jfaberna...@gmail.com
mailto:jfaberna...@gmail.com mailto:jfaberna...@gmail.com**__
wrote:
On Wed, Jan 18, 2012 at 7:55 AM, James Abernathy
jfaberna...@gmail.com mailto:jfaberna...@gmail.com
mailto:jfaberna...@gmail.com mailto:jfaberna...@gmail.com**__
wrote:
I just built a new development pc and installed Ubuntu 11.10
x64. I wonder if there are any new requirements to building
Yocto in that environment? I got an error right
off, but then it complete the first 63 task and stopped
successfully. error below:
jim@ubuntu:~/poky/build-cdv$ bitbake core-image-sato
Pseudo is not present but is required, building this first
before the main build
Parsing recipes: 100%
|#**__| Time:
00:00:25
Parsing of 797 .bb files complete (0 cached, 797 parsed). 1037
targets, 22 skipped, 0 masked, 0 errors.
ERROR: Execution of event handler 'run_buildstats' failed
Traceback (most recent call last):
File run_buildstats(e), line 18, in
run_buildstats(e=bb.event.__**BuildStarted object at 0x4c338d0)
File buildstats.bbclass, line 21, in
set_device(e=bb.event.__**BuildStarted object at 0x4c338d0)
UnboundLocalError: local variable 'rdev' referenced before
assignment
Any ideas?
JIm A
I went back and tried using the tarballs for poky edison and
cedartrail bsp and the errors don't occur. So I'm guessing the
issue isn't related to Ubuntu 32 vs. 64 bit.
I spoke too soon. Same error in edison tarballs. I looked at the
code and I can see an place were rdev could go un assigned. If
you fell out of the for loop without passing any of
the if conditions, rdev would be unassigned. That must be what
is happening in Ubuntu 11.10 x64
Anybody building with Ubuntu 11.10 x64? This doesn't happen on x32
Jim A
def set_device(e):
tmpdir = bb.data.getVar('TMPDIR', e.data, True)
try:
os.remove(bb.data.getVar('__**DEVFILE', e.data, True))
except:
pass
##**__**
##__
# We look for the volume TMPDIR lives on. To do all disks would
make little
# sense and not give us any particularly useful data. In theory
we could do
# something like stick DL_DIR on a different partition and this
would
# throw stats gathering off. The same goes with SSTATE_DIR.
However, let's
# get the basics in here and work on the cornercases later.
##**__**
##__
device=os.stat(tmpdir)
majordev=os.major(device.st___**dev)
minordev=os.minor(device.st___**dev)
for line in open(/proc/diskstats, r):
if majordev == int(line.split()[0]) and minordev ==
int(line.split()[1]):
rdev=line.split()[2]
file = open(bb.data.getVar('DEVFILE', e.data, True), w)
file.write(rdev)
file.close()
Can you show what the differences are between /proc/diskstats
on the two systems? That's obviously what's causing the error.
If your build dir is encyptfs or a fuse device or anything that is not a
direct block device you will get this error. This is to be fixed in
1.1.1 but encyptfs will still have other problems.
I build the Ubuntu 11.10 x64 system with 2 drives setup as Soft RAID 0.
I picked btrfs as the file system for no particular reason. Should I go
back to ext4 or is RAID 0 the problem?
No, I would not do that yet. I would think software RAID would present a
block device so would not trigger this error.
I was hoping to use RAID 0 for speed. I have a I7 2700K on a DZ68DB with 2
6Gb/s ports matched to 2 6Gb/s 7200 hard drives. Since the builds take so
long, I was looking for an edge.
So are there any recommendations at this point? I'm assuming that the
default ext4 directly on the SATA drive is a fall back position.
Advice?
Jim A
9 0 md0 133691 0 2218832 0 67133 0 5629616 0 0 0 0
9 1 md1 235
Re: [yocto] question on poky and git interaction
On Mon, Jan 16, 2012 at 4:27 AM, Jack Mitchell m...@communistcode.co.ukwrote: On 13/01/12 17:27, Jim Abernathy wrote: under the poky directory you git checkout of the branch you want to work with, then you clone meta-intel and within that directory you checkout a branch. if you needed to use git for you personal project, you can't put it at the same meta-intel level, right? Only one per directory??? I would guess that you'd need to create your personal git clone below meta-intel; something like meta-jima. Does this sound correct?? Jim A __**_ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.**org/listinfo/yoctohttps://lists.yoctoproject.org/listinfo/yocto Hi Jim, This is indeed how I manage my extra package files and anything else poky needs. Any other interesting input would be good to hear though! Slightly off-topic, with meta-intel and then checking out branches to get specific machines, do you do global work in master, machine specific work in the branches, and then merge out from master to the branches to keep them all in sync? At this point, I'm sticking to named releases like Edison. I have not tried Master yet. I need to learn a lot more before I try that. I get enough errors using official releases. Jim A Cheers, Jack. __**_ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.**org/listinfo/yoctohttps://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Developer Manual Appendix B example
I'm trying to do the Developer Manual Appendix B example exactly as written only changing the path to my home directory. When I get to B.1.8.3, bitbake after patching the kernel calibrate.c and modifiing the path to the local git repository for linux-yocto, I get an error on the build. The log file of the error is below: [INFO] doing kernel configme [INFO] Branch yocto/standard/common-pc/base used by common-pc-standard.scc [INFO] collecting configs in ./meta/meta-series mv: cannot stat `/home/jim/poky/build/tmp/work/qemux86-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+72671808fdbe69a9fe03fd8f094e7c59da04a28c-r2/linux-qemux86-standard-build/.tmp.config*': No such file or directory creation of pre-processed config data failed config of yocto/standard/common-pc/base (common-pc-standard.scc) failed ERROR: Function 'do_kernel_configme' failed (see /home/jim/poky/build/tmp/work/qemux86-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+72671808fdbe69a9fe03fd8f094e7c59da04a28c-r2/temp/log.do_kernel_configme.15214 for further information) Any help would be appreciated. Jim A ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Developer Manual Appendix B example
On Thu, Jan 12, 2012 at 9:54 PM, Bruce Ashfield bruce.ashfi...@windriver.com wrote: ** On 12-01-12 09:50 PM, James Abernathy wrote: I'm trying to do the Developer Manual Appendix B example exactly as written only changing the path to my home directory. When I get to B.1.8.3, bitbake after patching the kernel calibrate.c and modifiing the path to the local git repository for linux-yocto, I get an error on the build. The log file of the error is below: Funny how things tend to arrive in bunches. We just discussed this today on the list. The meta-kernel-dev layer is tied to master, and causes this problem when used with edison. And that's what you are seeing here. I'm going to create a edison branch for meta-kernel-dev to match up the tool SRCREVs. In the meantime, if you remove the kern-tools-native_git.bbappend from the meta-kernel-dev layer, the AUTOREV setting will be removed, and you won't pull in tools that are too new for the matching kernel. That worked as you said. I thought it was odd how we did a git checkout for Linux and Poky, but not the poky-extras repositories. Jim A Cheers, Bruce [INFO] doing kernel configme [INFO] Branch yocto/standard/common-pc/base used by common-pc-standard.scc [INFO] collecting configs in ./meta/meta-series mv: cannot stat `/home/jim/poky/build/tmp/work/qemux86-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+72671808fdbe69a9fe03fd8f094e7c59da04a28c-r2/linux-qemux86-standard-build/.tmp.config*': No such file or directory creation of pre-processed config data failed config of yocto/standard/common-pc/base (common-pc-standard.scc) failed ERROR: Function 'do_kernel_configme' failed (see /home/jim/poky/build/tmp/work/qemux86-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+72671808fdbe69a9fe03fd8f094e7c59da04a28c-r2/temp/log.do_kernel_configme.15214 for further information) Any help would be appreciated. Jim A ___ yocto mailing listyocto@yoctoproject.orghttps://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [Announcement] Cedartrail BSP available.
What is the purpose of building the provided images with time limited kernel? Can I assume that a standard build of the unchanged meta-cedartrail BSP will use the non-tlk kernel? Jim A On Wed, Dec 28, 2011 at 6:02 PM, Flanagan, Elizabeth elizabeth.flana...@intel.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, We are pleased to announce the release of Intel-based board support packages built from Yocto 1.1 Edison for the Intel® Atom™ Processor N2000 and D2000 Series-based Platform (CEDAR TRAIL). This BSP are available for download at: http://www.yoctoproject.org/download/bsp/intel%C2%AE-atom%E2%84%A2-processor-n2000-and-d2000-series-based-platform-cedar-trail Please note that the provided images were built using the meta-tlk layer (time limited kernel). Build instructions to build non-tlk images are provided in the meta-intel/meta-cedartrail/README for these machines. META-CEDARTRAIL 1.1 RELEASE Version: 1.1 Edison md5sum: 777150ce79d5d1cc916410f7d17741e1 Location: http://www.yoctoproject.org/download/bsp/intel%C2%AE-atom%E2%84%A2-processor-n2000-and-d2000-series-based-platform-cedar-trail - -- Elizabeth Flanagan Yocto Project Build and Release -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJO+5kmAAoJEEyK+E/MEkQPpqkH/iqYOrfxPd1fEcTbw3LXY+re 1H8zOglldc5yPhkhX2PmqkfI28OJwMOiUc3oooYRGeEpGg59SxQSqSImVwf3nmgn wK933o5FC37M+1fIZsySNNf6Maj5IAExKN1Wu1V56Onf/1wq77kJ/NkvPq62ig5n lZzKA2C1Red/4NuKKIuTEWj/3e5365XhBkbJHxaRECrIw3fD2bBIj49C3tVAkIUX +ijIO56UR/qgHfRulUowtarAfCP/xADOnLnOZ9yvv7JEsaekrMReYZlGqEeF/TL+ M6v3b/27OwgF2ohCN3Ib7YnaFTR5g9fXwa//YMLuKm6quL+hafgzxJ2OCOxlo08= =eKdg -END PGP SIGNATURE- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] understanding what's in an image
On Jan 10, 2012, at 7:03 AM, Gary Thomas wrote: On 2012-01-09 17:51, James Abernathy wrote: I'm trying to understand how bitbake parses the poky directory tree a little better. The best I can figure all .bb files are NOT included. Just some of them are. I'm guessing that the .bb in the meta/recipe-sato named core-image-sato.bb is the one that is used to start the parsing if bitbake core-image-sato is executed. I originally thought all subdirectories of a path included in BBLAYER were parsed looking for .bb files, but now I know that is not true, but not sure why. For example, it does not appear that webkit is included in the core-image-sato even though the recipe-sato directory includes the webkit subdirectory with it's recipe. What would be the proper way of adding the webkit to core-image-sato?? The 'webkit' is just a library used to build tools such as a web browser. You might want to start with an application that actually uses webkit, such as web-webkit. To build an image which includes web-webkit, add this line to your local.conf file and rebuild the image: IMAGE_INSTALL += web-webkit You can also build packages which are not installed into your image by default and use a package manager (e.g. zypper) to install the package later onto a running system. This was very helpful. Before I got your email, I had gotten the advice to put the IMAGE_INSTALL += web-webkit into the core-image-sato.bb file. Both seem to work. Not sure which is the best approach. Maybe creating a .bbappend in my BSP?? So how do I know which applications are installed in an image? is there a how file of IMAGE_INSTALL statements? Jim A -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Trouble creating new package
On Tue, Jan 10, 2012 at 8:20 AM, Jack Mitchell m...@communistcode.co.ukwrote:
On 10/01/12 11:21, Jack Mitchell wrote:
On 10/01/12 11:16, Martin Jansa wrote:
On Tue, Jan 10, 2012 at 11:08:22AM +, Jack Mitchell wrote:
Good morning everyone,
I am currently having issues creating a (very!) simple package. I have
looked at the latest reference manual and studied other .bb files to no
avail.
I am trying to build a simple web server called Hiawatha. To install
(http://www.hiawatha-**webserver.org/howto/**
compilation_and_installationhttp://www.hiawatha-webserver.org/howto/compilation_and_installation
)
it consists of a simple:
./configure
make
make install
Now, for the life in me I cannot replicate this behaviour in a .bb file.
This is what I have so far:
DESCRIPTION = Lightweight secure web server
HOMEPAGE =
http://www.hiawatha-**webserver.orghttp://www.hiawatha-webserver.org/
LICENSE = GPLv2
LIC_FILES_CHKSUM = file://COPYING;md5=**a9b0a0eb7c54c87ec6ac05f5f603df
**6a
SECTION = custom
PR = r0
SRC_URI = http://www.hiawatha-**webserver.org/files/hiawatha-**
7.8.2.tar.gzhttp://www.hiawatha-webserver.org/files/hiawatha-7.8.2.tar.gz
SRC_URI[md5sum] = **8aff3f8c759871ea1d1ff22e980303**32
do_configure () {
./configure --disable-ipv6 \
--disable-ssl \
--disable-toolkit \
--disable-xslt \
--disable-largefile \
oe_runmake
}
do_install () {
oe_runmake install DESTDIR=${D} SBINDIR=${sbindir} MANDIR=${mandir} \
INCLUDEDIR=${includedir}
}
Could someone point me in the right direction, I feel this should be an
extremely easy piece of software to build - I think I'm just not
understanding the build system correctly
The error I receive when trying to build this package is:
ERROR: Function 'do_install' failed (see
/home/jack/yocto/poky-git/**beagleInitial/tmp/work/**
armv5te-poky-linux-gnueabi/**hiawatha-7.8.2-r0/temp/log.do_**install.6289
for further information)
| NOTE: make -j 9 -e MAKEFLAGS= -e install
DESTDIR=/home/jack/yocto/poky-**git/beagleInitial/tmp/work/**
armv5te-poky-linux-gnueabi/**hiawatha-7.8.2-r0/image
SBINDIR=/usr/sbin MANDIR=/usr/share/man INCLUDEDIR=/usr/include
| make: *** No rule to make target `install'. Stop.
| ERROR: oe_runmake failed
try to start with
inherit autotools
Cheers,,
Thanks in advance,
Jack.
__**_
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.**org/listinfo/yoctohttps://lists.yoctoproject.org/listinfo/yocto
Hi Martin,
Inheriting autotools makes no difference, I also don't understand why
autotools should be inherited if it is only a make/configure combination
being used?
Best Regards
__**_
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.**org/listinfo/yoctohttps://lists.yoctoproject.org/listinfo/yocto
Ok, I have managed to get a bit further on this. I didn't realise that I
had to do
bitbake -c clean hiawatha
Everytime I had changed the package to ensure that it was building with
the new configuration. My new .bb looks like this:
DESCRIPTION = Lightweight secure web server
HOMEPAGE =
http://www.hiawatha-**webserver.orghttp://www.hiawatha-webserver.org/
LICENSE = GPLv2
LIC_FILES_CHKSUM = file://COPYING;md5=**a9b0a0eb7c54c87ec6ac05f5f603df**
6a
DEPENDS = openssl libxml2 libxslt
SECTION = custom
PR = r0
SRC_URI = http://www.hiawatha-**webserver.org/files/hiawatha-**
7.8.2.tar.gzhttp://www.hiawatha-webserver.org/files/hiawatha-7.8.2.tar.gz
SRC_URI[md5sum] = **8aff3f8c759871ea1d1ff22e980303**32
inherit autotools
EXTRA_OEMAKE = 'CC=${CC}' 'CFLAGS=${CFLAGS} -I${S}/include
-DWITHOUT_XATTR' \
'BUILDDIR=${S}'
EXTRA_OECONF = --disable-ipv6 \
--disable-ssl \
--disable-toolkit \
--disable-xslt \
--disable-largefile \
--mandir=${mandir}
do_configure() {
oe_runconf
}
do_compile() {
oe_runmake
}
do_install() {
oe_runmake install DESTDIR=${D} SBINDIR=${sbindir}
INCLUDEDIR=${includedir}
Now, this is building and installing however the Hiawatha binary doesn't
get included in the build. The configuration files make it in so I know
it's running the make install phase however I don't know how to find out
what is going on during the build and why the binary isn't making it in the
rootfs.
Maybe you need an IMAGE_INSTALL += hiawatha in you local.conf
Jim A
__**_
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.**org/listinfo/yoctohttps://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] yocto on Acer Aspire One NAV50
I created a core-image-sato using the meta-n450 BSP hoping I could work with it on the Acer Aspire One 532h-2588. However, that netbook uses the Atheros AR5B95 wireless NIC and the Atheros AR8132 wired NIC, which are not recognized. Is there anything already in Yocto that could be turned on to support these devices, or am I left with porting the drives? Since Ubuntu 11.10 with it's kernel 3.0.0 supports these devices and runs on the netbook, I'm guessing it's a matter of configuring the kernel to include these modules. Does this sound right?? Jim A ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] understanding what's in an image
I'm trying to understand how bitbake parses the poky directory tree a little better. The best I can figure all .bb files are NOT included. Just some of them are. I'm guessing that the .bb in the meta/recipe-sato named core-image-sato.bb is the one that is used to start the parsing if bitbake core-image-sato is executed. I originally thought all subdirectories of a path included in BBLAYER were parsed looking for .bb files, but now I know that is not true, but not sure why. For example, it does not appear that webkit is included in the core-image-sato even though the recipe-sato directory includes the webkit subdirectory with it's recipe. What would be the proper way of adding the webkit to core-image-sato?? Jim A ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-ti?????
On Dec 23, 2011, at 3:50 AM, Koen Kooi wrote: Op 23 dec. 2011, om 09:37 heeft Paul Eggleton het volgende geschreven: On Friday 23 December 2011 09:28:31 Koen Kooi wrote: Op 22 dec. 2011, om 16:06 heeft Jim Abernathy het volgende geschreven: I know the examples in the documentation of Yocto use meta-intel a lot to get the board specific BSPs like meta-crownbay or meta-n450. Is there a meta-ti or similar that gets you the meta-beagleboard and meta-pandaboard? If not how do you clone and checkout the pandaboard BPS? http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/ It has a README in there on how to set it up, read it and follow it precisely. Just out of interest, why does meta-texasinstruments depend on meta-angstrom? It needs extra things in overrides and reuses tasks from there. Sorry for the follow-up, but if I clone the meta-texasinstruments bsp repository and checkout the pandaboard-rework branch, how does that relate to the Yocto branch/bsp yocto/standard/pandaboard on the Yocto site? Being a Yocto newbie, it's hard enough to understand all the branches on the yocto site. Relating the meta-angstrom is confusing. The light bulb has now gone on yet :-) Jim A ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] ADT installer
On Nov 23, 2011, at 11:55 AM, Rifenbark, Scott M wrote: Jim, Let me try and replicate this from the manual. I will get back momentarily. Scott -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Jim Abernathy Sent: Wednesday, November 23, 2011 8:45 AM To: yocto@yoctoproject.org Subject: [yocto] ADT installer I was following the ADT manual online, section 2.1.1.1, and everything seemed to complete as expected, but adt_installer.tar.bz2 was not created in the /build/tmp/deploy/sdk direction as documented. In fact, there is no sdk directory in deploy. Is this a documentation issue or is this not working. BTW, I could not find the tarball anywhere on my Ubuntu development system. Jim A ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto The instructions don't have you cd into the directory to execute the source oe-. Not sure if that's a problem. I can rerun. I use the Edison Poky tarball and not the git. Jim A ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] meta-crownbay/README
A couple of items I think need changed in the subject document. 1. the command to copy the license needs recipe changed to recipe-graphics. 2. both of the cp commands need some additional directory reference since meta-intel is not in the IEMGD_HEAD_Linux directoy anywhere. Jim a ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] build failure on crownbay with EMGD
In the past I've built the crownbay-noemgd successfully, using the Development Manual Appendix A corrected instructions that have been patched. I thought I'd try my hand at building the crownbay with EMGD this time. Following the instructions in the Appendix A, but using the opposite instructions related to EMGD, plus installing EMGD per the instructions in the README file in the meta-crownbay directory, I got a long way into the build, but failed toward the end in what looks like a dependance issue. Can someone spot what I need to change??? NOTE: Running noexec task 4432 of 4436 (ID: 715, /home/jim/poky/meta/recipes-kernel/linux/linux-yocto_3.0.bb, do_package_write) NOTE: package eglibc-locale-2.13-r16: task do_package_write_rpm: Succeeded NOTE: Running task 4433 of 4436 (ID: 8, /home/jim/poky/meta/recipes-sato/images/core-image-sato.bb, do_rootfs) NOTE: Running noexec task 4434 of 4436 (ID: 260, /home/jim/poky/meta/recipes-core/eglibc/eglibc-locale_2.13.bb, do_package_write) NOTE: package core-image-sato-1.0-r0: task do_rootfs: Started ERROR: Function 'do_rootfs' failed (see /home/jim/poky/build/tmp/work/mymachine-poky-linux/core-image-sato-1.0-r0/temp/log.do_rootfs.29608 for further information) ERROR: Logfile of failure stored in: /home/jim/poky/build/tmp/work/mymachine-poky-linux/core-image-sato-1.0-r0/temp/log.do_rootfs.29608 Log data follows: | Generating solve db for /home/jim/poky/build/tmp/deploy/rpm/mymachine... |total: 1 0.00 MB 1.251276 secs |fingerprint: 1179 0.007580 MB 0.225419 secs |install: 393 0.00 MB 0.467978 secs |dbadd: 393 0.00 MB 0.458049 secs |dbget:2413 0.00 MB 0.002657 secs |dbput: 393 1.816904 MB 0.387933 secs |readhdr: 3931 3.623312 MB 0.007842 secs |hdrload: 1965 5.352088 MB 0.015769 secs |hdrget: 67287 0.00 MB 0.025251 secs | Generating solve db for /home/jim/poky/build/tmp/deploy/rpm/core2... |total: 1 0.00 MB 30.690842 secs |fingerprint: 16377 0.192190 MB 1.357263 secs |install: 5459 0.00 MB 9.185276 secs |dbadd:5459 0.00 MB 8.997421 secs |dbget: 61190 0.00 MB 0.097393 secs |dbput:5459 27.436448 MB 8.057184 secs |readhdr: 54591 55.326554 MB 0.216373 secs |hdrload: 2 84.106654 MB 0.241450 secs |hdrget: 982855 0.00 MB 0.367838 secs | Generating solve db for /home/jim/poky/build/tmp/deploy/rpm/all... |total: 1 0.00 MB 0.123502 secs |fingerprint:96 0.003258 MB 0.004244 secs |install:32 0.00 MB 0.065233 secs |dbadd: 32 0.00 MB 0.062755 secs |dbget: 585 0.00 MB 0.000230 secs |dbput: 32 0.259492 MB 0.039171 secs |readhdr: 321 0.520536 MB 0.000570 secs |hdrload: 160 0.772764 MB 0.001263 secs |hdrget: 5288 0.00 MB 0.002207 secs | Generating solve db for /home/jim/poky/build/tmp/deploy/rpm/all... |total: 1 0.00 MB 0.111927 secs |fingerprint:96 0.003258 MB 0.004173 secs |install:32 0.00 MB 0.057706 secs |dbadd: 32 0.00 MB 0.055191 secs |dbget: 585 0.00 MB 0.000204 secs |dbput: 32 0.259492 MB 0.034089 secs |readhdr: 321 0.520536 MB 0.000673 secs |hdrload: 160 0.772764 MB 0.001158 secs |hdrget: 5288 0.00 MB 0.001854 secs | Processing locale-base-en-us... | Processing locale-base-en-gb... | Processing task-core-boot... | Processing task-core-apps-console... | Processing task-core-ssh-dropbear... | Processing task-core-apps-x11-pimlico... | Processing task-core-x11-sato... | Processing zypper... | Processing task-core-x11-base... | Processing task-core-apps-x11-games... | Processing task-core-apps-x11-core... | Processing task-base-extended... | Processing rpm... | error: Failed dependencies: | libva.so.1 is needed by libegl1-1.8-r7.core2 | ERROR: Function 'do_rootfs' failed (see /home/jim/poky/build/tmp/work/mymachine-poky-linux/core-image-sato-1.0-r0/temp/log.do_rootfs.29608 for further information) NOTE: package core-image-sato-1.0-r0: task do_rootfs: Failed ERROR: Task 8 (/home/jim/poky/meta/recipes-sato/images/core-image-sato.bb, do_rootfs) failed with exit code '1' ERROR: '/home/jim/poky/meta/recipes-sato/images/core-image-sato.bb' failed jim@jim-ubuntu:~/poky/build$ ___ yocto mailing
Re: [yocto] build failure on crownbay with EMGD
On Wed, Nov 9, 2011 at 12:51 PM, Tom Zanussi tom.zanu...@intel.com wrote: On Wed, 2011-11-09 at 09:41 -0800, James Abernathy wrote: In the past I've built the crownbay-noemgd successfully, using the Development Manual Appendix A corrected instructions that have been patched. I thought I'd try my hand at building the crownbay with EMGD this time. Following the instructions in the Appendix A, but using the opposite instructions related to EMGD, plus installing EMGD per the instructions in the README file in the meta-crownbay directory, I got a long way into the build, but failed toward the end in what looks like a dependance issue. Can someone spot what I need to change??? Yes, you've hit the missing step added to the update release notes here: http://www.yoctoproject.org/download/bsp/intel-atom-processor-e660-intel-platform-controller-hub-eg20t-development-kit-1 7. Remove the following unused file from the emgd binaries in order to avoid a packaging error at build-time: $ rm meta-intel/common/recipes-graphics/xorg-xserver/emgd-driver-bin-1.8/lib/dri/emgd_drv_video.so This was an omission in the README, queued for the next edison point release. If I remember my MeeGo stuff, then removing this file will eliminate the ability to do Media decode acceleration?? Jim A Tom NOTE: Running noexec task 4432 of 4436 (ID: 715, /home/jim/poky/meta/recipes-kernel/linux/linux-yocto_3.0.bb, do_package_write) NOTE: package eglibc-locale-2.13-r16: task do_package_write_rpm: Succeeded NOTE: Running task 4433 of 4436 (ID: 8, /home/jim/poky/meta/recipes-sato/images/core-image-sato.bb, do_rootfs) NOTE: Running noexec task 4434 of 4436 (ID: 260, /home/jim/poky/meta/recipes-core/eglibc/eglibc-locale_2.13.bb, do_package_write) NOTE: package core-image-sato-1.0-r0: task do_rootfs: Started ERROR: Function 'do_rootfs' failed (see /home/jim/poky/build/tmp/work/mymachine-poky-linux/core-image-sato-1.0-r0/temp/log.do_rootfs.29608 for further information) ERROR: Logfile of failure stored in: /home/jim/poky/build/tmp/work/mymachine-poky-linux/core-image-sato-1.0-r0/temp/log.do_rootfs.29608 Log data follows: | Generating solve db for /home/jim/poky/build/tmp/deploy/rpm/mymachine... |total: 1 0.00 MB 1.251276 secs |fingerprint: 1179 0.007580 MB 0.225419 secs |install: 393 0.00 MB 0.467978 secs |dbadd: 393 0.00 MB 0.458049 secs |dbget:2413 0.00 MB 0.002657 secs |dbput: 393 1.816904 MB 0.387933 secs |readhdr: 3931 3.623312 MB 0.007842 secs |hdrload: 1965 5.352088 MB 0.015769 secs |hdrget: 67287 0.00 MB 0.025251 secs | Generating solve db for /home/jim/poky/build/tmp/deploy/rpm/core2... |total: 1 0.00 MB 30.690842 secs |fingerprint: 16377 0.192190 MB 1.357263 secs |install: 5459 0.00 MB 9.185276 secs |dbadd:5459 0.00 MB 8.997421 secs |dbget: 61190 0.00 MB 0.097393 secs |dbput:5459 27.436448 MB 8.057184 secs |readhdr: 54591 55.326554 MB 0.216373 secs |hdrload: 2 84.106654 MB 0.241450 secs |hdrget: 982855 0.00 MB 0.367838 secs | Generating solve db for /home/jim/poky/build/tmp/deploy/rpm/all... |total: 1 0.00 MB 0.123502 secs |fingerprint:96 0.003258 MB 0.004244 secs |install:32 0.00 MB 0.065233 secs |dbadd: 32 0.00 MB 0.062755 secs |dbget: 585 0.00 MB 0.000230 secs |dbput: 32 0.259492 MB 0.039171 secs |readhdr: 321 0.520536 MB 0.000570 secs |hdrload: 160 0.772764 MB 0.001263 secs |hdrget: 5288 0.00 MB 0.002207 secs | Generating solve db for /home/jim/poky/build/tmp/deploy/rpm/all... |total: 1 0.00 MB 0.111927 secs |fingerprint:96 0.003258 MB 0.004173 secs |install:32 0.00 MB 0.057706 secs |dbadd: 32 0.00 MB 0.055191 secs |dbget: 585 0.00 MB 0.000204 secs |dbput: 32 0.259492 MB 0.034089 secs |readhdr: 321 0.520536 MB 0.000673 secs |hdrload: 160 0.772764 MB 0.001158 secs |hdrget: 5288 0.00 MB 0.001854 secs | Processing locale-base-en-us... | Processing locale-base-en-gb... | Processing task-core-boot... | Processing task
Re: [yocto] build failure on crownbay with EMGD
On Wed, Nov 9, 2011 at 2:43 PM, Tom Zanussi tom.zanu...@intel.com wrote: On Wed, 2011-11-09 at 10:24 -0800, James Abernathy wrote: On Wed, Nov 9, 2011 at 12:56 PM, James Abernathy jfaberna...@gmail.com wrote: On Wed, Nov 9, 2011 at 12:51 PM, Tom Zanussi tom.zanu...@intel.com wrote: On Wed, 2011-11-09 at 09:41 -0800, James Abernathy wrote: In the past I've built the crownbay-noemgd successfully, using the Development Manual Appendix A corrected instructions that have been patched. I thought I'd try my hand at building the crownbay with EMGD this time. Following the instructions in the Appendix A, but using the opposite instructions related to EMGD, plus installing EMGD per the instructions in the README file in the meta-crownbay directory, I got a long way into the build, but failed toward the end in what looks like a dependance issue. Can someone spot what I need to change??? Yes, you've hit the missing step added to the update release notes here: http://www.yoctoproject.org/download/bsp/intel-atom-processor-e660-intel-platform-controller-hub-eg20t-development-kit-1 7. Remove the following unused file from the emgd binaries in order to avoid a packaging error at build-time: $ rm meta-intel/common/recipes-graphics/xorg-xserver/emgd-driver-bin-1.8/lib/dri/emgd_drv_video.so This was an omission in the README, queued for the next edison point release. If I remember my MeeGo stuff, then removing this file will eliminate the ability to do Media decode acceleration?? Not sure what it takes to get past this error. Just removing the file and rerunning bitbake gets the same error. Do I need to reset something before rerunning??? You should bump the PR of emgd-driver-bin_1.8.bb to get it to use the new contents i.e. change PR = r7 to PR = r8 To Okay, that fixed the issue. Now, how was I to know that? Is that a basic step in reruns? I'm guessing if I started from scratch and rm'ed the video file the first time it would have run with PR = r7? Let me know what I should have read to know about the PR setting Thanks, JIm A Jim A Tom NOTE: Running noexec task 4432 of 4436 (ID: 715, /home/jim/poky/meta/recipes-kernel/linux/ linux-yocto_3.0.bb, do_package_write) NOTE: package eglibc-locale-2.13-r16: task do_package_write_rpm: Succeeded NOTE: Running task 4433 of 4436 (ID: 8, /home/jim/poky/meta/recipes-sato/images/ core-image-sato.bb, do_rootfs) NOTE: Running noexec task 4434 of 4436 (ID: 260, /home/jim/poky/meta/recipes-core/eglibc/ eglibc-locale_2.13.bb, do_package_write) NOTE: package core-image-sato-1.0-r0: task do_rootfs: Started ERROR: Function 'do_rootfs' failed (see /home/jim/poky/build/tmp/work/mymachine-poky-linux/core-image-sato-1.0-r0/temp/log.do_rootfs.29608 for further information) ERROR: Logfile of failure stored in: /home/jim/poky/build/tmp/work/mymachine-poky-linux/core-image-sato-1.0-r0/temp/log.do_rootfs.29608 Log data follows: | Generating solve db for /home/jim/poky/build/tmp/deploy/rpm/mymachine... |total: 1 0.00 MB 1.251276 secs |fingerprint: 1179 0.007580 MB 0.225419 secs |install: 393 0.00 MB 0.467978 secs |dbadd: 393 0.00 MB 0.458049 secs |dbget:2413 0.00 MB 0.002657 secs |dbput: 393 1.816904 MB 0.387933 secs |readhdr: 3931 3.623312 MB 0.007842 secs |hdrload: 1965 5.352088 MB 0.015769 secs |hdrget: 67287 0.00 MB 0.025251 secs
Re: [yocto] build failure on crownbay with EMGD
On Wed, Nov 9, 2011 at 3:16 PM, Tom Zanussi tom.zanu...@intel.com wrote: On Wed, 2011-11-09 at 12:03 -0800, James Abernathy wrote: On Wed, Nov 9, 2011 at 2:43 PM, Tom Zanussi tom.zanu...@intel.com wrote: On Wed, 2011-11-09 at 10:24 -0800, James Abernathy wrote: On Wed, Nov 9, 2011 at 12:56 PM, James Abernathy jfaberna...@gmail.com wrote: On Wed, Nov 9, 2011 at 12:51 PM, Tom Zanussi tom.zanu...@intel.com wrote: On Wed, 2011-11-09 at 09:41 -0800, James Abernathy wrote: In the past I've built the crownbay-noemgd successfully, using the Development Manual Appendix A corrected instructions that have been patched. I thought I'd try my hand at building the crownbay with EMGD this time. Following the instructions in the Appendix A, but using the opposite instructions related to EMGD, plus installing EMGD per the instructions in the README file in the meta-crownbay directory, I got a long way into the build, but failed toward the end in what looks like a dependance issue. Can someone spot what I need to change??? Yes, you've hit the missing step added to the update release notes here: http://www.yoctoproject.org/download/bsp/intel-atom-processor-e660-intel-platform-controller-hub-eg20t-development-kit-1 7. Remove the following unused file from the emgd binaries in order to avoid a packaging error at build-time: $ rm meta-intel/common/recipes-graphics/xorg-xserver/emgd-driver-bin-1.8/lib/dri/emgd_drv_video.so This was an omission in the README, queued for the next edison point release. If I remember my MeeGo stuff, then removing this file will eliminate the ability to do Media decode acceleration?? Not sure what it takes to get past this error. Just removing the file and rerunning bitbake gets the same error. Do I need to reset something before rerunning??? You should bump the PR of emgd-driver-bin_1.8.bb to get it to use the new contents i.e. change PR = r7 to PR = r8 To Okay, that fixed the issue. Now, how was I to know that? Is that a basic step in reruns? I'm guessing if I started from scratch and rm'ed the video file the first time it would have run with PR = r7? Let me know what I should have read to know about the PR setting Yeah, in general, if you change a package, you need to update the PR so it gets rebuilt. It's described here: http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html 3.4.3. Package Revision Incrementing Admittedly, it might not be something a beginner would easily find, but on the other hand, the instructions assume you're doing the setup before a first build where rebuilding the package wouldn't matter. On the other hand, I guess the reason it happened in the first place was due to the omission in the README, which by necessity could only be addressed in the release notes for the BSP. So we probably need to add a note to bump the PR to the addition in the release notes as well. Sound right? Tom I was one chapter behind. :-) I guess for my background there are a lot of new concepts. In normal kernel development, back in the day, you edited a file and the date changed and make found it and it's dependencies, then rebuilt those. Maybe PR solves some problem that forced us to do make clean or make mrproper. JIm A Thanks, JIm A Jim A Tom NOTE: Running noexec task 4432 of 4436 (ID: 715, /home/jim/poky/meta/recipes-kernel/linux/linux-yocto_3.0.bb , do_package_write) NOTE: package eglibc-locale
[yocto] use case howto?
I approach embedded Linux from a path of taking a Distro like Ubuntu or Fedora and chopping it down to a working set of code that forms the final solution. Obviously, not the same methology as Yocto. With some success with the current methods, it's difficult to see the advantages of Yocto. I'm reading what I can find to get smarting on Yocto, but like most new concepts, you try to compare what you used to do with how to do it with the new concept. For example, if I use a distro, I can install packages really simply with yum or apt-get; update them the same way. If I start with a Yocto meta-??? that's closest to my hardware solution, and get it working at a base level, how do I add things, like browsers, or other application? Jim A ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] use case howto?
I thought the idea was to build a recipe for your device that could create the software complete with all the pieces. Certainly, having a list of packages that you need to install via zypper is fine, but I thought that not the concept behind Yocto??? Sorry for the dumb questions. Jim A On Mon, Nov 7, 2011 at 5:04 PM, Gary Thomas g...@mlbassoc.com wrote: On 2011-11-07 14:59, James Abernathy wrote: I approach embedded Linux from a path of taking a Distro like Ubuntu or Fedora and chopping it down to a working set of code that forms the final solution. Obviously, not the same methology as Yocto. With some success with the current methods, it's difficult to see the advantages of Yocto. I'm reading what I can find to get smarting on Yocto, but like most new concepts, you try to compare what you used to do with how to do it with the new concept. For example, if I use a distro, I can install packages really simply with yum or apt-get; update them the same way. If I start with a Yocto meta-??? that's closest to my hardware solution, and get it working at a base level, how do I add things, like browsers, or other application? Using very similar tools - zypper is just like yum, or if you choose to use ipk packages, opkg -- --**-- Gary Thomas | Consulting for the MLB Associates |Embedded world --**-- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] use case howto?
On Nov 7, 2011, at 7:12 PM, Gary Thomas wrote: On 2011-11-07 15:15, James Abernathy wrote: I thought the idea was to build a recipe for your device that could create the software complete with all the pieces. Certainly, having a list of packages that you need to install via zypper is fine, but I thought that not the concept behind Yocto??? Sorry for the dumb questions. It's actually a combination of both worlds - you can use existing recipes to add functionality by just including those packages in your system, either at initial build time or by using the packaging tools. You can also easily write your own recipes to build specialized packages. The combination is up to you. So if I wanted to build Firefox into my Yocto project. How is that done?? Jim A A point of terminology - recipes are used to construct packages which can then be installed, etc. They are functional units, not necessarily tied to any particular device or system. n.b. top posting on mailing lists makes your replies harder to follow :-( On Mon, Nov 7, 2011 at 5:04 PM, Gary Thomas g...@mlbassoc.com mailto:g...@mlbassoc.com wrote: On 2011-11-07 14:59, James Abernathy wrote: I approach embedded Linux from a path of taking a Distro like Ubuntu or Fedora and chopping it down to a working set of code that forms the final solution. Obviously, not the same methology as Yocto. With some success with the current methods, it's difficult to see the advantages of Yocto. I'm reading what I can find to get smarting on Yocto, but like most new concepts, you try to compare what you used to do with how to do it with the new concept. For example, if I use a distro, I can install packages really simply with yum or apt-get; update them the same way. If I start with a Yocto meta-??? that's closest to my hardware solution, and get it working at a base level, how do I add things, like browsers, or other application? Using very similar tools - zypper is just like yum, or if you choose to use ipk packages, opkg -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build error while following Appendix A. Yocto Project Development manual
I had some success, so I thought I'd report that out:
Following a combination of the Yocto Project Development Manual and Tom's
notes below, I got a successful
build and the image booted from a USB flash drive on a Crownbay Development
platform, without EMGD GFX driver.
The only change I needed to make it bootable from Tom's instructions was to
make KMACHINE_mymachine = yocto/standard/crownbay and
put in the correct SRCREV commit strings for the crownbay using the
howto instructions in Appendix A.5.2.4 6th paragraph.
Now on to making the EMGD image work.
Jim A
On Tue, Nov 1, 2011 at 8:45 PM, Tom Zanussi tom.zanu...@intel.com wrote:
Hi James,
I'm still not sure what happened in your case to cause this problem, but
I just went through the Appendix A example pretty much as described, and
got a good build out of it. There was one particular part of the
example that wasn't exactly clear and that could definitely cause some
build problems if you did it incorrectly (the section that makes changes
to linux-yocto_3.0.bbappend, which in the example has a custom branch in
the .bbappend file, but has the explanation using atom-pc).
I'll work with Scott to make sure that part gets cleaned up, along with
the other comments that should get pulled in, but in the meantime, I
captured the steps I used below, which should work in the same way for
you.
trz@elmorro:/usr/local/dev/yocto$ mkdir bsp-test; cd bsp-test
trz@elmorro:/usr/local/dev/yocto/bsp-test$ git clone git://
git.yoctoproject.org/poky
trz@elmorro:/usr/local/dev/yocto/bsp-test$ cd poky
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ git checkout -b edison
origin/edison
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ git clone git://
git.yoctoproject.org/meta-intel.git
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ cd meta-intel
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ git checkout
-b edison origin/edison
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ cp -a
meta-crownbay/ meta-mymachine
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ rm
meta-mymachine/conf/machine/crownbay.conf
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ mv
meta-mymachine/conf/machine/crownbay-noemgd.conf
meta-mymachine/conf/machine/mymachine.conf
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ rm -rf
meta-mymachine/recipes-bsp/formfactor/formfactor/crownbay/
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ mv
meta-mymachine/recipes-bsp/formfactor/formfactor/crownbay-noemgd
meta-mymachine/recipes-bsp/formfactor/formfactor/mymachine
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ rm -rf
meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay
The Developer's Manual seems to want to base the BSP on atom-pc for
this example, so we need to specify the atom-pc branch and get the
SRCREVs for atom-pc or the step that modifies the
linux-yocto_3.0.bbappend. So in
meta-yocto/recipes-kernel/linux/linux-yocto_3.0.bbappend, we find both
the KMACHINE branch we need, and the SRCREV on that branch we need for
edison. Since that doesn't specify the meta branch, but the base
recipe does, we can look at the SRCREV_meta there
(meta/recipes-kernel/linux/linux-yocto_3.0.bb) for the SRCREV of the
meta branch, which already matches what we're using, so no change
needed there.
Here's the resulting linux-yocto_3.0.bbappend:
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/meta-intel$ cat
meta-mymachine/recipes-kernel/linux/linux-yocto_3.0.bbappend
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
COMPATIBLE_MACHINE_mymachine = mymachine
KMACHINE_mymachine = yocto/standard/common-pc/atom-pc
KERNEL_FEATURES_append_mymachine += cfg/smp.scc
SRCREV_machine_pn-linux-yocto_mymachine ?=
1e18e44adbe79b846e382370eb29bc4b8cd5a1a0
SRCREV_meta_pn-linux-yocto_mymachine ?=
d05450e4aef02c1b7137398ab3a9f8f96da74f52
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ source oe-init-build-env
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky$ bitbake core-image-sato
NOTE: Tasks Summary: Attempted 4426 tasks of which 247 didn't need to be
rerun and 0 failed.
trz@elmorro:/usr/local/dev/yocto/bsp-test/poky/build
Tom
On Tue, 2011-11-01 at 12:48 -0700, James Abernathy wrote:
Just to clear up the basics, Prior to following Appendix A verbatim, I
did the following
1. install prerequisites from GS guide
2. git clone git://git.yoctoproject.org/poky
3. cd poky
4. git clone git://git.yoctoproject.org/meta-intel.git
I did not install the poky-extras. I assumed it only had to be
installed if you installed the kernel source for modification like in
Appendix b
Jim a
On Tue, Nov 1, 2011 at 3:40 PM, Tom Zanussi tom.zanu...@intel.com
wrote:
Hi,
On Tue, 2011-11-01 at 11:37 -0700, James Abernathy wrote:
I tried to duplicate the Yocto Project Decelopment Manual
Appendix A
build
Re: [yocto] Build error while following Appendix A. Yocto Project Development manual
Just to clear up the basics, Prior to following Appendix A verbatim, I did the following 1. install prerequisites from GS guide 2. git clone git://git.yoctoproject.org/poky 3. cd poky 4. git clone git://git.yoctoproject.org/meta-intel.git I did not install the poky-extras. I assumed it only had to be installed if you installed the kernel source for modification like in Appendix b Jim a On Tue, Nov 1, 2011 at 3:40 PM, Tom Zanussi tom.zanu...@intel.com wrote: Hi, On Tue, 2011-11-01 at 11:37 -0700, James Abernathy wrote: I tried to duplicate the Yocto Project Decelopment Manual Appendix A build of a Crownbay NOEMGD image, no changes just dulicate the instructions. This is using the latest Yocto 1.1. I did get a long way down the line, but had a fatal error in the last 2 steps. The only change I had to make was related to A.5.2.4. The commit string for the SRCREV_meta_pn was different on the git.yoctoproject.org/cgit/cgi for the Meta commit so I used what I found online. The first section of 126 task completed without error. The next section of 4394 tasks failed on 4393. Not sure if the error is obvious, but I wanted to run it by someone. Console error log below: Hmm, not sure what's going on here - I'm sure this example was verified several times, but just to make sure, what you're doing is going through 'Appendix A. BSP Development Example' verbatim and getting this? The SRCREVs in either case look ok for this, so that shouldn't be the problem... But let me go over the steps myself and see what I come up with - will let you know either way... Tom NOTE: package core-image-sato-1.0-r0: task do_bootimg: Started ERROR: Function 'build_boot_bin' failed (see /home/jim/poky/yocto-build/tmp/work/mymachine-poky-linux/core-image-sato-1.0-r0/temp/log.do_bootimg.31418 for further information) ERROR: Logfile of failure stored in: /home/jim/poky/yocto-build/tmp/work/mymachine-poky-linux/core-image-sato-1.0-r0/temp/log.do_bootimg.31418 Log data follows: | install: cannot stat `/home/jim/poky/yocto-build/tmp/sysroots/mymachine/kernel/bzImage': No such file or directory | ERROR: Function 'build_boot_bin' failed (see /home/jim/poky/yocto-build/tmp/work/mymachine-poky-linux/core-image-sato-1.0-r0/temp/log.do_bootimg.31418 for further information) NOTE: package core-image-sato-1.0-r0: task do_bootimg: Failed ERROR: Task 9 (/home/jim/poky/meta/recipes-sato/images/core-image-sato.bb, do_bootimg) failed with exit code '1' ERROR: '/home/jim/poky/meta/recipes-sato/images/core-image-sato.bb' failed jim@jim-ubuntu-10:~/poky/yocto-build$ ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
