Re: [yocto] examples / docs on utilizing an external toolchain
On Aug 3, 2011, at 10:12 AM, Richard Purdie wrote: > On Wed, 2011-08-03 at 09:50 -0500, Kumar Gala wrote: >> On Aug 3, 2011, at 9:22 AM, Richard Purdie wrote: >> >>> On Wed, 2011-08-03 at 09:04 -0500, Kumar Gala wrote: Bug submitted: http://bugzilla.pokylinux.org/show_bug.cgi?id=1323 My question still stands even w/o it being in formal docs. >>> >>> FWIW, POKYMODE was replaced by TCMODE as part of the OE-Core changes. >>> I'd be interested to know where we've missed the references to it and >>> get to get those references fixed. >> >> Ok, but how does one use TCMODE? :) >> >> is there an example around anywhere? > > I'll explain on the condition that someone actually documents this ;-). > > TCMODE determines which of the files in > meta/conf/distro/include/tcmode-* is used. It defaults to "default" and > our default toolchain definition is in tcmode-default.inc. > > There is another example there which is "external-csl2008q3". As you can > see from the tcmode-external-csl2008q3 file, it sets up the system to > use an external toolchain instead. > > So you can define one of these files in your layer and then the system > can select alternative toolchain configurations. > > Does that help? :) > > There is a similar TCLIBC variable which controls which libc is used > (eglibc or uclibc). Yes that helps. So it looks as if today there is not a means to point to SDK prebuilt toolchain via this means. - k ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/2] meta-fri2: new layer for Fish River Island II (E6XX/EG20T) systems
Hi Tom, A few thoughts below. These are all things I can pick up once I return as well if there is some urgency to get these in tree. -- Darren On 08/02/2011 09:05 PM, tom.zanu...@intel.com wrote: > From: Tom Zanussi > > This layer provides support for E6XX + EG20T Intel systems. > > Currently it supports only vesa graphics, which will be upgraded > shortly. > > Signed-off-by: Tom Zanussi > --- > meta-fri2/COPYING.MIT | 17 > meta-fri2/README | 83 > > meta-fri2/README.sources | 17 > meta-fri2/conf/layer.conf | 10 +++ > meta-fri2/conf/machine/fri2.conf | 36 + > .../formfactor/formfactor/fri2/machconfig |3 + > .../recipes-bsp/formfactor/formfactor_0.0.bbappend |3 + > .../recipes-core/tasks/task-core-tools.bbappend|2 + > .../xserver-xf86-config/fri2/xorg.conf | 26 ++ > .../xorg-xserver/xserver-xf86-config_0.1.bbappend |3 + > .../recipes-kernel/linux/linux-yocto_3.0.bbappend |6 ++ > 11 files changed, 206 insertions(+), 0 deletions(-) > create mode 100644 meta-fri2/COPYING.MIT > create mode 100644 meta-fri2/README > create mode 100644 meta-fri2/README.sources > create mode 100644 meta-fri2/binary/.gitignore > create mode 100644 meta-fri2/conf/layer.conf > create mode 100644 meta-fri2/conf/machine/fri2.conf > create mode 100644 > meta-fri2/recipes-bsp/formfactor/formfactor/fri2/machconfig > create mode 100644 meta-fri2/recipes-bsp/formfactor/formfactor_0.0.bbappend > create mode 100644 meta-fri2/recipes-core/tasks/task-core-tools.bbappend > create mode 100644 > meta-fri2/recipes-graphics/xorg-xserver/xserver-xf86-config/fri2/xorg.conf > create mode 100644 > meta-fri2/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend > create mode 100644 meta-fri2/recipes-kernel/linux/linux-yocto_3.0.bbappend > > diff --git a/meta-fri2/COPYING.MIT b/meta-fri2/COPYING.MIT > new file mode 100644 > index 000..fb950dc > --- /dev/null > +++ b/meta-fri2/COPYING.MIT > @@ -0,0 +1,17 @@ > +Permission is hereby granted, free of charge, to any person obtaining a copy > +of this software and associated documentation files (the "Software"), to > deal > +in the Software without restriction, including without limitation the rights > +to use, copy, modify, merge, publish, distribute, sublicense, and/or sell > +copies of the Software, and to permit persons to whom the Software is > +furnished to do so, subject to the following conditions: > + > +The above copyright notice and this permission notice shall be included in > +all copies or substantial portions of the Software. > + > +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE > +AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER > +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > FROM, > +OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN > +THE SOFTWARE. > diff --git a/meta-fri2/README b/meta-fri2/README > new file mode 100644 > index 000..7957a7f > --- /dev/null > +++ b/meta-fri2/README > @@ -0,0 +1,83 @@ > +This README file contains information on building the meta-fri2 BSP > +layer, and booting the images contained in the /binary directory. > +Please see the corresponding sections below for details. > + > + > +Table of Contents > += > + > + I. Special notes on the meta-fri2 BSP layer > + II. Building the meta-fri2 BSP layer > +III. Booting the images in /binary > + > + > +II. Building the meta-fri2 BSP layer > += > + > +In order to build an image with BSP support for a given release, you > +need to download the corresponding BSP tarball from the 'Board Support > +Package (BSP) Downloads' page of the Yocto Project website. > + > +Having done that, and assuming you extracted the BSP tarball contents > +at the top-level of your yocto build tree, you can build a fri2 image > +by adding the location of the meta-fri2 layer to bblayers.conf e.g.: > + > + yocto/meta-intel/meta-fri2 \ > + > +To enable the fri2 layer, add the fri2 MACHINE to local.conf: > + > + MACHINE ?= "fri2" > + > +You should then be able to build a fri2 image as such: > + > + $ source poky-init-build-env > + $ bitbake poky-image-sato-live These should be corrected with their oe- and core- equivalents. Also, I presume the FSTYPE should include -live by default now as the other BSPs have been recently updated to do? > + > +At the end of a successful build, you should have a live image that > +you can boot from a USB flash drive (see instructions on how to do > +that below, in the section 'Booting the images from /binary').
[yocto] [PATCH 1/2] meta-sugarbay: update machine configuration for recent tune file changes
Require the tune file for x86_64, then TARGET_ARCH is set via the tune file and TRANSLATED_TARGET_ARCH is set automatically in bitbake.conf. Signed-off-by: Paul Eggleton --- meta-sugarbay/conf/machine/sugarbay.conf |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/meta-sugarbay/conf/machine/sugarbay.conf b/meta-sugarbay/conf/machine/sugarbay.conf index 9450d97..9add1ca 100644 --- a/meta-sugarbay/conf/machine/sugarbay.conf +++ b/meta-sugarbay/conf/machine/sugarbay.conf @@ -4,8 +4,9 @@ #@DESCRIPTION: Machine configuration for Sugar Bay systems # i.e. Sandy Bridge + Cougar Point -TARGET_ARCH = "x86_64" -PACKAGE_EXTRA_ARCHS = "x86 snb" +require conf/machine/include/tune-x86_64.inc + +PACKAGE_EXTRA_ARCHS = "x86_64 snb" BASE_PACKAGE_ARCH="snb" -- 1.7.4.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 2/2] meta-jasperforest: update machine configuration for recent tune file changes
Require the tune file for x86_64, then TARGET_ARCH is set via the tune file and TRANSLATED_TARGET_ARCH is set automatically in bitbake.conf. Signed-off-by: Paul Eggleton --- meta-jasperforest/conf/machine/jasperforest.conf |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/meta-jasperforest/conf/machine/jasperforest.conf b/meta-jasperforest/conf/machine/jasperforest.conf index 1d875b5..b21a417 100644 --- a/meta-jasperforest/conf/machine/jasperforest.conf +++ b/meta-jasperforest/conf/machine/jasperforest.conf @@ -4,8 +4,9 @@ #@DESCRIPTION: Machine configuration for Jasper Forest Picket Post # systems i.e. Xeon C5500/C3500 + Intel 3420 chipset (Ibex Peak) -TARGET_ARCH = "x86_64" -PACKAGE_EXTRA_ARCHS = "x86 xeon" +require conf/machine/include/tune-x86_64.inc + +PACKAGE_EXTRA_ARCHS = "x86_64 xeon" BASE_PACKAGE_ARCH="xeon" -- 1.7.4.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 0/2] [meta-intel] Fix meta-intel BSPs for tune file changes
Two patches to fix "TUNE_ARCH unset" and "PACKAGE_ARCHS variable does not contain TUNE_PKGARCH" on the autobuilder for sugarbay and jasperforest. The following changes since commit 567c3b6436b4cb9551c23845c15ab544542b5083: meta-crownbay: remove obsolete dir (2011-08-03 12:14:39 -0500) are available in the git repository at: git://git.yoctoproject.org/meta-intel-contrib paule/tune http://git.yoctoproject.org/cgit.cgi/meta-intel-contrib/log/?h=paule/tune Paul Eggleton (2): meta-sugarbay: update machine configuration for recent tune file changes meta-jasperforest: update machine configuration for recent tune file changes meta-jasperforest/conf/machine/jasperforest.conf |5 +++-- meta-sugarbay/conf/machine/sugarbay.conf |5 +++-- 2 files changed, 6 insertions(+), 4 deletions(-) -- 1.7.4.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/2] meta-sugarbay: update machine configuration for recent tune file changes
On Thu, 2011-08-04 at 14:03 +0100, Paul Eggleton wrote: > Require the tune file for x86_64, then TARGET_ARCH is set via the tune > file and TRANSLATED_TARGET_ARCH is set automatically in bitbake.conf. > > Signed-off-by: Paul Eggleton > --- > meta-sugarbay/conf/machine/sugarbay.conf |5 +++-- > 1 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a/meta-sugarbay/conf/machine/sugarbay.conf > b/meta-sugarbay/conf/machine/sugarbay.conf > index 9450d97..9add1ca 100644 > --- a/meta-sugarbay/conf/machine/sugarbay.conf > +++ b/meta-sugarbay/conf/machine/sugarbay.conf > @@ -4,8 +4,9 @@ > #@DESCRIPTION: Machine configuration for Sugar Bay systems > # i.e. Sandy Bridge + Cougar Point > > -TARGET_ARCH = "x86_64" > -PACKAGE_EXTRA_ARCHS = "x86 snb" > +require conf/machine/include/tune-x86_64.inc > + > +PACKAGE_EXTRA_ARCHS = "x86_64 snb" > > BASE_PACKAGE_ARCH="snb" What difference is BASE_PACKAGE_ARCH or snb making in this case? Cheers, Richard ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 2/2] meta-jasperforest: update machine configuration for recent tune file changes
On Thu, 2011-08-04 at 14:03 +0100, Paul Eggleton wrote: > Require the tune file for x86_64, then TARGET_ARCH is set via the tune > file and TRANSLATED_TARGET_ARCH is set automatically in bitbake.conf. > > Signed-off-by: Paul Eggleton > --- > meta-jasperforest/conf/machine/jasperforest.conf |5 +++-- > 1 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a/meta-jasperforest/conf/machine/jasperforest.conf > b/meta-jasperforest/conf/machine/jasperforest.conf > index 1d875b5..b21a417 100644 > --- a/meta-jasperforest/conf/machine/jasperforest.conf > +++ b/meta-jasperforest/conf/machine/jasperforest.conf > @@ -4,8 +4,9 @@ > #@DESCRIPTION: Machine configuration for Jasper Forest Picket Post > # systems i.e. Xeon C5500/C3500 + Intel 3420 chipset (Ibex Peak) > > -TARGET_ARCH = "x86_64" > -PACKAGE_EXTRA_ARCHS = "x86 xeon" > +require conf/machine/include/tune-x86_64.inc > + > +PACKAGE_EXTRA_ARCHS = "x86_64 xeon" > > BASE_PACKAGE_ARCH="xeon" Likewise, what is special about the "xeon" package arch? Cheers, Richard ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/2] [meta-intel] Fix meta-intel BSPs for tune file changes
Thanks, Paul. I made some similar changes here for both of these last week, but haven't been able to boot them (getting a kernel oops) so haven't posted them or checked them in. Once I get past that, I'll be able to check those in... Thanks, Tom On Thu, 2011-08-04 at 06:03 -0700, Paul Eggleton wrote: > Two patches to fix "TUNE_ARCH unset" and "PACKAGE_ARCHS variable does not > contain TUNE_PKGARCH" on the autobuilder for sugarbay and jasperforest. > > The following changes since commit 567c3b6436b4cb9551c23845c15ab544542b5083: > > meta-crownbay: remove obsolete dir (2011-08-03 12:14:39 -0500) > > are available in the git repository at: > git://git.yoctoproject.org/meta-intel-contrib paule/tune > http://git.yoctoproject.org/cgit.cgi/meta-intel-contrib/log/?h=paule/tune > > Paul Eggleton (2): > meta-sugarbay: update machine configuration for recent tune file > changes > meta-jasperforest: update machine configuration for recent tune file > changes > > meta-jasperforest/conf/machine/jasperforest.conf |5 +++-- > meta-sugarbay/conf/machine/sugarbay.conf |5 +++-- > 2 files changed, 6 insertions(+), 4 deletions(-) > ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/2] [meta-intel] Fix meta-intel BSPs for tune file changes
On Thursday 04 August 2011 14:29:47 Tom Zanussi wrote: > Thanks, Paul. I made some similar changes here for both of these last > week, but haven't been able to boot them (getting a kernel oops) so > haven't posted them or checked them in. Once I get past that, I'll be > able to check those in... OK, FYI after discussion with Richard I'll be posting a v2 set shortly. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 0/2] [meta-intel] Fix meta-intel BSPs for tune file changes v2
Two patches to fix "TUNE_ARCH unset" and "PACKAGE_ARCHS variable does not contain TUNE_PKGARCH" on the autobuilder for sugarbay and jasperforest. Since v1, after discussion with Richard remove additional package architectures that aren't apparently doing anything. The following changes since commit 567c3b6436b4cb9551c23845c15ab544542b5083: meta-crownbay: remove obsolete dir (2011-08-03 12:14:39 -0500) are available in the git repository at: git://git.yoctoproject.org/meta-intel-contrib paule/tune http://git.yoctoproject.org/cgit.cgi/meta-intel-contrib/log/?h=paule/tune Paul Eggleton (2): meta-sugarbay: update machine configuration for recent tune file changes meta-jasperforest: update machine configuration for recent tune file changes meta-jasperforest/conf/machine/jasperforest.conf |7 +-- meta-sugarbay/conf/machine/sugarbay.conf |7 +-- 2 files changed, 2 insertions(+), 12 deletions(-) -- 1.7.4.1 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/2] meta-sugarbay: update machine configuration for recent tune file changes
Require the tune file for x86_64, then TARGET_ARCH and TARGET_CC_ARCH are set already. Also remove superfluous "snb" package architecture that doesn't do anything. Signed-off-by: Paul Eggleton --- meta-sugarbay/conf/machine/sugarbay.conf |7 +-- 1 files changed, 1 insertions(+), 6 deletions(-) diff --git a/meta-sugarbay/conf/machine/sugarbay.conf b/meta-sugarbay/conf/machine/sugarbay.conf index 9450d97..2a47dee 100644 --- a/meta-sugarbay/conf/machine/sugarbay.conf +++ b/meta-sugarbay/conf/machine/sugarbay.conf @@ -4,10 +4,7 @@ #@DESCRIPTION: Machine configuration for Sugar Bay systems # i.e. Sandy Bridge + Cougar Point -TARGET_ARCH = "x86_64" -PACKAGE_EXTRA_ARCHS = "x86 snb" - -BASE_PACKAGE_ARCH="snb" +require conf/machine/include/tune-x86_64.inc MACHINE_FEATURES = "kernel26 screen keyboard pci usbhost ext2 ext3 x86 \ acpi serial usbgadget" @@ -42,6 +39,4 @@ GLIBC_EXTRA_OECONF = "--with-tls" MACHINE_ESSENTIAL_EXTRA_RDEPENDS = "grub" -TARGET_CC_ARCH = "-m64" - PREFERRED_VERSION_grub ?= "1.98" -- 1.7.4.1 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 2/2] meta-jasperforest: update machine configuration for recent tune file changes
Require the tune file for x86_64, then TARGET_ARCH and TARGET_CC_ARCH are set already. Also remove superfluous "xeon" package architecture that doesn't do anything. Signed-off-by: Paul Eggleton --- meta-jasperforest/conf/machine/jasperforest.conf |7 +-- 1 files changed, 1 insertions(+), 6 deletions(-) diff --git a/meta-jasperforest/conf/machine/jasperforest.conf b/meta-jasperforest/conf/machine/jasperforest.conf index 1d875b5..6be9502 100644 --- a/meta-jasperforest/conf/machine/jasperforest.conf +++ b/meta-jasperforest/conf/machine/jasperforest.conf @@ -4,10 +4,7 @@ #@DESCRIPTION: Machine configuration for Jasper Forest Picket Post # systems i.e. Xeon C5500/C3500 + Intel 3420 chipset (Ibex Peak) -TARGET_ARCH = "x86_64" -PACKAGE_EXTRA_ARCHS = "x86 xeon" - -BASE_PACKAGE_ARCH="xeon" +require conf/machine/include/tune-x86_64.inc MACHINE_FEATURES = "kernel26 screen keyboard pci usbhost ext2 ext3 x86 \ acpi serial usbgadget" @@ -41,5 +38,3 @@ GLIBC_EXTRA_OECONF = "--with-tls" MACHINE_ESSENTIAL_EXTRA_RDEPENDS = "grub" PREFERRED_VERSION_grub ?= "1.98" -TARGET_CC_ARCH = "-m64" - -- 1.7.4.1 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/2] meta-fri2: new layer for Fish River Island II (E6XX/EG20T) systems
On Wed, 2011-08-03 at 23:18 -0700, Darren Hart wrote: > Hi Tom, > > A few thoughts below. These are all things I can pick up once I return > as well if there is some urgency to get these in tree. > Hi Darren, Thanks for your comments. I've already pulled this in as I didn't think you'd be getting to it this week. Comments below... > -- > Darren > > On 08/02/2011 09:05 PM, tom.zanu...@intel.com wrote: > > From: Tom Zanussi > > > > This layer provides support for E6XX + EG20T Intel systems. > > > > Currently it supports only vesa graphics, which will be upgraded > > shortly. > > > > Signed-off-by: Tom Zanussi > > --- > > meta-fri2/COPYING.MIT | 17 > > meta-fri2/README | 83 > > > > meta-fri2/README.sources | 17 > > meta-fri2/conf/layer.conf | 10 +++ > > meta-fri2/conf/machine/fri2.conf | 36 + > > .../formfactor/formfactor/fri2/machconfig |3 + > > .../recipes-bsp/formfactor/formfactor_0.0.bbappend |3 + > > .../recipes-core/tasks/task-core-tools.bbappend|2 + > > .../xserver-xf86-config/fri2/xorg.conf | 26 ++ > > .../xorg-xserver/xserver-xf86-config_0.1.bbappend |3 + > > .../recipes-kernel/linux/linux-yocto_3.0.bbappend |6 ++ > > 11 files changed, 206 insertions(+), 0 deletions(-) > > create mode 100644 meta-fri2/COPYING.MIT > > create mode 100644 meta-fri2/README > > create mode 100644 meta-fri2/README.sources > > create mode 100644 meta-fri2/binary/.gitignore > > create mode 100644 meta-fri2/conf/layer.conf > > create mode 100644 meta-fri2/conf/machine/fri2.conf > > create mode 100644 > > meta-fri2/recipes-bsp/formfactor/formfactor/fri2/machconfig > > create mode 100644 meta-fri2/recipes-bsp/formfactor/formfactor_0.0.bbappend > > create mode 100644 meta-fri2/recipes-core/tasks/task-core-tools.bbappend > > create mode 100644 > > meta-fri2/recipes-graphics/xorg-xserver/xserver-xf86-config/fri2/xorg.conf > > create mode 100644 > > meta-fri2/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend > > create mode 100644 meta-fri2/recipes-kernel/linux/linux-yocto_3.0.bbappend > > > > diff --git a/meta-fri2/COPYING.MIT b/meta-fri2/COPYING.MIT > > new file mode 100644 > > index 000..fb950dc > > --- /dev/null > > +++ b/meta-fri2/COPYING.MIT > > @@ -0,0 +1,17 @@ > > +Permission is hereby granted, free of charge, to any person obtaining a > > copy > > +of this software and associated documentation files (the "Software"), to > > deal > > +in the Software without restriction, including without limitation the > > rights > > +to use, copy, modify, merge, publish, distribute, sublicense, and/or sell > > +copies of the Software, and to permit persons to whom the Software is > > +furnished to do so, subject to the following conditions: > > + > > +The above copyright notice and this permission notice shall be included in > > +all copies or substantial portions of the Software. > > + > > +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > > +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > > +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE > > +AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER > > +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > > FROM, > > +OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN > > +THE SOFTWARE. > > diff --git a/meta-fri2/README b/meta-fri2/README > > new file mode 100644 > > index 000..7957a7f > > --- /dev/null > > +++ b/meta-fri2/README > > @@ -0,0 +1,83 @@ > > +This README file contains information on building the meta-fri2 BSP > > +layer, and booting the images contained in the /binary directory. > > +Please see the corresponding sections below for details. > > + > > + > > +Table of Contents > > += > > + > > + I. Special notes on the meta-fri2 BSP layer > > + II. Building the meta-fri2 BSP layer > > +III. Booting the images in /binary > > + > > + > > +II. Building the meta-fri2 BSP layer > > += > > + > > +In order to build an image with BSP support for a given release, you > > +need to download the corresponding BSP tarball from the 'Board Support > > +Package (BSP) Downloads' page of the Yocto Project website. > > + > > +Having done that, and assuming you extracted the BSP tarball contents > > +at the top-level of your yocto build tree, you can build a fri2 image > > +by adding the location of the meta-fri2 layer to bblayers.conf e.g.: > > + > > + yocto/meta-intel/meta-fri2 \ > > + > > +To enable the fri2 layer, add the fri2 MACHINE to local.conf: > > + > > + MACHINE ?= "fri2" > > + > > +You should then be able to build a fri2 image as such: > > + > > + $ source poky-init-build-env > > + $ bitbake pok
[yocto] prebuilt pacakages
Is there any way to make Yocto try to get prebuilt packages from known repositories rather than trying to rebuild the world? -Todd ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] examples / docs on utilizing an external toolchain
On Wed, 2011-08-03 at 23:59 -0500, Kumar Gala wrote: > On Aug 3, 2011, at 10:12 AM, Richard Purdie wrote: > > > On Wed, 2011-08-03 at 09:50 -0500, Kumar Gala wrote: > >> On Aug 3, 2011, at 9:22 AM, Richard Purdie wrote: > >> > >>> On Wed, 2011-08-03 at 09:04 -0500, Kumar Gala wrote: > Bug submitted: > > http://bugzilla.pokylinux.org/show_bug.cgi?id=1323 > > My question still stands even w/o it being in formal docs. > >>> > >>> FWIW, POKYMODE was replaced by TCMODE as part of the OE-Core changes. > >>> I'd be interested to know where we've missed the references to it and > >>> get to get those references fixed. > >> > >> Ok, but how does one use TCMODE? :) > >> > >> is there an example around anywhere? > > > > I'll explain on the condition that someone actually documents this ;-). > > > > TCMODE determines which of the files in > > meta/conf/distro/include/tcmode-* is used. It defaults to "default" and > > our default toolchain definition is in tcmode-default.inc. > > > > There is another example there which is "external-csl2008q3". As you can > > see from the tcmode-external-csl2008q3 file, it sets up the system to > > use an external toolchain instead. > > > > So you can define one of these files in your layer and then the system > > can select alternative toolchain configurations. > > > > Does that help? :) > > > > There is a similar TCLIBC variable which controls which libc is used > > (eglibc or uclibc). > > Yes that helps. So it looks as if today there is not a means to point > to SDK prebuilt toolchain via this means. We have supported this in the past but it got messy and I'd really prefer people to use sstate for this. You obviously can use the SDK toolchain as a prebuilt external toolchain though since its no different from any other external toolchain. Cheers, Richard ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] examples / docs on utilizing an external toolchain
On Wed, 2011-08-03 at 23:59 -0500, Kumar Gala wrote: > On Aug 3, 2011, at 10:12 AM, Richard Purdie wrote: > > > On Wed, 2011-08-03 at 09:50 -0500, Kumar Gala wrote: > >> On Aug 3, 2011, at 9:22 AM, Richard Purdie wrote: > >> > >>> On Wed, 2011-08-03 at 09:04 -0500, Kumar Gala wrote: > Bug submitted: > > http://bugzilla.pokylinux.org/show_bug.cgi?id=1323 > > My question still stands even w/o it being in formal docs. > >>> > >>> FWIW, POKYMODE was replaced by TCMODE as part of the OE-Core changes. > >>> I'd be interested to know where we've missed the references to it and > >>> get to get those references fixed. > >> > >> Ok, but how does one use TCMODE? :) > >> > >> is there an example around anywhere? > > > > I'll explain on the condition that someone actually documents this ;-). > > > > TCMODE determines which of the files in > > meta/conf/distro/include/tcmode-* is used. It defaults to "default" and > > our default toolchain definition is in tcmode-default.inc. > > > > There is another example there which is "external-csl2008q3". As you can > > see from the tcmode-external-csl2008q3 file, it sets up the system to > > use an external toolchain instead. > > > > So you can define one of these files in your layer and then the system > > can select alternative toolchain configurations. > > > > Does that help? :) > > > > There is a similar TCLIBC variable which controls which libc is used > > (eglibc or uclibc). > > Yes that helps. So it looks as if today there is not a means to point > to SDK prebuilt toolchain via this means. We have supported this in the past but it got messy and I'd really prefer people to use sstate for this. You obviously can use the SDK toolchain as a prebuilt external toolchain though since its no different from any other external toolchain. Cheers, Richard ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto post 1.1 development focus areas?
[Cross posted but please reply on the Yocto list] We're starting to think about the development focus for post Yocto 1.1 and are collecting ideas on the unscheduled feature list on the wiki: https://wiki.yoctoproject.org/wiki/Yocto_Project_Unscheduled_Feature_List This is an opportunity for people to mention all the "if only we had X functionality" ideas they might think of as they use the system. Obviously there are no promises anything listed will get worked on but if its not there, the likelihood of it not happening is significantly higher :) Cheers, Richard ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] examples / docs on utilizing an external toolchain
On 2011-08-04 08:49, Richard Purdie wrote: On Wed, 2011-08-03 at 23:59 -0500, Kumar Gala wrote: On Aug 3, 2011, at 10:12 AM, Richard Purdie wrote: On Wed, 2011-08-03 at 09:50 -0500, Kumar Gala wrote: On Aug 3, 2011, at 9:22 AM, Richard Purdie wrote: On Wed, 2011-08-03 at 09:04 -0500, Kumar Gala wrote: Bug submitted: http://bugzilla.pokylinux.org/show_bug.cgi?id=1323 My question still stands even w/o it being in formal docs. FWIW, POKYMODE was replaced by TCMODE as part of the OE-Core changes. I'd be interested to know where we've missed the references to it and get to get those references fixed. Ok, but how does one use TCMODE? :) is there an example around anywhere? I'll explain on the condition that someone actually documents this ;-). TCMODE determines which of the files in meta/conf/distro/include/tcmode-* is used. It defaults to "default" and our default toolchain definition is in tcmode-default.inc. There is another example there which is "external-csl2008q3". As you can see from the tcmode-external-csl2008q3 file, it sets up the system to use an external toolchain instead. So you can define one of these files in your layer and then the system can select alternative toolchain configurations. Does that help? :) There is a similar TCLIBC variable which controls which libc is used (eglibc or uclibc). Yes that helps. So it looks as if today there is not a means to point to SDK prebuilt toolchain via this means. We have supported this in the past but it got messy and I'd really prefer people to use sstate for this. That would be great, if only it worked for this purpose. Sadly, I've not had much luck with sharing toolchains like this. Here's my problem - I have a number of different target platforms (MACHINE), all of which are really the same ARM SoC (OMAP/3530==armv7a). When I try to share the sstate between them, the toolchain always rebuilds from scratch. A lot of other packages do seem to share state properly, e.g. busybox built for these platforms uses sstate well, but not so with toolchains. Is there any way for this to work? I'd love to be able to hand my customers a set of sstate files for the things they don't really need to rebuild and the toolchains are a giant part of it. If this should work and the current failures a bug, I'll report it as such. Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] prebuilt pacakages
On Thu, 2011-08-04 at 07:42 -0700, Todd Cooper wrote: > Is there any way to make Yocto try to get prebuilt packages from known > repositories rather than trying to rebuild the world? The system supports a cache of prebuilt objects in the form of the sstate data to accelerate build times if nothing changes. It doesn't directly support using prebuilt packages directly though as its a much harder problem to solve than you first realise. A an example, given a package feed, its very hard to work out library provision within that package feed or dependency naming. Cheers, Richard ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] examples / docs on utilizing an external toolchain
On Thursday, August 04, 2011 08:58:59 AM Gary Thomas wrote: > On 2011-08-04 08:49, Richard Purdie wrote: > > On Wed, 2011-08-03 at 23:59 -0500, Kumar Gala wrote: > >> On Aug 3, 2011, at 10:12 AM, Richard Purdie wrote: > >>> On Wed, 2011-08-03 at 09:50 -0500, Kumar Gala wrote: > On Aug 3, 2011, at 9:22 AM, Richard Purdie wrote: > > On Wed, 2011-08-03 at 09:04 -0500, Kumar Gala wrote: > >> Bug submitted: > >> > >> http://bugzilla.pokylinux.org/show_bug.cgi?id=1323 > >> > >> My question still stands even w/o it being in formal docs. > > > > FWIW, POKYMODE was replaced by TCMODE as part of the OE-Core > > changes. > > I'd be interested to know where we've missed the references to > > it and > > get to get those references fixed. > > Ok, but how does one use TCMODE? :) > > is there an example around anywhere? > >>> > >>> I'll explain on the condition that someone actually documents this > >>> ;-). > >>> > >>> TCMODE determines which of the files in > >>> meta/conf/distro/include/tcmode-* is used. It defaults to "default" > >>> and > >>> our default toolchain definition is in tcmode-default.inc. > >>> > >>> There is another example there which is "external-csl2008q3". As you > >>> can see from the tcmode-external-csl2008q3 file, it sets up the > >>> system to use an external toolchain instead. > >>> > >>> So you can define one of these files in your layer and then the > >>> system > >>> can select alternative toolchain configurations. > >>> > >>> Does that help? :) > >>> > >>> There is a similar TCLIBC variable which controls which libc is used > >>> (eglibc or uclibc). > >> > >> Yes that helps. So it looks as if today there is not a means to point > >> to SDK prebuilt toolchain via this means. > > > > We have supported this in the past but it got messy and I'd really > > prefer people to use sstate for this. > > That would be great, if only it worked for this purpose. Sadly, I've not > had much luck with sharing toolchains like this. > > Here's my problem - I have a number of different target platforms (MACHINE), > all of which are really the same ARM SoC (OMAP/3530==armv7a). When I try > to share the sstate between them, the toolchain always rebuilds from > scratch. can you post bitbake -e of say gcc-cross gcc-runtime and eglibc for both machines ? We somehow need to figure what changes the signatures > A lot of other packages do seem to share state properly, e.g. > busybox built for these platforms uses sstate well, but not so with > toolchains. > > Is there any way for this to work? I'd love to be able to hand my customers > a set of sstate files for the things they don't really need to rebuild and > the toolchains are a giant part of it. If this should work and the current > failures a bug, I'll report it as such. > > Thanks -- Khem Raj ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] examples / docs on utilizing an external toolchain
On Thu, Aug 4, 2011 at 8:06 AM, Khem Raj wrote: > On Thursday, August 04, 2011 08:58:59 AM Gary Thomas wrote: >> On 2011-08-04 08:49, Richard Purdie wrote: >> > On Wed, 2011-08-03 at 23:59 -0500, Kumar Gala wrote: >> >> On Aug 3, 2011, at 10:12 AM, Richard Purdie wrote: >> >>> On Wed, 2011-08-03 at 09:50 -0500, Kumar Gala wrote: >> On Aug 3, 2011, at 9:22 AM, Richard Purdie wrote: >> > On Wed, 2011-08-03 at 09:04 -0500, Kumar Gala wrote: >> >> Bug submitted: >> >> >> >> http://bugzilla.pokylinux.org/show_bug.cgi?id=1323 >> >> >> >> My question still stands even w/o it being in formal docs. >> > >> > FWIW, POKYMODE was replaced by TCMODE as part of the OE-Core >> > changes. >> > I'd be interested to know where we've missed the references to >> > it and >> > get to get those references fixed. >> >> Ok, but how does one use TCMODE? :) >> >> is there an example around anywhere? >> >>> >> >>> I'll explain on the condition that someone actually documents this >> >>> ;-). >> >>> >> >>> TCMODE determines which of the files in >> >>> meta/conf/distro/include/tcmode-* is used. It defaults to "default" >> >>> and >> >>> our default toolchain definition is in tcmode-default.inc. >> >>> >> >>> There is another example there which is "external-csl2008q3". As you >> >>> can see from the tcmode-external-csl2008q3 file, it sets up the >> >>> system to use an external toolchain instead. >> >>> >> >>> So you can define one of these files in your layer and then the >> >>> system >> >>> can select alternative toolchain configurations. >> >>> >> >>> Does that help? :) >> >>> >> >>> There is a similar TCLIBC variable which controls which libc is used >> >>> (eglibc or uclibc). >> >> >> >> Yes that helps. So it looks as if today there is not a means to point >> >> to SDK prebuilt toolchain via this means. >> > >> > We have supported this in the past but it got messy and I'd really >> > prefer people to use sstate for this. >> >> That would be great, if only it worked for this purpose. Sadly, I've not >> had much luck with sharing toolchains like this. >> >> Here's my problem - I have a number of different target platforms (MACHINE), >> all of which are really the same ARM SoC (OMAP/3530==armv7a). When I try >> to share the sstate between them, the toolchain always rebuilds from >> scratch. > > can you post bitbake -e of say gcc-cross gcc-runtime and eglibc > for both machines ? We somehow need to figure what changes the signatures No need to use bitbake -e, just use bitbake-diffsigs. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] examples / docs on utilizing an external toolchain
On 2011-08-04 09:29, Chris Larson wrote: On Thu, Aug 4, 2011 at 8:06 AM, Khem Raj wrote: On Thursday, August 04, 2011 08:58:59 AM Gary Thomas wrote: On 2011-08-04 08:49, Richard Purdie wrote: On Wed, 2011-08-03 at 23:59 -0500, Kumar Gala wrote: On Aug 3, 2011, at 10:12 AM, Richard Purdie wrote: On Wed, 2011-08-03 at 09:50 -0500, Kumar Gala wrote: On Aug 3, 2011, at 9:22 AM, Richard Purdie wrote: On Wed, 2011-08-03 at 09:04 -0500, Kumar Gala wrote: Bug submitted: http://bugzilla.pokylinux.org/show_bug.cgi?id=1323 My question still stands even w/o it being in formal docs. FWIW, POKYMODE was replaced by TCMODE as part of the OE-Core changes. I'd be interested to know where we've missed the references to it and get to get those references fixed. Ok, but how does one use TCMODE? :) is there an example around anywhere? I'll explain on the condition that someone actually documents this ;-). TCMODE determines which of the files in meta/conf/distro/include/tcmode-* is used. It defaults to "default" and our default toolchain definition is in tcmode-default.inc. There is another example there which is "external-csl2008q3". As you can see from the tcmode-external-csl2008q3 file, it sets up the system to use an external toolchain instead. So you can define one of these files in your layer and then the system can select alternative toolchain configurations. Does that help? :) There is a similar TCLIBC variable which controls which libc is used (eglibc or uclibc). Yes that helps. So it looks as if today there is not a means to point to SDK prebuilt toolchain via this means. We have supported this in the past but it got messy and I'd really prefer people to use sstate for this. That would be great, if only it worked for this purpose. Sadly, I've not had much luck with sharing toolchains like this. Here's my problem - I have a number of different target platforms (MACHINE), all of which are really the same ARM SoC (OMAP/3530==armv7a). When I try to share the sstate between them, the toolchain always rebuilds from scratch. can you post bitbake -e of say gcc-cross gcc-runtime and eglibc for both machines ? We somehow need to figure what changes the signatures No need to use bitbake -e, just use bitbake-diffsigs. How do I use this? -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/2] [meta-intel] Fix meta-intel BSPs for tune file changes v2
On Thu, 2011-08-04 at 07:04 -0700, Paul Eggleton wrote: > Two patches to fix "TUNE_ARCH unset" and "PACKAGE_ARCHS variable does not > contain TUNE_PKGARCH" on the autobuilder for sugarbay and jasperforest. > > Since v1, after discussion with Richard remove additional package > architectures that aren't apparently doing anything. > Hi Paul, Thanks. These are exactly the same changes I made and tested earlier in the week but that failed then with kernel oopes. Things have changed for the better since then and I was now able to build and boot the jasperforest BSP with your changes. I'm assuming the sugarbay will show the same thing. So I've pulled your patches into master, thanks. Acked-by: Tom Zanussi meta-jasperforest changes Tested-by: Tom Zanussi > The following changes since commit 567c3b6436b4cb9551c23845c15ab544542b5083: > > meta-crownbay: remove obsolete dir (2011-08-03 12:14:39 -0500) > > are available in the git repository at: > git://git.yoctoproject.org/meta-intel-contrib paule/tune > http://git.yoctoproject.org/cgit.cgi/meta-intel-contrib/log/?h=paule/tune > > Paul Eggleton (2): > meta-sugarbay: update machine configuration for recent tune file > changes > meta-jasperforest: update machine configuration for recent tune file > changes > > meta-jasperforest/conf/machine/jasperforest.conf |7 +-- > meta-sugarbay/conf/machine/sugarbay.conf |7 +-- > 2 files changed, 2 insertions(+), 12 deletions(-) > ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] examples / docs on utilizing an external toolchain
On Thu, Aug 4, 2011 at 10:34 AM, Gary Thomas wrote: > How do I use this? There seems to be a blurb here: https://wiki.yoctoproject.org/wiki/Enable_sstate_cache -M ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 2/2] meta-jasperforest: add live fstype
From: Tom Zanussi Most of the time, we want a -live image, so add it to the IMAGE_FSTYPES by default. Signed-off-by: Tom Zanussi --- meta-jasperforest/conf/machine/jasperforest.conf |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/meta-jasperforest/conf/machine/jasperforest.conf b/meta-jasperforest/conf/machine/jasperforest.conf index 6be9502..89626da 100644 --- a/meta-jasperforest/conf/machine/jasperforest.conf +++ b/meta-jasperforest/conf/machine/jasperforest.conf @@ -30,7 +30,7 @@ SERIAL_CONSOLE = "115200 ttyS0" MACHINE_EXTRA_RRECOMMENDS = "kernel-modules eee-acpi-scripts" -IMAGE_FSTYPES ?= "ext3 cpio.gz" +IMAGE_FSTYPES ?= "ext3 cpio.gz live" GLIBC_ADDONS = "nptl" GLIBC_EXTRA_OECONF = "--with-tls" -- 1.7.0.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 0/2] meta-intel: sugarbay, jasperforest updates
From: Tom Zanussi A couple updates for meta-sugarbay and meta-jasperforest dealing with the new live image changes. Boot tested successfully with the jasperforest live minimal image. The following changes since commit c5f2339533ec9daf14e00db67fa75ed89bbdda13: Paul Eggleton (1): meta-jasperforest: update machine configuration for recent tune file changes are available in the git repository at: git://git.yoctoproject.org/meta-intel.git tzanussi/sugarbay-jasperforest-live-changes http://git.yoctoproject.org/cgit.cgi//log/?h=tzanussi/sugarbay-jasperforest-live-changes Tom Zanussi (2): meta-sugarbay: add live fstype meta-jasperforest: add live fstype meta-jasperforest/conf/machine/jasperforest.conf |2 +- meta-sugarbay/conf/machine/sugarbay.conf |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/2] meta-sugarbay: add live fstype
From: Tom Zanussi Most of the time, we want a -live image, so add it to the IMAGE_FSTYPES by default. Signed-off-by: Tom Zanussi --- meta-sugarbay/conf/machine/sugarbay.conf |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/meta-sugarbay/conf/machine/sugarbay.conf b/meta-sugarbay/conf/machine/sugarbay.conf index 2a47dee..0d1ab06 100644 --- a/meta-sugarbay/conf/machine/sugarbay.conf +++ b/meta-sugarbay/conf/machine/sugarbay.conf @@ -32,7 +32,7 @@ SERIAL_CONSOLE = "115200 ttyS0" MACHINE_EXTRA_RRECOMMENDS = "kernel-modules eee-acpi-scripts" -IMAGE_FSTYPES ?= "ext3 cpio.gz" +IMAGE_FSTYPES ?= "ext3 cpio.gz live" GLIBC_ADDONS = "nptl" GLIBC_EXTRA_OECONF = "--with-tls" -- 1.7.0.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build failure on recent yocto download
On Wed, 2011-08-03 at 20:21 -0700, Tim Bird wrote: > On 8/3/2011 5:50 PM, Joshua Lock wrote: > > On Wed, 2011-08-03 at 17:40 -0700, Joshua Lock wrote: > >> On Wed, 2011-08-03 at 17:08 -0700, Tim Bird wrote: > >>> Hi all, > >>> > >>> I'm not sure where to report this, but I tried again to build > >>> Yocto, without success. > >>> > >>> I downloaded poky-bernard-4.0.tar.bz2, and followed instructions > >>> for installing it. > >>> > >>> I am using 'MACHINE ?= qemuarm' and doing 'bitbake poky-image-sato' > >>> > >>> bitbake error messages follow below. > >>> > >>> The first error is a failure to fetch the kernel, and a follow-on > >>> failure to do a git-clone on the kernel. I'm behind a firewall and > >>> this is a perennial problem for me. Is there another way to get this > >>> code? If I do a git-clone on a remote machine and copy it over to > >>> my development host, where do I put it? (Why did the first http-based > >>> fetch fail, anyway?) Any help would be appreciated. > >> We seem to be missing the kernel tarball on our sources mirror... Let me > >> try and chase that. > > Chased and caught: > > > > joshual@scimitar:~/mess/31 > > $ wget > > http://autobuilder.yoctoproject.org/sources/git2_git.pokylinux.org.linux-yocto-2.6.37.tar.gz > > --2011-08-03 17:50:18-- > > http://autobuilder.yoctoproject.org/sources/git2_git.pokylinux.org.linux-yocto-2.6.37.tar.gz > > Resolving autobuilder.yoctoproject.org... 140.211.169.118 > > Connecting to autobuilder.yoctoproject.org|140.211.169.118|:80... > > connected. > > HTTP request sent, awaiting response... 200 OK > > Length: 449232265 (428M) [application/x-gzip] > > Saving to: `git2_git.pokylinux.org.linux-yocto-2.6.37.tar.gz.1' > Thanks very much. I'll give it another try. > > I've visited the "behind a proxy" help page before. I guess I should > have checked that for an update before asking. > -- Tim We don't mind people asking :-) Let us know how you get on! Joshua -- Joshua Lock Yocto Project "Johannes factotum" Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] prebuilt pacakages
Would this be worth putting on the list of items wished for in the future? It sounds like the problem is difficult, but not impossible. > >From: Richard Purdie >To: Todd Cooper >Cc: "yocto@yoctoproject.org" >Sent: Thursday, August 4, 2011 10:59 AM >Subject: Re: [yocto] prebuilt pacakages > >On Thu, 2011-08-04 at 07:42 -0700, Todd Cooper wrote: >> Is there any way to make Yocto try to get prebuilt packages from known >> repositories rather than trying to rebuild the world? > >The system supports a cache of prebuilt objects in the form of the >sstate data to accelerate build times if nothing changes. It doesn't >directly support using prebuilt packages directly though as its a much >harder problem to solve than you first realise. > >A an example, given a package feed, its very hard to work out library >provision within that package feed or dependency naming. > >Cheers, > >Richard > > > > > > >___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build failure on recent yocto download
On 08/03/2011 06:44 PM, Khem Raj wrote: > On Wednesday, August 03, 2011 05:08:43 PM Tim Bird wrote: >> | from cairo-scaled-font-private.h:45, >> | from cairoint.h:380, >> | >> | from cairo-arc.c:37: >> | cairo-mutex-impl-private.h:262:3: error: #error "XXX: No mutex >> | implementation found. Cairo will not work with multiple >> | threads. Define CAIRO_NO_MUTEX to 1 to acknowledge and accept this >> | limitation >> and compile cairo without thread-safety support." >> >> | In file included from cairo-mutex-type-private.h:45:0, >> | >> | from cairo-scaled-font-private.h:45, >> | from cairoint.h:380, >> | >> | from cairo-arc.c:37: >> | cairo-mutex-impl-private.h:271:30: error: expected '=', ',', ';', 'asm' >> | or '__attribute__' before 'cairo_recursive_mutex_impl_t' In file >> | included from cairo-scaled-font-private.h:45:0, >> | >> | from cairoint.h:380, >> | >> | from cairo-arc.c:37: >> | cairo-mutex-type-private.h:49:3: error: #error "CAIRO_MUTEX_IMPL_LOCK >> | not defined. Check cairo-mutex-impl-private.h." >> | cairo-mutex-type-private.h:52:3: error: #error "CAIRO_MUTEX_IMPL_UNLOCK >> | not defined. Check cairo-mutex-impl-private.h." >> | cairo-mutex-type-private.h:55:3: error: #error >> | "CAIRO_MUTEX_IMPL_NIL_INITIALIZER not defined. Check >> | cairo-mutex-impl-private.h." cairo-mutex-type-private.h:139:3: error: >> | #error "CAIRO_MUTEX_IMPL_LOCK not defined" >> | cairo-mutex-type-private.h:142:3: error: #error >> | "CAIRO_MUTEX_IMPL_UNLOCK not defined" cairo-mutex-type-private.h:151:3: >> | error: #error "CAIRO_MUTEX_IMPL_NIL_INITIALIZER not defined" >> | cairo-mutex-type-private.h:161:28: error: expected '=', ',', ';', 'asm' >> | or '__attribute__' before 'cairo_mutex_t' >> | cairo-mutex-type-private.h:162:38: error: expected '=', ',', ';', 'asm' >> | or '__attribute__' before 'cairo_recursive_mutex_t' In file included >> | from cairoint.h:380:0, >> | >> | from cairo-arc.c:37: >> | cairo-scaled-font-private.h:108:5: error: expected >> | specifier-qualifier-list before 'cairo_mutex_t' In file included from >> | cairo-mutex-type-private.h:45:0, >> | >> | from cairo-scaled-font-private.h:45, >> | from cairoint.h:380, >> | >> | from cairo-base64-stream.c:39: >> | cairo-mutex-impl-private.h:262:3: error: #error "XXX: No mutex >> | implementation found. Cairo will not work with multiple >> | threads. Define CAIRO_NO_MUTEX to 1 to acknowledge and accept this >> | limitation >> and compile cairo without thread-safety support." > > hmmm this error means you dont have libc headers installed properly. > Seems something is broken in your environment. Its probably using some tools > from your build system which are not quite in line with what configure wanted > Can you post the config.log of cairo somewhere ? OK. I tried it all again, this time with Yocto 5.0.1, and I get the same cairo build error. I found the config log for this in: poky-5.0.1.build/tmp/work/armv5te-poky-linux-gnueabi/cairo-1.10.2-r0/temp log.do_configure. I pasted it at: http://pastebin.com/z0QqgVaE The only thing that looks suspicious to me is: ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded: ignored. I don't know anything about how libpseudo.so is used, so I don't know if this is a big problem or not (but I fear host tool or lib contamination if Pseudo is not being used correctly. There's also this inability to link with pthread. > checking for cairo's pthread feature... > checking whether cairo's pthread feature could be enabled... no (can't link > with -lpthread or -pthread) That sounds like it might be related to a missing mutex compile problem. ?? And this line from the compile output seems to be the start of the problem: | cairo-mutex-impl-private.h:262:3: error: #error "XXX: No mutex implementation found. Cairo will not work with multiple threads. Define CAIRO_NO_MUTEX to 1 to acknowledge and accept this limitation and compile cairo without thread-safety support." How would I define CAIRO_NO_MUTEX, and rebuild, to check this out? Once again, I'm running this on Fedora 12, 64-bit system. (But I would have expected any lib dependencies and configure to have been sandboxed from the host libs and environment). Thanks for any help. -- Tim = Tim Bird Architecture Group Chair, CE Workgroup of the Linux Foundation Senior Staff Engineer, Sony Network Entertainment = ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto post 1.1 development focus areas?
On Thu, 2011-08-04 at 15:54 +0100, Richard Purdie wrote: > [Cross posted but please reply on the Yocto list] > > We're starting to think about the development focus for post Yocto 1.1 > and are collecting ideas on the unscheduled feature list on the wiki: > > https://wiki.yoctoproject.org/wiki/Yocto_Project_Unscheduled_Feature_List > > This is an opportunity for people to mention all the "if only we had X > functionality" ideas they might think of as they use the system. Is the intention to collect features on this thread or for people to add them to the wiki? It'd be great to finish up the swabber (host-intrusion detection) work and have that integrated into our autobuilder cycle. I have more but I'll wait to learn if you want them on-list or on-wiki. :-) Cheers, Joshua -- Joshua Lock Yocto Project "Johannes Factotum" Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build failure on recent yocto download
On Thu, 2011-08-04 at 11:51 -0700, Tim Bird wrote: > The only thing that looks suspicious to me is: > > ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded: > ignored. This is concerning and may cause problems later on. One possible factor here is SELINUX. Do you have that enabled? We've tried to ensure the system works with SELINUX but the policay may vary quite a bit from Fedora 12 to 14 (where I know a build with SELINUX has run). > I don't know anything about how libpseudo.so is used, so I don't know if this > is > a big problem or not (but I fear host tool or lib contamination if Pseudo is > not > being used correctly. Pseudo is akin to fakeroot, so it allows us to set appropriate permissions for the generated image without requiring root privileges on the build machine. > Once again, I'm running this on Fedora 12, 64-bit system. (But I would have > expected any lib dependencies and configure > to have been sandboxed from the host libs and environment). That is how we intend to operate but I know we have had issues with host contamination in the past and may well again in the future. We have the beginnings of some machinery in place to catch these issues earlier, however. Regards, Joshua -- Joshua Lock Yocto Project "Johannes Factotum" Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] examples / docs on utilizing an external toolchain
On 2011-08-04 09:06, Khem Raj wrote: On Thursday, August 04, 2011 08:58:59 AM Gary Thomas wrote: On 2011-08-04 08:49, Richard Purdie wrote: On Wed, 2011-08-03 at 23:59 -0500, Kumar Gala wrote: On Aug 3, 2011, at 10:12 AM, Richard Purdie wrote: On Wed, 2011-08-03 at 09:50 -0500, Kumar Gala wrote: On Aug 3, 2011, at 9:22 AM, Richard Purdie wrote: On Wed, 2011-08-03 at 09:04 -0500, Kumar Gala wrote: Bug submitted: http://bugzilla.pokylinux.org/show_bug.cgi?id=1323 My question still stands even w/o it being in formal docs. FWIW, POKYMODE was replaced by TCMODE as part of the OE-Core changes. I'd be interested to know where we've missed the references to it and get to get those references fixed. Ok, but how does one use TCMODE? :) is there an example around anywhere? I'll explain on the condition that someone actually documents this ;-). TCMODE determines which of the files in meta/conf/distro/include/tcmode-* is used. It defaults to "default" and our default toolchain definition is in tcmode-default.inc. There is another example there which is "external-csl2008q3". As you can see from the tcmode-external-csl2008q3 file, it sets up the system to use an external toolchain instead. So you can define one of these files in your layer and then the system can select alternative toolchain configurations. Does that help? :) There is a similar TCLIBC variable which controls which libc is used (eglibc or uclibc). Yes that helps. So it looks as if today there is not a means to point to SDK prebuilt toolchain via this means. We have supported this in the past but it got messy and I'd really prefer people to use sstate for this. That would be great, if only it worked for this purpose. Sadly, I've not had much luck with sharing toolchains like this. Here's my problem - I have a number of different target platforms (MACHINE), all of which are really the same ARM SoC (OMAP/3530==armv7a). When I try to share the sstate between them, the toolchain always rebuilds from scratch. can you post bitbake -e of say gcc-cross gcc-runtime and eglibc for both machines ? We somehow need to figure what changes the signatures A lot of other packages do seem to share state properly, e.g. busybox built for these platforms uses sstate well, but not so with toolchains. Is there any way for this to work? I'd love to be able to hand my customers a set of sstate files for the things they don't really need to rebuild and the toolchains are a giant part of it. If this should work and the current failures a bug, I'll report it as such. Thanks This turns out (in my case) to be a sensitivity to $DISTRO_FEATURES One of my builds had slightly different value, but not such that it actually changed any packages (it had an unused key). I tried this with two machines, identical except in the name, with machineB sharing state with machineB. The only packages which had to be rebuilt were the target specific ones, e.g. the machine kernel. If I touch DISTRO_FEATURES in the build for machineB though, the number of packages rebuilt skyrockets (list attached). For now, I'll make sure that DISTRO_FEATURES is not something that my builds touch. -- Gary Thomas | Consulting for the MLB Associates |Embedded world sstate-cache/sstate-acl-armv5te-amltd-linux-gnueabi-2.2.51-r1-armv5te-2-6b8cc98b10370be238413867a3f5522e_package.tgz sstate-cache/sstate-attr-armv5te-amltd-linux-gnueabi-2.4.46-r1-armv5te-2-d0b5730e91b3ef9952c13ef9e075fd19_package.tgz sstate-cache/sstate-base-passwd-armv5te-amltd-linux-gnueabi-3.5.22-r3-armv5te-2-84996e9837490d84a916f90e5c8f05e8_package.tgz sstate-cache/sstate-bash-armv5te-amltd-linux-gnueabi-4.1-r2-armv5te-2-a02ca1ba1fc49785d57840fb885b7f93_package.tgz sstate-cache/sstate-bison-armv5te-amltd-linux-gnueabi-2.5-r0-armv5te-2-7c62d5c1ef24ff60a3f9075686dea68b_package.tgz sstate-cache/sstate-busybox-armv5te-amltd-linux-gnueabi-1.18.4-r7.1-armv5te-2-b795c99d6c5fa2a552b497e989fd4064_package.tgz sstate-cache/sstate-bzip2-armv5te-amltd-linux-gnueabi-1.0.6-r3-armv5te-2-6698349244d671c825c132e7f7f8b4ef_package.tgz sstate-cache/sstate-dbus-armv5te-amltd-linux-gnueabi-1.4.12-r0-armv5te-2-ed94dafaac16d14bdcbd32af8d718473_package.tgz sstate-cache/sstate-dropbear-armv5te-amltd-linux-gnueabi-0.52-r2-armv5te-2-6f2d63ee1b120cc18b5c90771898e496_package.tgz sstate-cache/sstate-e2fsprogs-armv5te-amltd-linux-gnueabi-1.41.14-r1-armv5te-2-07f2879846fa80fa7afdc4b102b58858_package.tgz sstate-cache/sstate-eglibc-armv5te-amltd-linux-gnueabi-2.13-r8+svnr14157-armv5te-2-9537d4b964a485fb6daec8e3cb116220_package.tgz sstate-cache/sstate-eglibc-initial-armv5te-amltd-linux-gnueabi-2.13-r8+svnr14157-armv5te-2-85ce5c36a4b5ac4d0b6db6d01d1b2604_package.tgz sstate-cache/sstate-eglibc-locale-armv5te-amltd-linux-gnueabi-2.13-r16-armv5te-2-113b7e47e1e28245255bc7bb02b06faa_package.tgz ssta
Re: [yocto] Yocto post 1.1 development focus areas?
On Thu, 2011-08-04 at 12:45 -0700, Joshua Lock wrote: > On Thu, 2011-08-04 at 15:54 +0100, Richard Purdie wrote: > > [Cross posted but please reply on the Yocto list] > > > > We're starting to think about the development focus for post Yocto 1.1 > > and are collecting ideas on the unscheduled feature list on the wiki: > > > > https://wiki.yoctoproject.org/wiki/Yocto_Project_Unscheduled_Feature_List > > > > This is an opportunity for people to mention all the "if only we had X > > functionality" ideas they might think of as they use the system. > > Is the intention to collect features on this thread or for people to add > them to the wiki? > > It'd be great to finish up the swabber (host-intrusion detection) work > and have that integrated into our autobuilder cycle. > > I have more but I'll wait to learn if you want them on-list or > on-wiki. :-) Wiki please... Cheers, Richard ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] prebuilt pacakages
On Thu, 2011-08-04 at 10:50 -0700, Todd Cooper wrote: > Would this be worth putting on the list of items wished for in the > future? > > It sounds like the problem is difficult, but not impossible. Most things are possible :). The implementation isn't hard, maintaining some kind of translation table for the dependencies, shared library provision lists and so on is a *lot* of work though. It would really take someone with a specific use case to step forward along with manpower for it to have a chance of happening. Even then it would work for a specific set of packages and wouldn't translate to any other package feed. Cheers, Richard > > > __ > From: Richard Purdie > To: Todd Cooper > Cc: "yocto@yoctoproject.org" > Sent: Thursday, August 4, 2011 10:59 AM > Subject: Re: [yocto] prebuilt pacakages > > On Thu, 2011-08-04 at 07:42 -0700, Todd Cooper wrote: > > Is there any way to make Yocto try to get prebuilt packages > from known > > repositories rather than trying to rebuild the world? > > The system supports a cache of prebuilt objects in the form of > the > sstate data to accelerate build times if nothing changes. It > doesn't > directly support using prebuilt packages directly though as > its a much > harder problem to solve than you first realise. > > A an example, given a package feed, its very hard to work out > library > provision within that package feed or dependency naming. > > Cheers, > > Richard > > > > > > > > ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto post 1.1 development focus areas?
On 08/04/2011 12:45 PM, Joshua Lock wrote: On Thu, 2011-08-04 at 15:54 +0100, Richard Purdie wrote: [Cross posted but please reply on the Yocto list] We're starting to think about the development focus for post Yocto 1.1 and are collecting ideas on the unscheduled feature list on the wiki: https://wiki.yoctoproject.org/wiki/Yocto_Project_Unscheduled_Feature_List My good browser presented me with ssl error that "The site's security certificate is not trusted!" :) I would like to add a taks to curb bitbake memory consumption Thanks -Khem ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build failure on recent yocto download
On 08/04/2011 01:22 PM, Joshua Lock wrote: > On Thu, 2011-08-04 at 11:51 -0700, Tim Bird wrote: >> The only thing that looks suspicious to me is: >> >> ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded: >> ignored. > > This is concerning and may cause problems later on. One possible factor > here is SELINUX. Do you have that enabled? We've tried to ensure the > system works with SELINUX but the policay may vary quite a bit from > Fedora 12 to 14 (where I know a build with SELINUX has run). I'm not running SELinux. Another developer doing a build of 5.0.1 on an Ubuntu 11.04 platform had no problem with the cairo build, so I'm going to guess it's my distro. I changed to building poky-image-minimal (GUI is not needed for what I'm doing at the moment), and it built, successfully, in about 30 seconds. 99% of what was needed was already built. The system booted in qemuarm, and I plan to do some more testing of the runtime in the next little bit. Thanks, all, for the help. -- Tim = Tim Bird Architecture Group Chair, CE Workgroup of the Linux Foundation Senior Staff Engineer, Sony Network Entertainment = ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] examples / docs on utilizing an external toolchain
>> http://bugzilla.pokylinux.org/show_bug.cgi?id=1323 >> >> My question still stands even w/o it being in formal docs. > > FWIW, POKYMODE was replaced by TCMODE as part of the OE-Core changes. > I'd be interested to know where we've missed the references to it and > get to get those references fixed. Ok, but how does one use TCMODE? :) is there an example around anywhere? >>> >>> I'll explain on the condition that someone actually documents this ;-). >>> >>> TCMODE determines which of the files in >>> meta/conf/distro/include/tcmode-* is used. It defaults to "default" and >>> our default toolchain definition is in tcmode-default.inc. >>> >>> There is another example there which is "external-csl2008q3". As you can >>> see from the tcmode-external-csl2008q3 file, it sets up the system to >>> use an external toolchain instead. >>> >>> So you can define one of these files in your layer and then the system >>> can select alternative toolchain configurations. >>> >>> Does that help? :) >>> >>> There is a similar TCLIBC variable which controls which libc is used >>> (eglibc or uclibc). >> >> Yes that helps. So it looks as if today there is not a means to point >> to SDK prebuilt toolchain via this means. > > We have supported this in the past but it got messy and I'd really > prefer people to use sstate for this. > > You obviously can use the SDK toolchain as a prebuilt external toolchain > though since its no different from any other external toolchain. What got mess about it? Seems like a poky built sdk toolchain should work as an external toolchain w/o too much issue. - k ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] prebuilt pacakages
Can I suggest that Yocto put it on the futures list, but with a lower priority? > >From: Richard Purdie >To: Todd Cooper >Cc: "yocto@yoctoproject.org" >Sent: Thursday, August 4, 2011 6:43 PM >Subject: Re: [yocto] prebuilt pacakages > >On Thu, 2011-08-04 at 10:50 -0700, Todd Cooper wrote: >> Would this be worth putting on the list of items wished for in the >> future? >> >> It sounds like the problem is difficult, but not impossible. > >Most things are possible :). > >The implementation isn't hard, maintaining some kind of translation >table for the dependencies, shared library provision lists and so on is >a *lot* of work though. > >It would really take someone with a specific use case to step forward >along with manpower for it to have a chance of happening. Even then it >would work for a specific set of packages and wouldn't translate to any >other package feed. > >Cheers, > >Richard > >> >> >> __ >> From: Richard Purdie >> To: Todd Cooper >> Cc: "yocto@yoctoproject.org" >> Sent: Thursday, August 4, 2011 10:59 AM >> Subject: Re: [yocto] prebuilt pacakages >> >> On Thu, 2011-08-04 at 07:42 -0700, Todd Cooper wrote: >> > Is there any way to make Yocto try to get prebuilt packages >> from known >> > repositories rather than trying to rebuild the world? >> >> The system supports a cache of prebuilt objects in the form of >> the >> sstate data to accelerate build times if nothing changes. It >> doesn't >> directly support using prebuilt packages directly though as >> its a much >> harder problem to solve than you first realise. >> >> A an example, given a package feed, its very hard to work out >> library >> provision within that package feed or dependency naming. >> >> Cheers, >> >> Richard >> >> >> >> >> >> >> > >> > > > > >___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 0/1] meta/pandaboard: add pandaboard bsp
From: Jingdong Lu Add pandaboard bsp Jingdong Lu (1): pandaboard: add pandaboard bsp .../bsp/pandaboard/pandaboard-non_hardware.cfg | 30 ++ .../bsp/pandaboard/pandaboard-standard.scc |7 + .../cfg/kernel-cache/bsp/pandaboard/pandaboard.cfg | 346 .../cfg/kernel-cache/bsp/pandaboard/pandaboard.scc |5 + 4 files changed, 388 insertions(+), 0 deletions(-) create mode 100644 meta/cfg/kernel-cache/bsp/pandaboard/pandaboard-non_hardware.cfg create mode 100644 meta/cfg/kernel-cache/bsp/pandaboard/pandaboard-standard.scc create mode 100644 meta/cfg/kernel-cache/bsp/pandaboard/pandaboard.cfg create mode 100644 meta/cfg/kernel-cache/bsp/pandaboard/pandaboard.scc ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/1] pandaboard: add pandaboard bsp
From: Jingdong Lu add pandaboard bsp configuration. Signed-off-by: Jingdong Lu --- .../bsp/pandaboard/pandaboard-non_hardware.cfg | 30 ++ .../bsp/pandaboard/pandaboard-standard.scc |7 + .../cfg/kernel-cache/bsp/pandaboard/pandaboard.cfg | 346 .../cfg/kernel-cache/bsp/pandaboard/pandaboard.scc |5 + 4 files changed, 388 insertions(+), 0 deletions(-) create mode 100644 meta/cfg/kernel-cache/bsp/pandaboard/pandaboard-non_hardware.cfg create mode 100644 meta/cfg/kernel-cache/bsp/pandaboard/pandaboard-standard.scc create mode 100644 meta/cfg/kernel-cache/bsp/pandaboard/pandaboard.cfg create mode 100644 meta/cfg/kernel-cache/bsp/pandaboard/pandaboard.scc diff --git a/meta/cfg/kernel-cache/bsp/pandaboard/pandaboard-non_hardware.cfg b/meta/cfg/kernel-cache/bsp/pandaboard/pandaboard-non_hardware.cfg new file mode 100644 index 000..361343b --- /dev/null +++ b/meta/cfg/kernel-cache/bsp/pandaboard/pandaboard-non_hardware.cfg @@ -0,0 +1,30 @@ +# +# Miscellaneous filesystems +# +CONFIG_NFS_DEF_FILE_IO_SIZE=1024 + +# +# Multiple Device Support +# +# CONFIG_MD is not set + +# Kernel Features +# +CONFIG_NO_HZ=y + +# +# CPUIdle +# +CONFIG_CPU_IDLE=y +CONFIG_CPU_IDLE_GOV_LADDER=y +CONFIG_CPU_IDLE_GOV_MENU=y + +# +# Kernel hacking +# +CONFIG_DEBUG_FS=y + +# +# Power management options +# +CONFIG_PM_DEBUG=y diff --git a/meta/cfg/kernel-cache/bsp/pandaboard/pandaboard-standard.scc b/meta/cfg/kernel-cache/bsp/pandaboard/pandaboard-standard.scc new file mode 100644 index 000..4415af4 --- /dev/null +++ b/meta/cfg/kernel-cache/bsp/pandaboard/pandaboard-standard.scc @@ -0,0 +1,7 @@ +define KMACHINE pandaboard +define KTYPE standard +define KARCH arm + +scc_leaf ktypes/standard pandaboard + +include pandaboard.scc diff --git a/meta/cfg/kernel-cache/bsp/pandaboard/pandaboard.cfg b/meta/cfg/kernel-cache/bsp/pandaboard/pandaboard.cfg new file mode 100644 index 000..d147f3c --- /dev/null +++ b/meta/cfg/kernel-cache/bsp/pandaboard/pandaboard.cfg @@ -0,0 +1,346 @@ +# +# System Type +# +CONFIG_ARCH_OMAP=y + +# +# TI OMAP Common Features +# +# CONFIG_ARCH_OMAP1 is not set +CONFIG_ARCH_OMAP2PLUS=y + +# +# OMAP Feature Selections +# +# CONFIG_OMAP_SMARTREFLEX is not set +CONFIG_OMAP_RESET_CLOCKS=y +CONFIG_OMAP_MUX=y +CONFIG_OMAP_MUX_DEBUG=y +CONFIG_OMAP_MUX_WARNINGS=y +CONFIG_OMAP_MCBSP=y +# CONFIG_OMAP_MBOX_FWK is not set +# CONFIG_OMAP_MPU_TIMER is not set +CONFIG_OMAP_32K_TIMER=y +# CONFIG_OMAP3_L2_AUX_SECURE_SAVE_RESTORE is not set +CONFIG_OMAP_32K_TIMER_HZ=128 +CONFIG_OMAP_DM_TIMER=y +# CONFIG_OMAP_PM_NONE is not set +CONFIG_OMAP_PM_NOOP=y +# CONFIG_MACH_OMAP_GENERIC is not set +CONFIG_CPU_32v6K=y +# +# TI OMAP2/3/4 Specific Features +# +CONFIG_ARCH_OMAP2PLUS_TYPICAL=y +CONFIG_ARCH_OMAP2=y +CONFIG_ARCH_OMAP3=y +CONFIG_ARCH_OMAP4=y + +# +# OMAP Core Type +# +# CONFIG_ARCH_OMAP2420 is not set +# CONFIG_ARCH_OMAP2430 is not set +# CONFIG_ARCH_OMAP3430 is not set +CONFIG_OMAP_PACKAGE_CBL=y +CONFIG_OMAP_PACKAGE_CBS=y + +# +# OMAP Board Type +# +CONFIG_MACH_OMAP_4430SDP=y +CONFIG_MACH_OMAP4_PANDA=y + +# +# Processor Features +# +CONFIG_ARM_THUMB=y +CONFIG_ARM_THUMBEE=y +CONFIG_DMA_CACHE_RWFO=y +CONFIG_OUTER_CACHE=y +CONFIG_OUTER_CACHE_SYNC=y +CONFIG_CACHE_L2X0=y +CONFIG_ARM_L1_CACHE_SHIFT=5 +CONFIG_ARM_DMA_MEM_BUFFERABLE=y +CONFIG_PL310_ERRATA_588369=y +CONFIG_ARM_ERRATA_720789=y +CONFIG_ARM_GIC=y +CONFIG_COMMON_CLKDEV=y + +# +# Kernel Features +# +CONFIG_LEDS=y + +# +# At least one emulation must be selected +# +CONFIG_FPE_NWFPE=y +# CONFIG_FPE_NWFPE_XP is not set +# CONFIG_FPE_FASTFPE is not set +CONFIG_VFP=y +CONFIG_VFPv3=y +CONFIG_NEON=y + +# +# Power management options +# +CONFIG_PM=y +CONFIG_PM_RUNTIME=y + + +# +# Input device support +# +CONFIG_INPUT=y + +# +# Hardware I/O ports +# +CONFIG_SERIO=y +CONFIG_SERIO_SERPORT=y +CONFIG_SERIO_LIBPS2=y + +# +# Character devices +# +CONFIG_VT=y +CONFIG_CONSOLE_TRANSLATIONS=y +CONFIG_VT_CONSOLE=y +CONFIG_HW_CONSOLE=y +CONFIG_VT_HW_CONSOLE_BINDING=y +CONFIG_DEVKMEM=y +# CONFIG_SERIAL_NONSTANDARD is not set +# CONFIG_N_GSM is not set + +# +# Serial drivers +# +CONFIG_SERIAL_8250=y +CONFIG_SERIAL_8250_CONSOLE=y +CONFIG_SERIAL_8250_NR_UARTS=32 +CONFIG_SERIAL_8250_RUNTIME_UARTS=4 +CONFIG_SERIAL_8250_EXTENDED=y +CONFIG_SERIAL_8250_MANY_PORTS=y +CONFIG_SERIAL_8250_SHARE_IRQ=y +CONFIG_SERIAL_8250_DETECT_IRQ=y +CONFIG_SERIAL_8250_RSA=y + +# +# Non-8250 serial port support +# +CONFIG_SERIAL_CORE=y +CONFIG_SERIAL_CORE_CONSOLE=y +CONFIG_SERIAL_OMAP=y +CONFIG_SERIAL_OMAP_CONSOLE=y +CONFIG_UNIX98_PTYS=y +CONFIG_HW_RANDOM=y +CONFIG_HW_RANDOM_OMAP=y +CONFIG_I2C=y +CONFIG_I2C_BOARDINFO=y +CONFIG_I2C_COMPAT=y +CONFIG_I2C_CHARDEV=y +CONFIG_I2C_HELPER_AUTO=y + +# +# I2C system bus drivers (mostly embedded / system-on-chip) +# +CONFIG_I2C_OMAP=y + +# +# Other I2C/SMBus bus drivers +# +CONFIG_SPI=y +CONFIG_SPI_MASTER=y + +# +# SPI Master Controller Drivers +# +CONFIG_SPI_OMAP24XX=y + +# +# PPS support +# +# CONFIG_PPS is not set +CONFIG_ARCH_REQUIR
