Re: [yocto] Eclipse ADT plugin configuration error
Problem solved. The toolchain root path needs to be pointed to the build directory i.e. in my case it happens to be: ~/mybuild Thanks & Regards, N.Kartik Senior developer | Renu Electronics Pvt. Ltd. _ From: Kartik N [mailto:kart...@renuelectronics.com] Sent: Thursday, October 25, 2012 10:20 AM To: 'yocto@yoctoproject.org' Subject: Eclipse ADT plugin configuration error Hi, I have bit-baked "meta-ide-support" and also created a sysroot and kernel image for the imx535qsb. Then I installed Eclipse following the steps in the ADT manual. Now I try to set the build environment. I point to the toolchain available under ~/mybuild/tmp/sysroots/i686-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi Set sysroot at this: ~/mybuild/tmp/sysroot But get error message: "Yocto Preferences Configuration Error! Specified Build Tree Toolchain Root does not contain any toolchain yet! Please run "bitbake meta-ide-support" to build the toolchain." Then I tried changing sysroot path to the build folders: ~/mybuild/tmp/deploy/images Error message: Still the same. What do I really need to check now? Thanks & Regards, N.Kartik Senior developer | Renu Electronics Pvt. Ltd. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Eclipse ADT plugin configuration error
Hi, I have bit-baked "meta-ide-support" and also created a sysroot and kernel image for the imx535qsb. Then I installed Eclipse following the steps in the ADT manual. Now I try to set the build environment. I point to the toolchain available under ~/mybuild/tmp/sysroots/i686-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi Set sysroot at this: ~/mybuild/tmp/sysroot But get error message: "Yocto Preferences Configuration Error! Specified Build Tree Toolchain Root does not contain any toolchain yet! Please run "bitbake meta-ide-support" to build the toolchain." Then I tried changing sysroot path to the build folders: ~/mybuild/tmp/deploy/images Error message: Still the same. What do I really need to check now? Thanks & Regards, N.Kartik Senior developer | Renu Electronics Pvt. Ltd. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] ERROR: Function failed: do_rootfs, poky commit id 8ce23f569584f195391bc5c68a780e1bf54e4360
Hi Ross, On Oct 23, 2012, at 11:53 PM, "Burton, Ross" wrote: > On 23 October 2012 19:35, Elvis Dowson wrote: >> the following entry works for the /etc/fstab for moving the /tmp file to RAM >> none/tmptmpfsdefaults,noatime,nodiratime00 > > tmpfs is in virtual memory, so potentially swap. Have you benchmarked > a build with the build on SSD verses in tmpfs to see what the > improvement is? There was no difference in build times with the /tmp folder in RAM or SSD Both these scenarios took around 22 minutes for commit id a3d5e9e6b7729319c518dcaf25bbe0643bfb25db I think the optimisation is only useful to improve the life of the SSD drive, by moving the /tmp folder to RAM. I've also moved the fire-fox browser cache to RAM, to avoid hitting the SSD as far as possible. > An alternative (and less intrusive) is to increase the commit timeout > on the build partition, which means more data is buffered in RAM > before the disk is used. I haven't benchmarked that either though. :) I modified /etc/sysctl.conf as follows, to improve desktop performance. One of the parameters vm.swappiness, controls swap to disk. With a setting of 10, and 16GB of RAM, it hardly ever swaps to disk throughout the entire build process. Here are my /etc/sysctl.conf settings: ### # Additional settings - these setting can increase desktop performance # Configure vm.mmap_min_addr vm.mmap_min_addr = 0 vm.vdso_enabled = 0 # Optimize swap usage to increase desktop performance vm.swappiness=10 vm.vfs_cache_pressure=1000 vm.dirty_background_ratio=10 vm.dirty_ratio=30 Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH v2 4/6] emenlow: add WEBTITLE & Compliance information
On Wed, 2012-10-24 at 13:25 -0700, nitin.a.kam...@intel.com wrote: > From: Nitin A Kamble > > The WEBTITLE will be used to publish the BSP on the Yocto Project Website. > And adding the Yocto Project Compliance information for the 1.3 release. > Also specifying all the layers used from meta-intel repository. > > Signed-off-by: Nitin A Kamble > --- > meta-emenlow/README|8 +++- > meta-emenlow/conf/machine/emenlow.conf |2 ++ > 2 files changed, 9 insertions(+), 1 deletions(-) > > diff --git a/meta-emenlow/README b/meta-emenlow/README > index 3932718..8216af2 100644 > --- a/meta-emenlow/README > +++ b/meta-emenlow/README > @@ -13,6 +13,12 @@ depending on which BSP tarball you downloaded. > Please see the corresponding sections below for details. > > > +Compliance > +== > +This BSP is compliant with Yocto Project as per requirements listed here: > +http://www.yoctoproject.org/yocto-project-compatible-registration > + > + > Dependencies > > > @@ -26,7 +32,7 @@ This layer depends on: >branch: master > >URI: git://git.yoctoproject.org/meta-intel > - layers: intel > + layers: meta-intel, meta-emenlow >branch: master > > > diff --git a/meta-emenlow/conf/machine/emenlow.conf > b/meta-emenlow/conf/machine/emenlow.conf > index d1efbc3..77cdbe6 100644 > --- a/meta-emenlow/conf/machine/emenlow.conf > +++ b/meta-emenlow/conf/machine/emenlow.conf > @@ -1,6 +1,8 @@ > #@TYPE: Machine > #@NAME: emenlow > > +#@WEBTITLE: Platforms with Intel Atom Z5xx processor with Intel US15W > Controller Hub (Emenlow) > + To be consistent with the other ones e.g crownbay, remove the 'Platforms with' and also capitalize as: Intel Atom Z5xx Processor with Intel US15W Platform Controller Hub (Emenlow) I think Emenlow is actually eMenlow... Tom > #@DESCRIPTION: Machine configuration for eMenlow based systems, like the > # Webs-2120 box. > ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH v2 5/6] jasperforest: add WEBTITLE & Compliance information
On Wed, 2012-10-24 at 13:25 -0700, nitin.a.kam...@intel.com wrote: > From: Nitin A Kamble > > The WEBTITLE will be used to publish the BSP on the Yocto Project Website. > And adding the Yocto Project Compliance information for the 1.3 release. > Also specifying all the layers used from meta-intel repository. > > Signed-off-by: Nitin A Kamble > --- > meta-jasperforest/README |8 +++- > meta-jasperforest/conf/machine/jasperforest.conf |2 ++ > 2 files changed, 9 insertions(+), 1 deletions(-) > > diff --git a/meta-jasperforest/README b/meta-jasperforest/README > index 12f84c2..6397ec7 100644 > --- a/meta-jasperforest/README > +++ b/meta-jasperforest/README > @@ -8,6 +8,12 @@ combined with the Intel 3420 PCH chipset (Ibex Peak) make up > the > 'Picket Post' CRB this BSP was developed on. > > > +Compliance > +== > +This BSP is compliant with Yocto Project as per requirements listed here: > +http://www.yoctoproject.org/yocto-project-compatible-registration > + > + > Dependencies > > > @@ -21,7 +27,7 @@ This layer depends on: >branch: master > >URI: git://git.yoctoproject.org/meta-intel > - layers: intel > + layers: meta-intel, meta-jasperforest >branch: master > > > diff --git a/meta-jasperforest/conf/machine/jasperforest.conf > b/meta-jasperforest/conf/machine/jasperforest.conf > index d661f7b..8111deb 100644 > --- a/meta-jasperforest/conf/machine/jasperforest.conf > +++ b/meta-jasperforest/conf/machine/jasperforest.conf > @@ -1,6 +1,8 @@ > #@TYPE: Machine > #@NAME: jasperforest > > +#@WEBTITLE: Platforms with Intel Xeon C5500/C3500 series processors with > Intel 3420 PCH chipset (Jasper Forest) > + Similarly: Intel Xeon C5500/C3500 Series Processors with Intel 3420 PCH Chipset (Jasper Forest) Tom > #@DESCRIPTION: Machine configuration for Jasper Forest Picket Post > # systems i.e. Xeon C5500/C3500 + Intel 3420 chipset (Ibex Peak) > ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH v2 3/6] crownbay: add WEBTITLE & Compliance information
On Wed, 2012-10-24 at 13:25 -0700, nitin.a.kam...@intel.com wrote: > From: Nitin A Kamble > > The WEBTITLE will be used to publish the BSP on the Yocto Project Website. > And adding the Yocto Project Compliance information for the 1.3 release. > Also specifying all the layers used from meta-intel repository. > > Signed-off-by: Nitin A Kamble > --- > meta-crownbay/README| 10 -- > meta-crownbay/conf/machine/crownbay-noemgd.conf |2 ++ > meta-crownbay/conf/machine/crownbay.conf|2 ++ > 3 files changed, 12 insertions(+), 2 deletions(-) > > diff --git a/meta-crownbay/README b/meta-crownbay/README > index 4bc9f31..f3ad506 100644 > --- a/meta-crownbay/README > +++ b/meta-crownbay/README > @@ -2,13 +2,19 @@ This README file contains information on building the > meta-crownbay > BSP layer, and booting the images contained in the /binary directory. > Please see the corresponding sections below for details. > > -The Crown Bay platform consists of the Intel Atom Z6xx processor, > +The Crown Bay platform consists of the Intel Atom E6xx processor, > plus the Intel EG20T Platform Controller Hub (Tunnel Creek + Topcliff). > > It also supports the E6xx embedded on-chip graphics via the Intel > Embedded Media and Graphics Driver (EMGD) 1.14 Driver. > > > +Compliance > +== > +This BSP is compliant with Yocto Project as per requirements listed here: > +http://www.yoctoproject.org/yocto-project-compatible-registration > + > + > Dependencies > > > @@ -22,7 +28,7 @@ This layer depends on: >branch: master > >URI: git://git.yoctoproject.org/meta-intel > - layers: intel > + layers: meta-intel, meta-crownbay >branch: master > > > diff --git a/meta-crownbay/conf/machine/crownbay-noemgd.conf > b/meta-crownbay/conf/machine/crownbay-noemgd.conf > index 4c869ee..c3bdcb4 100644 > --- a/meta-crownbay/conf/machine/crownbay-noemgd.conf > +++ b/meta-crownbay/conf/machine/crownbay-noemgd.conf > @@ -1,6 +1,8 @@ > #@TYPE: Machine > #@NAME: crownbay-noemgd > > +#@WEBTITLE: Intel Atom E6xx processor with Intel EG20T Controller Hub > development kit (Crown Bay) with open source VESA graphics > + This should probably be capitalized as in the manual title: Intel Atom E6xx Processor with Intel EG20T Controller Hub Development Kit (Crown Bay) with open source VESA graphics Same for the other one... Tom > #@DESCRIPTION: Machine configuration for Crown Bay systems, without > Intel-proprietary graphics bits > # i.e. E660 + EG20T > > diff --git a/meta-crownbay/conf/machine/crownbay.conf > b/meta-crownbay/conf/machine/crownbay.conf > index d56ef64..5e4147c 100644 > --- a/meta-crownbay/conf/machine/crownbay.conf > +++ b/meta-crownbay/conf/machine/crownbay.conf > @@ -1,6 +1,8 @@ > #@TYPE: Machine > #@NAME: crownbay > > +#@WEBTITLE: Intel Atom E6xx processor with Intel EG20T Controller Hub > development kit (Crown Bay) with proprietary IEMGD accelerated graphics > + > #@DESCRIPTION: Machine configuration for Crown Bay systems > # i.e. E660 + EG20T > ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH v2 2/6] chiefriver: add WEBTITLE & Compliance information
On Wed, 2012-10-24 at 13:25 -0700, nitin.a.kam...@intel.com wrote: > From: Nitin A Kamble > > The WEBTITLE will be used to publish the BSP on the Yocto Project Website. > And adding the Yocto Project Compliance information for the 1.3 release. > Also specifying all the layers used from meta-intel repository. > > Signed-off-by: Nitin A Kamble > --- > meta-chiefriver/README |8 +++- > meta-chiefriver/conf/machine/chiefriver.conf |2 ++ > 2 files changed, 9 insertions(+), 1 deletions(-) > > diff --git a/meta-chiefriver/README b/meta-chiefriver/README > index 7c47b02..249a389 100644 > --- a/meta-chiefriver/README > +++ b/meta-chiefriver/README > @@ -7,6 +7,12 @@ plus the Panther Point PCH. This BSP assumes that the Ivy > Bridge > integrated graphics are being used. > > > +Compliance > +== > +This BSP is compliant with Yocto Project as per requirements listed here: > +http://www.yoctoproject.org/yocto-project-compatible-registration > + To be consistent with the rest of the README, there should be a blank line between the = and the 'This BSP... ' text. Also, for readability, it would be nice to have the URL also separated by a blank line from the preceding text, and indented a couple spaces like similar lines in the README. Also, I think the compliance text reads better as: This BSP is compliant with the Yocto Project as per the requirements listed here: > + > Dependencies > > > @@ -20,7 +26,7 @@ This layer depends on: >branch: master > >URI: git://git.yoctoproject.org/meta-intel > - layers: intel > + layers: meta-intel, meta-chiefriver If you look at the meta-intel/conf/layer.conf, you see the layer actually is 'intel'. Also, this is the README for the chiefriver layer, so it can't depend on itself i.e. meta-chiefriver or 'chiefriver' shouldn't be listed in layers >branch: master > > > diff --git a/meta-chiefriver/conf/machine/chiefriver.conf > b/meta-chiefriver/conf/machine/chiefriver.conf > index b8b8754..5005ce0 100644 > --- a/meta-chiefriver/conf/machine/chiefriver.conf > +++ b/meta-chiefriver/conf/machine/chiefriver.conf > @@ -1,6 +1,8 @@ > #@TYPE: Machine > #@NAME: chiefriver > > +#@WEBTITLE: Intel 3rd Generations Core Platforms: Core i3, i5, i7 (Ivy > Bridge) > + Since this is text that will appear on the website, we need to be a little picky about grammar: it should read '3rd Generation' rather than '3rd Generations' These comments apply to the other README files as well, so I won't repeat them there, other than to fix any text that might appear on the website for those as well... Tom > #@DESCRIPTION: Machine configuration for Chief River systems > # i.e. Ivy Bridge + Panther Point > ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Weekly build available for QA testing.
The weekly build out of the Yocto Project is almost complete and should be available within the next hour or two. Some artifacts are still generating and should be available within the next few hours. Please begin QAing the available artifacts, keeping in mind that the build is not quite finished yet. Repository: git://git.yoctoproject.org/poky Branch: master Revision: 33440ee70623394d06a4b214c2be10788cba6d08 Location: http://autobuilder.yoctoproject.org/pub/nightly/20121024-1 Thanks -b -- Elizabeth Flanagan Yocto Project Build and Release ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH v2 0/6] meta-intel: README updates
From: Nitin A Kamble Changed the commits based on the feedback from Tom & Darren. We also need similar changes for other BSPs for 1.3 release. Thanks, Nitin The following changes since commit 62aa4ca25a943c864838b2910c5b506cca0c9323: fri2: Add grub-efi workaround for USB keyboard initialization (2012-10-24 13:16:00 -0700) are available in the git repository at: git://git.yoctoproject.org/meta-intel-contrib nitin/misc http://git.yoctoproject.org/cgit.cgi/meta-intel-contrib/log/?h=nitin/misc Nitin A Kamble (6): MAINTAINERS: correct pathname chiefriver: add WEBTITLE & Compliance information crownbay: add WEBTITLE & Compliance information emenlow: add WEBTITLE & Compliance information jasperforest: add WEBTITLE & Compliance information sugarbay: add WEBTITLE & Compliance information MAINTAINERS |2 +- meta-chiefriver/README |8 +++- meta-chiefriver/conf/machine/chiefriver.conf |2 ++ meta-crownbay/README | 10 -- meta-crownbay/conf/machine/crownbay-noemgd.conf |2 ++ meta-crownbay/conf/machine/crownbay.conf |2 ++ meta-emenlow/README |8 +++- meta-emenlow/conf/machine/emenlow.conf |2 ++ meta-jasperforest/README |8 +++- meta-jasperforest/conf/machine/jasperforest.conf |2 ++ meta-sugarbay/README |8 +++- meta-sugarbay/conf/machine/sugarbay.conf |2 ++ 12 files changed, 49 insertions(+), 7 deletions(-) -- 1.7.3.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH v2 4/6] emenlow: add WEBTITLE & Compliance information
From: Nitin A Kamble The WEBTITLE will be used to publish the BSP on the Yocto Project Website. And adding the Yocto Project Compliance information for the 1.3 release. Also specifying all the layers used from meta-intel repository. Signed-off-by: Nitin A Kamble --- meta-emenlow/README|8 +++- meta-emenlow/conf/machine/emenlow.conf |2 ++ 2 files changed, 9 insertions(+), 1 deletions(-) diff --git a/meta-emenlow/README b/meta-emenlow/README index 3932718..8216af2 100644 --- a/meta-emenlow/README +++ b/meta-emenlow/README @@ -13,6 +13,12 @@ depending on which BSP tarball you downloaded. Please see the corresponding sections below for details. +Compliance +== +This BSP is compliant with Yocto Project as per requirements listed here: +http://www.yoctoproject.org/yocto-project-compatible-registration + + Dependencies @@ -26,7 +32,7 @@ This layer depends on: branch: master URI: git://git.yoctoproject.org/meta-intel - layers: intel + layers: meta-intel, meta-emenlow branch: master diff --git a/meta-emenlow/conf/machine/emenlow.conf b/meta-emenlow/conf/machine/emenlow.conf index d1efbc3..77cdbe6 100644 --- a/meta-emenlow/conf/machine/emenlow.conf +++ b/meta-emenlow/conf/machine/emenlow.conf @@ -1,6 +1,8 @@ #@TYPE: Machine #@NAME: emenlow +#@WEBTITLE: Platforms with Intel Atom Z5xx processor with Intel US15W Controller Hub (Emenlow) + #@DESCRIPTION: Machine configuration for eMenlow based systems, like the # Webs-2120 box. -- 1.7.3.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH v2 1/6] MAINTAINERS: correct pathname
From: Nitin A Kamble The commmon directory has more stuff than just recipes-core. All this need to be maintained together as part of the meta-intel layer. Signed-off-by: Nitin A Kamble --- MAINTAINERS |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index d63ed31..eac592b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -42,7 +42,7 @@ F:meta-chiefriver/ COMMON M: Nitin A Kamble -F: common/recipes-core/ +F: common/ CROWNBAY M: Nitin A Kamble -- 1.7.3.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH v2 6/6] sugarbay: add WEBTITLE & Compliance information
From: Nitin A Kamble The WEBTITLE will be used to publish the BSP on the Yocto Project Website. And adding the Yocto Project Compliance information for the 1.3 release. Also specifying all the layers used from meta-intel repository. Signed-off-by: Nitin A Kamble --- meta-sugarbay/README |8 +++- meta-sugarbay/conf/machine/sugarbay.conf |2 ++ 2 files changed, 9 insertions(+), 1 deletions(-) diff --git a/meta-sugarbay/README b/meta-sugarbay/README index c8a99d7..5b84bac 100644 --- a/meta-sugarbay/README +++ b/meta-sugarbay/README @@ -7,6 +7,12 @@ plus the Cougar Point PCH (Q67 Express or B65 Express chipsets). This BSP assumes that the Sandy Bridge integrated graphics are being used. +Compliance +== +This BSP is compliant with Yocto Project as per requirements listed here: +http://www.yoctoproject.org/yocto-project-compatible-registration + + Dependencies @@ -20,7 +26,7 @@ This layer depends on: branch: master URI: git://git.yoctoproject.org/meta-intel - layers: intel + layers: meta-intel, meta-sugarbay branch: master diff --git a/meta-sugarbay/conf/machine/sugarbay.conf b/meta-sugarbay/conf/machine/sugarbay.conf index 1d0e68d..5fb0c59 100644 --- a/meta-sugarbay/conf/machine/sugarbay.conf +++ b/meta-sugarbay/conf/machine/sugarbay.conf @@ -1,6 +1,8 @@ #@TYPE: Machine #@NAME: sugarbay +#@WEBTITLE: Intel 2nd Generation Core Platforms: Core i3, i5, i7 (Sandy Bridge) + #@DESCRIPTION: Machine configuration for Sugar Bay systems # i.e. Sandy Bridge + Cougar Point -- 1.7.3.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH v2 5/6] jasperforest: add WEBTITLE & Compliance information
From: Nitin A Kamble The WEBTITLE will be used to publish the BSP on the Yocto Project Website. And adding the Yocto Project Compliance information for the 1.3 release. Also specifying all the layers used from meta-intel repository. Signed-off-by: Nitin A Kamble --- meta-jasperforest/README |8 +++- meta-jasperforest/conf/machine/jasperforest.conf |2 ++ 2 files changed, 9 insertions(+), 1 deletions(-) diff --git a/meta-jasperforest/README b/meta-jasperforest/README index 12f84c2..6397ec7 100644 --- a/meta-jasperforest/README +++ b/meta-jasperforest/README @@ -8,6 +8,12 @@ combined with the Intel 3420 PCH chipset (Ibex Peak) make up the 'Picket Post' CRB this BSP was developed on. +Compliance +== +This BSP is compliant with Yocto Project as per requirements listed here: +http://www.yoctoproject.org/yocto-project-compatible-registration + + Dependencies @@ -21,7 +27,7 @@ This layer depends on: branch: master URI: git://git.yoctoproject.org/meta-intel - layers: intel + layers: meta-intel, meta-jasperforest branch: master diff --git a/meta-jasperforest/conf/machine/jasperforest.conf b/meta-jasperforest/conf/machine/jasperforest.conf index d661f7b..8111deb 100644 --- a/meta-jasperforest/conf/machine/jasperforest.conf +++ b/meta-jasperforest/conf/machine/jasperforest.conf @@ -1,6 +1,8 @@ #@TYPE: Machine #@NAME: jasperforest +#@WEBTITLE: Platforms with Intel Xeon C5500/C3500 series processors with Intel 3420 PCH chipset (Jasper Forest) + #@DESCRIPTION: Machine configuration for Jasper Forest Picket Post # systems i.e. Xeon C5500/C3500 + Intel 3420 chipset (Ibex Peak) -- 1.7.3.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH v2 3/6] crownbay: add WEBTITLE & Compliance information
From: Nitin A Kamble The WEBTITLE will be used to publish the BSP on the Yocto Project Website. And adding the Yocto Project Compliance information for the 1.3 release. Also specifying all the layers used from meta-intel repository. Signed-off-by: Nitin A Kamble --- meta-crownbay/README| 10 -- meta-crownbay/conf/machine/crownbay-noemgd.conf |2 ++ meta-crownbay/conf/machine/crownbay.conf|2 ++ 3 files changed, 12 insertions(+), 2 deletions(-) diff --git a/meta-crownbay/README b/meta-crownbay/README index 4bc9f31..f3ad506 100644 --- a/meta-crownbay/README +++ b/meta-crownbay/README @@ -2,13 +2,19 @@ This README file contains information on building the meta-crownbay BSP layer, and booting the images contained in the /binary directory. Please see the corresponding sections below for details. -The Crown Bay platform consists of the Intel Atom Z6xx processor, +The Crown Bay platform consists of the Intel Atom E6xx processor, plus the Intel EG20T Platform Controller Hub (Tunnel Creek + Topcliff). It also supports the E6xx embedded on-chip graphics via the Intel Embedded Media and Graphics Driver (EMGD) 1.14 Driver. +Compliance +== +This BSP is compliant with Yocto Project as per requirements listed here: +http://www.yoctoproject.org/yocto-project-compatible-registration + + Dependencies @@ -22,7 +28,7 @@ This layer depends on: branch: master URI: git://git.yoctoproject.org/meta-intel - layers: intel + layers: meta-intel, meta-crownbay branch: master diff --git a/meta-crownbay/conf/machine/crownbay-noemgd.conf b/meta-crownbay/conf/machine/crownbay-noemgd.conf index 4c869ee..c3bdcb4 100644 --- a/meta-crownbay/conf/machine/crownbay-noemgd.conf +++ b/meta-crownbay/conf/machine/crownbay-noemgd.conf @@ -1,6 +1,8 @@ #@TYPE: Machine #@NAME: crownbay-noemgd +#@WEBTITLE: Intel Atom E6xx processor with Intel EG20T Controller Hub development kit (Crown Bay) with open source VESA graphics + #@DESCRIPTION: Machine configuration for Crown Bay systems, without Intel-proprietary graphics bits # i.e. E660 + EG20T diff --git a/meta-crownbay/conf/machine/crownbay.conf b/meta-crownbay/conf/machine/crownbay.conf index d56ef64..5e4147c 100644 --- a/meta-crownbay/conf/machine/crownbay.conf +++ b/meta-crownbay/conf/machine/crownbay.conf @@ -1,6 +1,8 @@ #@TYPE: Machine #@NAME: crownbay +#@WEBTITLE: Intel Atom E6xx processor with Intel EG20T Controller Hub development kit (Crown Bay) with proprietary IEMGD accelerated graphics + #@DESCRIPTION: Machine configuration for Crown Bay systems # i.e. E660 + EG20T -- 1.7.3.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH v2 2/6] chiefriver: add WEBTITLE & Compliance information
From: Nitin A Kamble The WEBTITLE will be used to publish the BSP on the Yocto Project Website. And adding the Yocto Project Compliance information for the 1.3 release. Also specifying all the layers used from meta-intel repository. Signed-off-by: Nitin A Kamble --- meta-chiefriver/README |8 +++- meta-chiefriver/conf/machine/chiefriver.conf |2 ++ 2 files changed, 9 insertions(+), 1 deletions(-) diff --git a/meta-chiefriver/README b/meta-chiefriver/README index 7c47b02..249a389 100644 --- a/meta-chiefriver/README +++ b/meta-chiefriver/README @@ -7,6 +7,12 @@ plus the Panther Point PCH. This BSP assumes that the Ivy Bridge integrated graphics are being used. +Compliance +== +This BSP is compliant with Yocto Project as per requirements listed here: +http://www.yoctoproject.org/yocto-project-compatible-registration + + Dependencies @@ -20,7 +26,7 @@ This layer depends on: branch: master URI: git://git.yoctoproject.org/meta-intel - layers: intel + layers: meta-intel, meta-chiefriver branch: master diff --git a/meta-chiefriver/conf/machine/chiefriver.conf b/meta-chiefriver/conf/machine/chiefriver.conf index b8b8754..5005ce0 100644 --- a/meta-chiefriver/conf/machine/chiefriver.conf +++ b/meta-chiefriver/conf/machine/chiefriver.conf @@ -1,6 +1,8 @@ #@TYPE: Machine #@NAME: chiefriver +#@WEBTITLE: Intel 3rd Generations Core Platforms: Core i3, i5, i7 (Ivy Bridge) + #@DESCRIPTION: Machine configuration for Chief River systems # i.e. Ivy Bridge + Panther Point -- 1.7.3.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 3/6] crownbay README: add WebTitle & Compliance information
> > > > -The Crown Bay platform consists of the Intel Atom Z6xx processor, > > +The Crown Bay platform consists of the Intel Atom E6xx processor, > > plus the Intel EG20T Platform Controller Hub (Tunnel Creek + Topcliff). > > How can we distinguish this from Queens Bay, which I would describe in > exactly the same terms? > > -- > Darren > > > 1st let us understand what are the differences in the crownbay & queens bay platforms? If there are not significant differences then we can also look at possibility of combining two BSPs into one. I can add bit more information in the crownbay readme, such as shellbay & littlebay boards. And for FRI2 you can talk about the extra M2M devices. And I am not clear how to differentiate crownbay BSP with sys94x BSP. Nitin ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 3/3] fri2: Add grub-efi workaround for USB keyboard initialization
On Tue, 2012-10-23 at 21:31 -0700, Darren Hart wrote:
> The Fastboot firmware will sometimes fail to init the USB keyboard when
> connected directly in 1.0 mode (works fine through a 2.0 hub). By adding
> the USB modules to the grub-efi build, we can ensure the keyboard will
> be available in the grub menu at the expense of about a second in boot
> time.
>
> Signed-off-by: Darren Hart
Acked-by: Tom Zanussi
> ---
> .../recipes-bsp/grub/grub-efi-native_2.00.bbappend | 11 +++
> 1 files changed, 11 insertions(+), 0 deletions(-)
> create mode 100644 meta-fri2/recipes-bsp/grub/grub-efi-native_2.00.bbappend
>
> diff --git a/meta-fri2/recipes-bsp/grub/grub-efi-native_2.00.bbappend
> b/meta-fri2/recipes-bsp/grub/grub-efi-native_2.00.bbappend
> new file mode 100644
> index 000..c6904ef
> --- /dev/null
> +++ b/meta-fri2/recipes-bsp/grub/grub-efi-native_2.00.bbappend
> @@ -0,0 +1,11 @@
> +# The Intel provided Fast Boot Firmware may not initialize the USB keyboard
> +# before launching the grub.efi payload. Ensure GRUB has keyboard control by
> +# building in the usb, usb_keyboard, and ohci modules.
> +
> +do_mkimage() {
> + ./grub-mkimage -p /EFI/BOOT -d ./grub-core/ \
> +-O ${GRUB_TARGET}-efi -o ./${GRUB_IMAGE} \
> +boot linux ext2 fat serial part_msdos part_gpt normal
> efi_gop \
> +usb usb_keyboard ohci
> +}
> +
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 2/3] fri2: README: Correct typographical and wording errors
On Tue, 2012-10-23 at 21:31 -0700, Darren Hart wrote: > Correct minor issues reported by Steve S. > > Signed-off-by: Darren Hart > Reported-by: Steve Sakoman Acked-by: Tom Zanussi > --- > meta-fri2/README |6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/meta-fri2/README b/meta-fri2/README > index a866174..05b7257 100644 > --- a/meta-fri2/README > +++ b/meta-fri2/README > @@ -154,8 +154,8 @@ example: > # eject /dev/sdf > > This should give you a bootable USB flash device. Insert the device > -into a bootable USB socket on the target, and power on. This should > -result in a system booted to the Sato graphical desktop. > +into one of the USB host ports on the target, and power on. This > +should result in a system booted to the Sato graphical desktop. > > If you want a terminal, use the arrows at the top of the UI to move to > different pages of available applications, one of which is named > @@ -242,7 +242,7 @@ e. GPIO > --- > The FRI2 has two I2C PCA555x GPIO devices used for internal control > signals. These have not been exposed in the current release of the > -BSP, but may be in the future. Regardless, these do would not provide > +BSP, but may be in the future. Regardless, these would not provide > general purpose IO with which to read or drive additional signals. > > f. MMC ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/3] fri2: Add linux-yocto-tiny_3.4 support
On Tue, 2012-10-23 at 21:31 -0700, Darren Hart wrote:
> Add support for the tiny KTYPE via a liunx-yocto-tiny bbappend
> for the 3.4 kernel. With this kernel, DISTRO="poky-tiny" can be
> used with the fri2 and fri2-noemgd machines.
>
> Signed-off-by: Darren Hart
Acked-by: Tom Zanussi
> ---
> .../linux/linux-yocto-tiny_3.4.bbappend| 14 ++
> 1 files changed, 14 insertions(+), 0 deletions(-)
> create mode 100644
> meta-fri2/recipes-kernel/linux/linux-yocto-tiny_3.4.bbappend
>
> diff --git a/meta-fri2/recipes-kernel/linux/linux-yocto-tiny_3.4.bbappend
> b/meta-fri2/recipes-kernel/linux/linux-yocto-tiny_3.4.bbappend
> new file mode 100644
> index 000..bc96859
> --- /dev/null
> +++ b/meta-fri2/recipes-kernel/linux/linux-yocto-tiny_3.4.bbappend
> @@ -0,0 +1,14 @@
> +FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> +
> +COMPATIBLE_MACHINE_fri2 = "fri2"
> +KMACHINE_fri2 = "fri2"
> +KBRANCH_fri2 = "standard/tiny/base"
> +#SRCREV_machine_pn-linux-yocto-tiny_fri2 ?=
> "449f7f520350700858f21a5554b81cc8ad23267d"
> +SRCREV_meta_pn-linux-yocto-tiny_fri2 ?=
> "2ec32d511b62d44b63e8560a9b1d6895a5dac695"
> +
> +
> +COMPATIBLE_MACHINE_fri2-noemgd = "fri2-noemgd"
> +KMACHINE_fri2-noemgd = "fri2"
> +KBRANCH_fri2-noemgd = "standard/tiny/base"
> +#SRCREV_machine_pn-linux-yocto-tiny_fri2-noemgd ?=
> "449f7f520350700858f21a5554b81cc8ad23267d"
> +SRCREV_meta_pn-linux-yocto-tiny_fri2-noemgd ?=
> "2ec32d511b62d44b63e8560a9b1d6895a5dac695"
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/1] meta-intel: fix VA_FEATURES assignment in machine configs
On 10/24/2012 06:30 AM, tom.zanu...@intel.com wrote: > From: Tom Zanussi > > commit 2231d38 (meta-intel: make video acceleration choice dependent > on LICENSE_FLAGS) inadvertently also changed '?=' to a hard > assignment, making it hard to override as intended. This changes it > back. > > Signed-off-by: Tom Zanussi Acked-by: Darren Hart -- Darren Hart Intel Open Source Technology Center Yocto Project - Technical Lead - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 3/6] crownbay README: add WebTitle & Compliance information
On Wed, 2012-10-24 at 11:15 -0700, Sean Liming wrote: > > -Original Message- > > From: yocto-boun...@yoctoproject.org [mailto:yocto- > > boun...@yoctoproject.org] On Behalf Of Tom Zanussi > > Sent: Wednesday, October 24, 2012 9:43 AM > > To: Kamble, Nitin A > > Cc: yocto@yoctoproject.org; Hart, Darren > > Subject: Re: [yocto] [PATCH 3/6] crownbay README: add WebTitle & > > Compliance information > > > > On Wed, 2012-10-24 at 11:06 -0500, Kamble, Nitin A wrote: > > > > > > > -Original Message- > > > > From: Zanussi, Tom > > > > Sent: Tuesday, October 23, 2012 2:16 PM > > > > To: Kamble, Nitin A > > > > Cc: yocto@yoctoproject.org; Hart, Darren > > > > Subject: Re: [PATCH 3/6] crownbay README: add WebTitle & Compliance > > > > information > > > > > > > > On Tue, 2012-10-23 at 13:24 -0700, nitin.a.kam...@intel.com wrote: > > > > > From: Nitin A Kamble > > > > > > > > > > The WebTitle will be used to publish the BSP on the Yocto Project > > Website. > > > > > And adding the Yocto Project Compliance information for the 1.3 > > release. > > > > > Also specifying all the layers used from meta-intel repository. > > > > > > > > > > Signed-off-by: Nitin A Kamble > > > > > --- > > > > > meta-crownbay/README | 13 +++-- > > > > > 1 files changed, 11 insertions(+), 2 deletions(-) > > > > > > > > > > diff --git a/meta-crownbay/README b/meta-crownbay/README index > > > > > 4bc9f31..3996a94 100644 > > > > > --- a/meta-crownbay/README > > > > > +++ b/meta-crownbay/README > > > > > @@ -2,13 +2,22 @@ This README file contains information on > > > > > building the meta-crownbay BSP layer, and booting the images > > > > > contained in the > > > > /binary directory. > > > > > Please see the corresponding sections below for details. > > > > > > > > > > -The Crown Bay platform consists of the Intel Atom Z6xx processor, > > > > > +The Crown Bay platform consists of the Intel Atom E6xx processor, > > > > > plus the Intel EG20T Platform Controller Hub (Tunnel Creek + > > > > > Topcliff). > > > > > > > > > > It also supports the E6xx embedded on-chip graphics via the Intel > > > > > Embedded Media and Graphics Driver (EMGD) 1.14 Driver. > > > > > > > > > > > > > > > +WebTitle: Intel Atom E6xx processor with Intel EG20T Controller > > > > > +Hub development kit (crownbay) > > > > > + > > > > > > > > I'm not sure this kind of thing should be in the README since we can > > > > have multiple downloadable BSPs per layer e.g. crownbay vs > > > > crownbay-noemgd. I suppose in keeping with the build system you > > > > could have separate WebTitle_crownbay and WebTitle_crownbay- > > noemgd > > > > lines. ;-) (and it would be nice if you could get rid of the > > > > CamelCaps too) > > > > > > > > Why not put this info in the machine.conf, where we already have > > > > fields meant to be machine parseable e.g. > > > > > > > > #@TYPE: Machine > > > > #@NAME: crownbay > > > > > > > > #@WEBTITLE: ... > > > > > > > > Or maybe just use the exisiting #@DESCRIPTION for that... > > > > > > For example in the current way the BSPs are published, this is shown > > > on the YP website for crownbay > > > > > > Intel Atom Processor E660 with Intel Platform Controller Hub EG20T > > > Development Kit > > > Version: 7.0 "Denzil" > > > Release date: 29 Jun 2012 > > > Type: BSP > > > Download Links: > > > Crown Bay > > > Crown Bay no EMGD > > > Release Notes > > > > > > So there is one BSP list item per h/w with multiple links to different BSP > > tarballs for the same hardware. > > > If we move the WebTitle in machine file, then we will have multiple items > > in the BSP list for the same hardware. > > > I am not sure which is better from the downloader's point of view. But > > > this > > is worth considering for this change. > > > > > > > Yeah, on the one hand if we have text that's the same for all BSPs in the > > layer, it could go in the README for lack of a better common place. > > > > But we should consider whether we want to lay things out as the crownbay > > above, or more like the cedartrail, which has: > > > > Intel® Atom™ Processor N2000 and D2000 Series-based Platform (CEDAR > > TRAIL) with PowerVR Graphics > > > > (there's no corresponding -nopvr version available, though I suspect that's > > an > > oversight and would have been something like: > > > > Intel® Atom™ Processor N2000 and D2000 Series-based Platform (CEDAR > > TRAIL) with VESA Graphics > > > > I'm not sure the field(s) need to map exactly to the page layout, but all > > the > > information should be there to allow the page to be generated or laid out by > > hand without having to ask questions, in either case. Did you have any idea > > as to how for example to distinguish between the emgd and -noemgd > > versions (side note: there's nothing in the current entry that tells the > > user > > what EMGD even is - should it at least be spelled out in the title, or do we > > need a separate subtext element to describe > > that?) > > > > Tom > > >
Re: [yocto] [PATCH 3/6] crownbay README: add WebTitle & Compliance information
> -Original Message- > From: Sean Liming [mailto:sean.lim...@annabooks.com] > Sent: Wednesday, October 24, 2012 11:51 AM > To: 'Kamble, Nitin A' > Subject: RE: [yocto] [PATCH 3/6] crownbay README: add WebTitle & > Compliance information > > > > > > -Original Message- > > From: Kamble, Nitin A [mailto:nitin.a.kam...@intel.com] > > Sent: Wednesday, October 24, 2012 11:38 AM > > To: Sean Liming; yocto@yoctoproject.org > > Subject: RE: [yocto] [PATCH 3/6] crownbay README: add WebTitle & > > Compliance information > > > > > > > > > -Original Message- > > > From: yocto-boun...@yoctoproject.org [mailto:yocto- > > > boun...@yoctoproject.org] On Behalf Of Sean Liming > > > Sent: Wednesday, October 24, 2012 11:16 AM > > > To: yocto@yoctoproject.org > > > Subject: Re: [yocto] [PATCH 3/6] crownbay README: add WebTitle & > > > Compliance information > > > > > > > -Original Message- > > > > From: yocto-boun...@yoctoproject.org [mailto:yocto- > > > > boun...@yoctoproject.org] On Behalf Of Tom Zanussi > > > > Sent: Wednesday, October 24, 2012 9:43 AM > > > > To: Kamble, Nitin A > > > > Cc: yocto@yoctoproject.org; Hart, Darren > > > > Subject: Re: [yocto] [PATCH 3/6] crownbay README: add WebTitle & > > > > Compliance information > > > > > > > > On Wed, 2012-10-24 at 11:06 -0500, Kamble, Nitin A wrote: > > > > > > > > > > > -Original Message- > > > > > > From: Zanussi, Tom > > > > > > Sent: Tuesday, October 23, 2012 2:16 PM > > > > > > To: Kamble, Nitin A > > > > > > Cc: yocto@yoctoproject.org; Hart, Darren > > > > > > Subject: Re: [PATCH 3/6] crownbay README: add WebTitle & > > > > > > Compliance information > > > > > > > > > > > > On Tue, 2012-10-23 at 13:24 -0700, nitin.a.kam...@intel.com wrote: > > > > > > > From: Nitin A Kamble > > > > > > > > > > > > > > The WebTitle will be used to publish the BSP on the Yocto > > > > > > > Project > > > > Website. > > > > > > > And adding the Yocto Project Compliance information for the > > > > > > > 1.3 > > > > release. > > > > > > > Also specifying all the layers used from meta-intel repository. > > > > > > > > > > > > > > Signed-off-by: Nitin A Kamble > > > > > > > --- > > > > > > > meta-crownbay/README | 13 +++-- > > > > > > > 1 files changed, 11 insertions(+), 2 deletions(-) > > > > > > > > > > > > > > diff --git a/meta-crownbay/README b/meta-crownbay/README > > > index > > > > > > > 4bc9f31..3996a94 100644 > > > > > > > --- a/meta-crownbay/README > > > > > > > +++ b/meta-crownbay/README > > > > > > > @@ -2,13 +2,22 @@ This README file contains information on > > > > > > > building the meta-crownbay BSP layer, and booting the > > > > > > > images contained in the > > > > > > /binary directory. > > > > > > > Please see the corresponding sections below for details. > > > > > > > > > > > > > > -The Crown Bay platform consists of the Intel Atom Z6xx > > > > > > > processor, > > > > > > > +The Crown Bay platform consists of the Intel Atom E6xx > > > > > > > +processor, > > > > > > > plus the Intel EG20T Platform Controller Hub (Tunnel Creek > > > > > > > + > > > Topcliff). > > > > > > > > > > > > > > It also supports the E6xx embedded on-chip graphics via the > > > > > > > Intel Embedded Media and Graphics Driver (EMGD) 1.14 Driver. > > > > > > > > > > > > > > > > > > > > > +WebTitle: Intel Atom E6xx processor with Intel EG20T > > > > > > > +Controller Hub development kit (crownbay) > > > > > > > + > > > > > > > > > > > > I'm not sure this kind of thing should be in the README since > > > > > > we can have multiple downloadable BSPs per layer e.g. crownbay > > > > > > vs crownbay-noemgd. I suppose in keeping with the build > > > > > > system you could have separate WebTitle_crownbay and > > > > > > WebTitle_crownbay- > > > > noemgd > > > > > > lines. ;-) (and it would be nice if you could get rid of the > > > > > > CamelCaps too) > > > > > > > > > > > > Why not put this info in the machine.conf, where we already > > > > > > have fields meant to be machine parseable e.g. > > > > > > > > > > > > #@TYPE: Machine > > > > > > #@NAME: crownbay > > > > > > > > > > > > #@WEBTITLE: ... > > > > > > > > > > > > Or maybe just use the exisiting #@DESCRIPTION for that... > > > > > > > > > > For example in the current way the BSPs are published, this is > > > > > shown on the YP website for crownbay > > > > > > > > > > Intel Atom Processor E660 with Intel Platform Controller Hub > > > > > EG20T Development Kit > > > > > Version: 7.0 "Denzil" > > > > > Release date: 29 Jun 2012 > > > > > Type: BSP > > > > > Download Links: > > > > > Crown Bay > > > > > Crown Bay no EMGD > > > > > Release Notes > > > > > > > > > > So there is one BSP list item per h/w with multiple links to > > > > > different BSP > > > > tarballs for the same hardware. > > > > > If we move the WebTitle in machine file, then we will have > > > > > multiple items > > > > in the BSP list for the same hardware. > > > > > I am not sure which is better from the downloader's
Re: [yocto] [PATCH 3/6] crownbay README: add WebTitle & Compliance information
> -Original Message- > From: yocto-boun...@yoctoproject.org [mailto:yocto- > boun...@yoctoproject.org] On Behalf Of Sean Liming > Sent: Wednesday, October 24, 2012 11:16 AM > To: yocto@yoctoproject.org > Subject: Re: [yocto] [PATCH 3/6] crownbay README: add WebTitle & > Compliance information > > > -Original Message- > > From: yocto-boun...@yoctoproject.org [mailto:yocto- > > boun...@yoctoproject.org] On Behalf Of Tom Zanussi > > Sent: Wednesday, October 24, 2012 9:43 AM > > To: Kamble, Nitin A > > Cc: yocto@yoctoproject.org; Hart, Darren > > Subject: Re: [yocto] [PATCH 3/6] crownbay README: add WebTitle & > > Compliance information > > > > On Wed, 2012-10-24 at 11:06 -0500, Kamble, Nitin A wrote: > > > > > > > -Original Message- > > > > From: Zanussi, Tom > > > > Sent: Tuesday, October 23, 2012 2:16 PM > > > > To: Kamble, Nitin A > > > > Cc: yocto@yoctoproject.org; Hart, Darren > > > > Subject: Re: [PATCH 3/6] crownbay README: add WebTitle & > > > > Compliance information > > > > > > > > On Tue, 2012-10-23 at 13:24 -0700, nitin.a.kam...@intel.com wrote: > > > > > From: Nitin A Kamble > > > > > > > > > > The WebTitle will be used to publish the BSP on the Yocto > > > > > Project > > Website. > > > > > And adding the Yocto Project Compliance information for the 1.3 > > release. > > > > > Also specifying all the layers used from meta-intel repository. > > > > > > > > > > Signed-off-by: Nitin A Kamble > > > > > --- > > > > > meta-crownbay/README | 13 +++-- > > > > > 1 files changed, 11 insertions(+), 2 deletions(-) > > > > > > > > > > diff --git a/meta-crownbay/README b/meta-crownbay/README > index > > > > > 4bc9f31..3996a94 100644 > > > > > --- a/meta-crownbay/README > > > > > +++ b/meta-crownbay/README > > > > > @@ -2,13 +2,22 @@ This README file contains information on > > > > > building the meta-crownbay BSP layer, and booting the images > > > > > contained in the > > > > /binary directory. > > > > > Please see the corresponding sections below for details. > > > > > > > > > > -The Crown Bay platform consists of the Intel Atom Z6xx > > > > > processor, > > > > > +The Crown Bay platform consists of the Intel Atom E6xx > > > > > +processor, > > > > > plus the Intel EG20T Platform Controller Hub (Tunnel Creek + > Topcliff). > > > > > > > > > > It also supports the E6xx embedded on-chip graphics via the > > > > > Intel Embedded Media and Graphics Driver (EMGD) 1.14 Driver. > > > > > > > > > > > > > > > +WebTitle: Intel Atom E6xx processor with Intel EG20T Controller > > > > > +Hub development kit (crownbay) > > > > > + > > > > > > > > I'm not sure this kind of thing should be in the README since we > > > > can have multiple downloadable BSPs per layer e.g. crownbay vs > > > > crownbay-noemgd. I suppose in keeping with the build system you > > > > could have separate WebTitle_crownbay and WebTitle_crownbay- > > noemgd > > > > lines. ;-) (and it would be nice if you could get rid of the > > > > CamelCaps too) > > > > > > > > Why not put this info in the machine.conf, where we already have > > > > fields meant to be machine parseable e.g. > > > > > > > > #@TYPE: Machine > > > > #@NAME: crownbay > > > > > > > > #@WEBTITLE: ... > > > > > > > > Or maybe just use the exisiting #@DESCRIPTION for that... > > > > > > For example in the current way the BSPs are published, this is shown > > > on the YP website for crownbay > > > > > > Intel Atom Processor E660 with Intel Platform Controller Hub EG20T > > > Development Kit > > > Version: 7.0 "Denzil" > > > Release date: 29 Jun 2012 > > > Type: BSP > > > Download Links: > > > Crown Bay > > > Crown Bay no EMGD > > > Release Notes > > > > > > So there is one BSP list item per h/w with multiple links to > > > different BSP > > tarballs for the same hardware. > > > If we move the WebTitle in machine file, then we will have multiple > > > items > > in the BSP list for the same hardware. > > > I am not sure which is better from the downloader's point of view. > > > But this > > is worth considering for this change. > > > > > > > Yeah, on the one hand if we have text that's the same for all BSPs in > > the layer, it could go in the README for lack of a better common place. > > > > But we should consider whether we want to lay things out as the > > crownbay above, or more like the cedartrail, which has: > > > > Intel® Atom™ Processor N2000 and D2000 Series-based Platform (CEDAR > > TRAIL) with PowerVR Graphics > > > > (there's no corresponding -nopvr version available, though I suspect > > that's an oversight and would have been something like: > > > > Intel® Atom™ Processor N2000 and D2000 Series-based Platform (CEDAR > > TRAIL) with VESA Graphics > > > > I'm not sure the field(s) need to map exactly to the page layout, but > > all the information should be there to allow the page to be generated > > or laid out by hand without having to ask questions, in either case. > > Did you have any idea as to how for example to distinguish betwe
Re: [yocto] [PATCH 3/6] crownbay README: add WebTitle & Compliance information
> -Original Message- > From: yocto-boun...@yoctoproject.org [mailto:yocto- > boun...@yoctoproject.org] On Behalf Of Tom Zanussi > Sent: Wednesday, October 24, 2012 9:43 AM > To: Kamble, Nitin A > Cc: yocto@yoctoproject.org; Hart, Darren > Subject: Re: [yocto] [PATCH 3/6] crownbay README: add WebTitle & > Compliance information > > On Wed, 2012-10-24 at 11:06 -0500, Kamble, Nitin A wrote: > > > > > -Original Message- > > > From: Zanussi, Tom > > > Sent: Tuesday, October 23, 2012 2:16 PM > > > To: Kamble, Nitin A > > > Cc: yocto@yoctoproject.org; Hart, Darren > > > Subject: Re: [PATCH 3/6] crownbay README: add WebTitle & Compliance > > > information > > > > > > On Tue, 2012-10-23 at 13:24 -0700, nitin.a.kam...@intel.com wrote: > > > > From: Nitin A Kamble > > > > > > > > The WebTitle will be used to publish the BSP on the Yocto Project > Website. > > > > And adding the Yocto Project Compliance information for the 1.3 > release. > > > > Also specifying all the layers used from meta-intel repository. > > > > > > > > Signed-off-by: Nitin A Kamble > > > > --- > > > > meta-crownbay/README | 13 +++-- > > > > 1 files changed, 11 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/meta-crownbay/README b/meta-crownbay/README index > > > > 4bc9f31..3996a94 100644 > > > > --- a/meta-crownbay/README > > > > +++ b/meta-crownbay/README > > > > @@ -2,13 +2,22 @@ This README file contains information on > > > > building the meta-crownbay BSP layer, and booting the images > > > > contained in the > > > /binary directory. > > > > Please see the corresponding sections below for details. > > > > > > > > -The Crown Bay platform consists of the Intel Atom Z6xx processor, > > > > +The Crown Bay platform consists of the Intel Atom E6xx processor, > > > > plus the Intel EG20T Platform Controller Hub (Tunnel Creek + Topcliff). > > > > > > > > It also supports the E6xx embedded on-chip graphics via the Intel > > > > Embedded Media and Graphics Driver (EMGD) 1.14 Driver. > > > > > > > > > > > > +WebTitle: Intel Atom E6xx processor with Intel EG20T Controller > > > > +Hub development kit (crownbay) > > > > + > > > > > > I'm not sure this kind of thing should be in the README since we can > > > have multiple downloadable BSPs per layer e.g. crownbay vs > > > crownbay-noemgd. I suppose in keeping with the build system you > > > could have separate WebTitle_crownbay and WebTitle_crownbay- > noemgd > > > lines. ;-) (and it would be nice if you could get rid of the > > > CamelCaps too) > > > > > > Why not put this info in the machine.conf, where we already have > > > fields meant to be machine parseable e.g. > > > > > > #@TYPE: Machine > > > #@NAME: crownbay > > > > > > #@WEBTITLE: ... > > > > > > Or maybe just use the exisiting #@DESCRIPTION for that... > > > > For example in the current way the BSPs are published, this is shown > > on the YP website for crownbay > > > > Intel Atom Processor E660 with Intel Platform Controller Hub EG20T > > Development Kit > > Version: 7.0 "Denzil" > > Release date: 29 Jun 2012 > > Type: BSP > > Download Links: > > Crown Bay > > Crown Bay no EMGD > > Release Notes > > > > So there is one BSP list item per h/w with multiple links to different BSP > tarballs for the same hardware. > > If we move the WebTitle in machine file, then we will have multiple items > in the BSP list for the same hardware. > > I am not sure which is better from the downloader's point of view. But this > is worth considering for this change. > > > > Yeah, on the one hand if we have text that's the same for all BSPs in the > layer, it could go in the README for lack of a better common place. > > But we should consider whether we want to lay things out as the crownbay > above, or more like the cedartrail, which has: > > Intel® Atom™ Processor N2000 and D2000 Series-based Platform (CEDAR > TRAIL) with PowerVR Graphics > > (there's no corresponding -nopvr version available, though I suspect that's an > oversight and would have been something like: > > Intel® Atom™ Processor N2000 and D2000 Series-based Platform (CEDAR > TRAIL) with VESA Graphics > > I'm not sure the field(s) need to map exactly to the page layout, but all the > information should be there to allow the page to be generated or laid out by > hand without having to ask questions, in either case. Did you have any idea > as to how for example to distinguish between the emgd and -noemgd > versions (side note: there's nothing in the current entry that tells the user > what EMGD even is - should it at least be spelled out in the title, or do we > need a separate subtext element to describe > that?) > > Tom > I am working with CEDAR trail and Crown Bay-like (SYS940X-ECX) systems. For Crown Bay, it is a little confusing to know which tar ball to download. It would be clearer to have one BSP with an option switch to enable the video. Also, it would help to know how the EMGD has been configure in the BSP and for what output port
Re: [yocto] [PATCH 3/6] crownbay README: add WebTitle & Compliance information
> -Original Message- > From: Zanussi, Tom > Sent: Wednesday, October 24, 2012 9:43 AM > To: Kamble, Nitin A > Cc: yocto@yoctoproject.org; Hart, Darren > Subject: Re: [PATCH 3/6] crownbay README: add WebTitle & Compliance > information > > On Wed, 2012-10-24 at 11:06 -0500, Kamble, Nitin A wrote: > > > > > -Original Message- > > > From: Zanussi, Tom > > > Sent: Tuesday, October 23, 2012 2:16 PM > > > To: Kamble, Nitin A > > > Cc: yocto@yoctoproject.org; Hart, Darren > > > Subject: Re: [PATCH 3/6] crownbay README: add WebTitle & Compliance > > > information > > > > > > On Tue, 2012-10-23 at 13:24 -0700, nitin.a.kam...@intel.com wrote: > > > > From: Nitin A Kamble > > > > > > > > The WebTitle will be used to publish the BSP on the Yocto Project > Website. > > > > And adding the Yocto Project Compliance information for the 1.3 > release. > > > > Also specifying all the layers used from meta-intel repository. > > > > > > > > Signed-off-by: Nitin A Kamble > > > > --- > > > > meta-crownbay/README | 13 +++-- > > > > 1 files changed, 11 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/meta-crownbay/README b/meta-crownbay/README index > > > > 4bc9f31..3996a94 100644 > > > > --- a/meta-crownbay/README > > > > +++ b/meta-crownbay/README > > > > @@ -2,13 +2,22 @@ This README file contains information on > > > > building the meta-crownbay BSP layer, and booting the images > > > > contained in the > > > /binary directory. > > > > Please see the corresponding sections below for details. > > > > > > > > -The Crown Bay platform consists of the Intel Atom Z6xx processor, > > > > +The Crown Bay platform consists of the Intel Atom E6xx processor, > > > > plus the Intel EG20T Platform Controller Hub (Tunnel Creek + Topcliff). > > > > > > > > It also supports the E6xx embedded on-chip graphics via the Intel > > > > Embedded Media and Graphics Driver (EMGD) 1.14 Driver. > > > > > > > > > > > > +WebTitle: Intel Atom E6xx processor with Intel EG20T Controller > > > > +Hub development kit (crownbay) > > > > + > > > > > > I'm not sure this kind of thing should be in the README since we can > > > have multiple downloadable BSPs per layer e.g. crownbay vs > > > crownbay-noemgd. I suppose in keeping with the build system you > > > could have separate WebTitle_crownbay and WebTitle_crownbay- > noemgd > > > lines. ;-) (and it would be nice if you could get rid of the > > > CamelCaps too) > > > > > > Why not put this info in the machine.conf, where we already have > > > fields meant to be machine parseable e.g. > > > > > > #@TYPE: Machine > > > #@NAME: crownbay > > > > > > #@WEBTITLE: ... > > > > > > Or maybe just use the exisiting #@DESCRIPTION for that... > > > > For example in the current way the BSPs are published, this is shown > > on the YP website for crownbay > > > > Intel Atom Processor E660 with Intel Platform Controller Hub EG20T > > Development Kit > > Version: 7.0 "Denzil" > > Release date: 29 Jun 2012 > > Type: BSP > > Download Links: > > Crown Bay > > Crown Bay no EMGD > > Release Notes > > > > So there is one BSP list item per h/w with multiple links to different BSP > tarballs for the same hardware. > > If we move the WebTitle in machine file, then we will have multiple items > in the BSP list for the same hardware. > > I am not sure which is better from the downloader's point of view. But this > is worth considering for this change. > > > > Yeah, on the one hand if we have text that's the same for all BSPs in the > layer, it could go in the README for lack of a better common place. > > But we should consider whether we want to lay things out as the crownbay > above, or more like the cedartrail, which has: > > Intel® Atom™ Processor N2000 and D2000 Series-based Platform (CEDAR > TRAIL) with PowerVR Graphics > > (there's no corresponding -nopvr version available, though I suspect that's an > oversight and would have been something like: > > Intel® Atom™ Processor N2000 and D2000 Series-based Platform (CEDAR > TRAIL) with VESA Graphics > > I'm not sure the field(s) need to map exactly to the page layout, but all the > information should be there to allow the page to be generated or laid out by > hand without having to ask questions, in either case. Did you have any idea > as to how for example to distinguish between the emgd and -noemgd > versions (side note: there's nothing in the current entry that tells the user > what EMGD even is - should it at least be spelled out in the title, or do we > need a separate subtext element to describe > that?) > I think for crownbay we should add in the title "with proprietary IEMGD accelerated graphics drivers", and for crownbay-noemgd we should add "with open source VESA graphics drivers" And then these can go in the machine.conf files. It will make our list of BSPs bigger, but it will be clearer to people, who want to download a BSP from YP site. Shall we add these title requirements in the BSP standard format, so that ot
Re: [yocto] [PATCH 3/6] crownbay README: add WebTitle & Compliance information
On 10/24/2012 09:43 AM, Tom Zanussi wrote: > On Wed, 2012-10-24 at 11:06 -0500, Kamble, Nitin A wrote: >> >>> -Original Message- >>> From: Zanussi, Tom >>> Sent: Tuesday, October 23, 2012 2:16 PM >>> To: Kamble, Nitin A >>> Cc: yocto@yoctoproject.org; Hart, Darren >>> Subject: Re: [PATCH 3/6] crownbay README: add WebTitle & Compliance >>> information >>> >>> On Tue, 2012-10-23 at 13:24 -0700, nitin.a.kam...@intel.com wrote: From: Nitin A Kamble The WebTitle will be used to publish the BSP on the Yocto Project Website. And adding the Yocto Project Compliance information for the 1.3 release. Also specifying all the layers used from meta-intel repository. Signed-off-by: Nitin A Kamble --- meta-crownbay/README | 13 +++-- 1 files changed, 11 insertions(+), 2 deletions(-) diff --git a/meta-crownbay/README b/meta-crownbay/README index 4bc9f31..3996a94 100644 --- a/meta-crownbay/README +++ b/meta-crownbay/README @@ -2,13 +2,22 @@ This README file contains information on building the meta-crownbay BSP layer, and booting the images contained in the >>> /binary directory. Please see the corresponding sections below for details. -The Crown Bay platform consists of the Intel Atom Z6xx processor, +The Crown Bay platform consists of the Intel Atom E6xx processor, plus the Intel EG20T Platform Controller Hub (Tunnel Creek + Topcliff). It also supports the E6xx embedded on-chip graphics via the Intel Embedded Media and Graphics Driver (EMGD) 1.14 Driver. +WebTitle: Intel Atom E6xx processor with Intel EG20T Controller Hub +development kit (crownbay) + >>> >>> I'm not sure this kind of thing should be in the README since we can have >>> multiple downloadable BSPs per layer e.g. crownbay vs crownbay-noemgd. I >>> suppose in keeping with the build system you could have separate >>> WebTitle_crownbay and WebTitle_crownbay-noemgd lines. ;-) (and it would >>> be nice if you could get rid of the CamelCaps too) >>> >>> Why not put this info in the machine.conf, where we already have fields >>> meant to be machine parseable e.g. >>> >>> #@TYPE: Machine >>> #@NAME: crownbay >>> >>> #@WEBTITLE: ... >>> >>> Or maybe just use the exisiting #@DESCRIPTION for that... >> >> For example in the current way the BSPs are published, this is shown on the >> YP website for crownbay >> >> Intel Atom Processor E660 with Intel Platform Controller Hub EG20T >> Development Kit >> Version: 7.0 "Denzil" >> Release date: 29 Jun 2012 >> Type: BSP >> Download Links: >> Crown Bay >> Crown Bay no EMGD >> Release Notes >> >> So there is one BSP list item per h/w with multiple links to different BSP >> tarballs for the same hardware. >> If we move the WebTitle in machine file, then we will have multiple items in >> the BSP list for the same hardware. >> I am not sure which is better from the downloader's point of view. But this >> is worth considering for this change. >> > > Yeah, on the one hand if we have text that's the same for all BSPs in > the layer, it could go in the README for lack of a better common place. > > But we should consider whether we want to lay things out as the crownbay > above, or more like the cedartrail, which has: > > Intel® Atom™ Processor N2000 and D2000 Series-based Platform (CEDAR > TRAIL) with PowerVR Graphics > > (there's no corresponding -nopvr version available, though I suspect > that's an oversight and would have been something like: > > Intel® Atom™ Processor N2000 and D2000 Series-based Platform (CEDAR > TRAIL) with VESA Graphics > > I'm not sure the field(s) need to map exactly to the page layout, but > all the information should be there to allow the page to be generated or > laid out by hand without having to ask questions, in either case. Did > you have any idea as to how for example to distinguish between the emgd > and -noemgd versions (side note: there's nothing in the current entry > that tells the user what EMGD even is - should it at least be spelled > out in the title, or do we need a separate subtext element to describe > that?) I like the Cedar Trail description with the graphics mentioned explicitly. Doing this in the machine conf as Tom original suggested makes perfect sense to me. If that means two entries for some machines, that's preferable to me than extra complexity of subtexts, etc. -- 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] Ubuntu 10.04 don't support mirror option with parameter
On Wednesday 24 October 2012 18:30:12 Stefan Herbrechtsmeier wrote: > the git version of Ubuntu 10.04 is to old to support mirror option with > parameter which is used by the bitbake fetch2. > > Regards, >Stefan > > > DEBUG: ... git remote add --mirror=fetch origin > git://git.yoctoproject.org/opkg-utils > ERROR: Fetcher failure: Fetch command failed with exit code 129, output: > error: option `mirror' takes no value > usage: git remote add [] > > -f, --fetch fetch the remote branches > -t, --track branch(es) to track > -m, --master >master branch > --mirror no separate remotes > Which version of the build system are you using? In master and the upcoming danny / 1.3 release we have a check in the bitbake wrapper script to determine if a newer version of git needs to be built (if the host's version of git is older than 1.7.5); if so we build one (git-replacement-native). The denzil / 1.2 release does not have this, however. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 3/6] crownbay README: add WebTitle & Compliance information
On Wed, 2012-10-24 at 11:06 -0500, Kamble, Nitin A wrote: > > > -Original Message- > > From: Zanussi, Tom > > Sent: Tuesday, October 23, 2012 2:16 PM > > To: Kamble, Nitin A > > Cc: yocto@yoctoproject.org; Hart, Darren > > Subject: Re: [PATCH 3/6] crownbay README: add WebTitle & Compliance > > information > > > > On Tue, 2012-10-23 at 13:24 -0700, nitin.a.kam...@intel.com wrote: > > > From: Nitin A Kamble > > > > > > The WebTitle will be used to publish the BSP on the Yocto Project Website. > > > And adding the Yocto Project Compliance information for the 1.3 release. > > > Also specifying all the layers used from meta-intel repository. > > > > > > Signed-off-by: Nitin A Kamble > > > --- > > > meta-crownbay/README | 13 +++-- > > > 1 files changed, 11 insertions(+), 2 deletions(-) > > > > > > diff --git a/meta-crownbay/README b/meta-crownbay/README index > > > 4bc9f31..3996a94 100644 > > > --- a/meta-crownbay/README > > > +++ b/meta-crownbay/README > > > @@ -2,13 +2,22 @@ This README file contains information on building > > > the meta-crownbay BSP layer, and booting the images contained in the > > /binary directory. > > > Please see the corresponding sections below for details. > > > > > > -The Crown Bay platform consists of the Intel Atom Z6xx processor, > > > +The Crown Bay platform consists of the Intel Atom E6xx processor, > > > plus the Intel EG20T Platform Controller Hub (Tunnel Creek + Topcliff). > > > > > > It also supports the E6xx embedded on-chip graphics via the Intel > > > Embedded Media and Graphics Driver (EMGD) 1.14 Driver. > > > > > > > > > +WebTitle: Intel Atom E6xx processor with Intel EG20T Controller Hub > > > +development kit (crownbay) > > > + > > > > I'm not sure this kind of thing should be in the README since we can have > > multiple downloadable BSPs per layer e.g. crownbay vs crownbay-noemgd. I > > suppose in keeping with the build system you could have separate > > WebTitle_crownbay and WebTitle_crownbay-noemgd lines. ;-) (and it would > > be nice if you could get rid of the CamelCaps too) > > > > Why not put this info in the machine.conf, where we already have fields > > meant to be machine parseable e.g. > > > > #@TYPE: Machine > > #@NAME: crownbay > > > > #@WEBTITLE: ... > > > > Or maybe just use the exisiting #@DESCRIPTION for that... > > For example in the current way the BSPs are published, this is shown on the > YP website for crownbay > > Intel Atom Processor E660 with Intel Platform Controller Hub EG20T > Development Kit > Version: 7.0 "Denzil" > Release date: 29 Jun 2012 > Type: BSP > Download Links: > Crown Bay > Crown Bay no EMGD > Release Notes > > So there is one BSP list item per h/w with multiple links to different BSP > tarballs for the same hardware. > If we move the WebTitle in machine file, then we will have multiple items in > the BSP list for the same hardware. > I am not sure which is better from the downloader's point of view. But this > is worth considering for this change. > Yeah, on the one hand if we have text that's the same for all BSPs in the layer, it could go in the README for lack of a better common place. But we should consider whether we want to lay things out as the crownbay above, or more like the cedartrail, which has: Intel® Atom™ Processor N2000 and D2000 Series-based Platform (CEDAR TRAIL) with PowerVR Graphics (there's no corresponding -nopvr version available, though I suspect that's an oversight and would have been something like: Intel® Atom™ Processor N2000 and D2000 Series-based Platform (CEDAR TRAIL) with VESA Graphics I'm not sure the field(s) need to map exactly to the page layout, but all the information should be there to allow the page to be generated or laid out by hand without having to ask questions, in either case. Did you have any idea as to how for example to distinguish between the emgd and -noemgd versions (side note: there's nothing in the current entry that tells the user what EMGD even is - should it at least be spelled out in the title, or do we need a separate subtext element to describe that?) Tom > > > > > + > > > +Compliance: > > > + > > > > For consistency with the rest of the README, please remove the colon and > > clean up the underlining. > > Will do. > > Thanks, > Nitin > > > > Thanks, > > > > Tom > > > > > +This BSP is compliant with Yocto Project as per requirements listed here: > > > +http://www.yoctoproject.org/yocto-project-compatible-registration > > > + > > > + > > > Dependencies > > > > > > > > > @@ -22,7 +31,7 @@ This layer depends on: > > >branch: master > > > > > >URI: git://git.yoctoproject.org/meta-intel > > > - layers: intel > > > + layers: meta-intel, meta-crownbay > > >branch: master > > > > > > > > > ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto vs LDAT
On 10/24/12 10:52 AM, Evade Flow wrote: I've been quietly experimenting with Yocto at work for several weeks now, flying under everybody's radar; but my bosses have discovered what I've been doing and I now need to defend my position--not just from the perspective of my little team, but for the whole company(!) Welcome. ;) I work for an automotive supplier whose current big project uses LDAT. We also have a two-year-old 'proof-of-concept' demo system that was assembled using LDAT. The guys that sign my checks want to know: why should they not remain with LDAT for future projects? I've been asked to put together some kind of cost/benefit analysis to justify switching to Yocto. (I am a Wind River employee, but I'm not in sales -- so keep that in mind as I answer this.) LDAT is our old build environment. It was our first attempt at an open build system, that never really took off.. The Yocto Project succeeded in the vision that we have, and our recent 5.0 product is now Yocto Project (1.2 - Denzil) based. If you are coming from an LDAT experience and moving to our Wind River Yocto Project based 5.0 product, many of the tools and processes you are already familiar with can continue to be used -- but of course there are differences. In any case (commerical or not), you really do want to eventually move to the Yocto Project based system. This will allow you to have a forward path to future revisions of products, support and infrastructure from 'Yocto Project Compatible' commercial providers. When you create a layer, a kernel modification, new applications, etc -- by being compatible with the Yocto Project, your customers (who I am assuming use your software to build the final product) will be able to use Yocto Project, GENIVI (IVI) and compatible software to more easily construct their products. There is a clear integration and compatibility path moving forward. (Note, our WR IVI group has Yocto Project compatible software available for customers as well.) Unfortunately, I'm ill-equipped to do any such thing, as I don't have much experience with LDAT. My understanding is that the newest version of Wind River Linux uses Yocto rather than LDAT. And since Intel (Yocto's primary corporate sponsor) purchased Wind River in 2009, it doesn't appear that LDAT has a future. Is using LDAT for new projects even a viable option? How difficult is it to 'port' LDAT layers to Yocto? What I generally tell customers. If you need an existing stable platform for product development (short-term, 6-9 month release cycle) that our LDAT platform is what you want -today-. It's stable well supported, etc. However, if you are working for a product in the 9-16 month range, or working on long-term development -- the Yocto Project is what you want to start with. Either the Open Source or one of the compatible commercial variants. This is what is going to allow you to do your work today, and make it reusable in future products. There are a -lot- of products being built on LDAT today, and I would not advocate changing course for something that is coming to market soon. Basically, I'm being asked: "Why should we do this, and what will it cost?" Any suggestions for how to answer these questions? From a cost perspective, lets assume you will be using our commercial versions. (Again, I'm not in sales... so I can't directly comment on all of the costs, so much of this is my assumptions.) I would assume that the commercial support/maintenance agreements would be roughly the same or perhaps even slightly cheaper. In otherwords, this likely should not affect your decision. However, the conversion of your software from the LDAT format to the Yocto Project recipe format will take time and effort. This time and effort does have a cost associated with it -- but if this is a long term product for your company, at some point you will have to have this expense to continue moving forward with products you can sell to your customers. What you need to determine is simply when do you need to make this change, and when to absorb these costs. Long term though, the stability of the Yocto Project components, recipes in layers and configuration, you should be able to more easily manage change and costs. I hope this helps -- and I do intend the above to be generic for anyone coming from a non-Yocto Project compliant commercial or Roll-Your-Own distribution to the Yocto Project. If you need additional information on any Wind River specific products, let me know (private email) and I'll get you in contact with the right folks. --Mark ___ 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] Ubuntu 10.04 don't support mirror option with parameter
Hi, the git version of Ubuntu 10.04 is to old to support mirror option with parameter which is used by the bitbake fetch2. Regards, Stefan DEBUG: ... git remote add --mirror=fetch origin git://git.yoctoproject.org/opkg-utils ERROR: Fetcher failure: Fetch command failed with exit code 129, output: error: option `mirror' takes no value usage: git remote add [] -f, --fetch fetch the remote branches -t, --track branch(es) to track -m, --master master branch --mirror no separate remotes ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 2/2] psplash: use correct blue offset value for BGR888
From: Aws Ismail
Author: Aws Ismail
Date: Thu Aug 16 11:06:13 2012 -0400
Use correct blue offset value for BGR888
fs->blue_offset should be compared to 16 instead
of 8 in order to detect BGR.
Credit goes to Ulrich Feichter
for detecting this.
Signed-off-by: Aws Ismail
Signed-off-by: Saul Wold
---
psplash-fb.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/psplash-fb.c b/psplash-fb.c
index 72505b0..1db4fde 100644
--- a/psplash-fb.c
+++ b/psplash-fb.c
@@ -185,7 +185,7 @@ psplash_fb_new (int angle)
fb->rgbmode = RGB888;
} else if (fb->red_offset == 0 && fb->red_length == 8 &&
fb->green_offset == 8 && fb->green_length == 8 &&
- fb->blue_offset == 8 && fb->blue_length == 8) {
+ fb->blue_offset == 16 && fb->blue_length == 8) {
fb->rgbmode = BGR888;
} else {
fb->rgbmode = GENERIC;
--
1.7.7.6
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/2] psplash: Trivial, cleanup some comments.
From: Marc Ferland This patch fixes some minor comment mistakes. Signed-off-by: Marc Ferland Signed-off-by: Saul Wold --- psplash-colors.h |2 +- psplash-console.c |2 +- psplash-console.h |2 +- psplash-fb.c |2 +- psplash-fb.h |2 +- psplash-write.c |2 +- psplash.c |4 ++-- psplash.h |2 +- 8 files changed, 9 insertions(+), 9 deletions(-) diff --git a/psplash-colors.h b/psplash-colors.h index d701089..d574afa 100644 --- a/psplash-colors.h +++ b/psplash-colors.h @@ -1,5 +1,5 @@ /* - * pslash - a lightweight framebuffer splashscreen for embedded devices. + * psplash - a lightweight framebuffer splashscreen for embedded devices. * * Copyright (c) 2012 sleep(5) ltd * Author: Tomas Frydrych diff --git a/psplash-console.c b/psplash-console.c index 9b7dfb9..1ee49e6 100644 --- a/psplash-console.c +++ b/psplash-console.c @@ -1,5 +1,5 @@ /* - * pslash - a lightweight framebuffer splashscreen for embedded devices. + * psplash - a lightweight framebuffer splashscreen for embedded devices. * * Copyright (c) 2006 Matthew Allum * diff --git a/psplash-console.h b/psplash-console.h index c444d27..2cf7555 100644 --- a/psplash-console.h +++ b/psplash-console.h @@ -1,5 +1,5 @@ /* - * pslash - a lightweight framebuffer splashscreen for embedded devices. + * psplash - a lightweight framebuffer splashscreen for embedded devices. * * Copyright (c) 2006 Matthew Allum * diff --git a/psplash-fb.c b/psplash-fb.c index 71740cd..72505b0 100644 --- a/psplash-fb.c +++ b/psplash-fb.c @@ -1,5 +1,5 @@ /* - * pslash - a lightweight framebuffer splashscreen for embedded devices. + * psplash - a lightweight framebuffer splashscreen for embedded devices. * * Copyright (c) 2006 Matthew Allum * diff --git a/psplash-fb.h b/psplash-fb.h index ef5b39e..244ab67 100644 --- a/psplash-fb.h +++ b/psplash-fb.h @@ -1,5 +1,5 @@ /* - * pslash - a lightweight framebuffer splashscreen for embedded devices. + * psplash - a lightweight framebuffer splashscreen for embedded devices. * * Copyright (c) 2006 Matthew Allum * diff --git a/psplash-write.c b/psplash-write.c index 3fdba95..1a81270 100644 --- a/psplash-write.c +++ b/psplash-write.c @@ -1,5 +1,5 @@ /* - * pslash - a lightweight framebuffer splashscreen for embedded devices. + * psplash - a lightweight framebuffer splashscreen for embedded devices. * * Copyright (c) 2006 Matthew Allum * diff --git a/psplash.c b/psplash.c index 09cf0d0..aa6568a 100644 --- a/psplash.c +++ b/psplash.c @@ -1,5 +1,5 @@ /* - * pslash - a lightweight framebuffer splashscreen for embedded devices. + * psplash - a lightweight framebuffer splashscreen for embedded devices. * * Copyright (c) 2006 Matthew Allum * @@ -263,7 +263,7 @@ main (int argc, char** argv) goto fb_fail; } - /* Clear the background with #ecece1 */ + /* Clear screen with background color */ psplash_fb_draw_rect (fb, 0, 0, fb->width, fb->height, PSPLASH_BACKGROUND_COLOR); diff --git a/psplash.h b/psplash.h index f78c117..9b60ce1 100644 --- a/psplash.h +++ b/psplash.h @@ -1,5 +1,5 @@ /* - * pslash - a lightweight framebuffer splashscreen for embedded devices. + * psplash - a lightweight framebuffer splashscreen for embedded devices. * * Copyright (c) 2006 Matthew Allum * -- 1.7.7.6 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 3/6] crownbay README: add WebTitle & Compliance information
> -Original Message- > From: Zanussi, Tom > Sent: Tuesday, October 23, 2012 2:16 PM > To: Kamble, Nitin A > Cc: yocto@yoctoproject.org; Hart, Darren > Subject: Re: [PATCH 3/6] crownbay README: add WebTitle & Compliance > information > > On Tue, 2012-10-23 at 13:24 -0700, nitin.a.kam...@intel.com wrote: > > From: Nitin A Kamble > > > > The WebTitle will be used to publish the BSP on the Yocto Project Website. > > And adding the Yocto Project Compliance information for the 1.3 release. > > Also specifying all the layers used from meta-intel repository. > > > > Signed-off-by: Nitin A Kamble > > --- > > meta-crownbay/README | 13 +++-- > > 1 files changed, 11 insertions(+), 2 deletions(-) > > > > diff --git a/meta-crownbay/README b/meta-crownbay/README index > > 4bc9f31..3996a94 100644 > > --- a/meta-crownbay/README > > +++ b/meta-crownbay/README > > @@ -2,13 +2,22 @@ This README file contains information on building > > the meta-crownbay BSP layer, and booting the images contained in the > /binary directory. > > Please see the corresponding sections below for details. > > > > -The Crown Bay platform consists of the Intel Atom Z6xx processor, > > +The Crown Bay platform consists of the Intel Atom E6xx processor, > > plus the Intel EG20T Platform Controller Hub (Tunnel Creek + Topcliff). > > > > It also supports the E6xx embedded on-chip graphics via the Intel > > Embedded Media and Graphics Driver (EMGD) 1.14 Driver. > > > > > > +WebTitle: Intel Atom E6xx processor with Intel EG20T Controller Hub > > +development kit (crownbay) > > + > > I'm not sure this kind of thing should be in the README since we can have > multiple downloadable BSPs per layer e.g. crownbay vs crownbay-noemgd. I > suppose in keeping with the build system you could have separate > WebTitle_crownbay and WebTitle_crownbay-noemgd lines. ;-) (and it would > be nice if you could get rid of the CamelCaps too) > > Why not put this info in the machine.conf, where we already have fields > meant to be machine parseable e.g. > > #@TYPE: Machine > #@NAME: crownbay > > #@WEBTITLE: ... > > Or maybe just use the exisiting #@DESCRIPTION for that... For example in the current way the BSPs are published, this is shown on the YP website for crownbay Intel Atom Processor E660 with Intel Platform Controller Hub EG20T Development Kit Version: 7.0 "Denzil" Release date: 29 Jun 2012 Type: BSP Download Links: Crown Bay Crown Bay no EMGD Release Notes So there is one BSP list item per h/w with multiple links to different BSP tarballs for the same hardware. If we move the WebTitle in machine file, then we will have multiple items in the BSP list for the same hardware. I am not sure which is better from the downloader's point of view. But this is worth considering for this change. > > > + > > +Compliance: > > + > > For consistency with the rest of the README, please remove the colon and > clean up the underlining. Will do. Thanks, Nitin > > Thanks, > > Tom > > > +This BSP is compliant with Yocto Project as per requirements listed here: > > +http://www.yoctoproject.org/yocto-project-compatible-registration > > + > > + > > Dependencies > > > > > > @@ -22,7 +31,7 @@ This layer depends on: > >branch: master > > > >URI: git://git.yoctoproject.org/meta-intel > > - layers: intel > > + layers: meta-intel, meta-crownbay > >branch: master > > > > > ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto vs LDAT
I've been quietly experimenting with Yocto at work for several weeks now, flying under everybody's radar; but my bosses have discovered what I've been doing and I now need to defend my position--not just from the perspective of my little team, but for the whole company(!) I work for an automotive supplier whose current big project uses LDAT. We also have a two-year-old 'proof-of-concept' demo system that was assembled using LDAT. The guys that sign my checks want to know: why should they not remain with LDAT for future projects? I've been asked to put together some kind of cost/benefit analysis to justify switching to Yocto. Unfortunately, I'm ill-equipped to do any such thing, as I don't have much experience with LDAT. My understanding is that the newest version of Wind River Linux uses Yocto rather than LDAT. And since Intel (Yocto's primary corporate sponsor) purchased Wind River in 2009, it doesn't appear that LDAT has a future. Is using LDAT for new projects even a viable option? How difficult is it to 'port' LDAT layers to Yocto? Basically, I'm being asked: "Why should we do this, and what will it cost?" Any suggestions for how to answer these questions? ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/1] meta-intel: fix VA_FEATURES assignment in machine configs
From: Tom Zanussi
commit 2231d38 (meta-intel: make video acceleration choice dependent
on LICENSE_FLAGS) inadvertently also changed '?=' to a hard
assignment, making it hard to override as intended. This changes it
back.
Signed-off-by: Tom Zanussi
---
meta-cedartrail/conf/machine/cedartrail.conf | 2 +-
meta-chiefriver/conf/machine/chiefriver.conf | 2 +-
meta-crownbay/conf/machine/crownbay.conf | 2 +-
meta-fri2/conf/machine/fri2.conf | 2 +-
meta-sugarbay/conf/machine/sugarbay.conf | 2 +-
meta-sys940x/conf/machine/sys940x.conf | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/meta-cedartrail/conf/machine/cedartrail.conf
b/meta-cedartrail/conf/machine/cedartrail.conf
index d8b6bc0..1463ae2 100644
--- a/meta-cedartrail/conf/machine/cedartrail.conf
+++ b/meta-cedartrail/conf/machine/cedartrail.conf
@@ -22,6 +22,6 @@ SYSLINUX_OPTS = "serial 0 115200"
SERIAL_CONSOLE = "115200 ttyS0"
APPEND += "console=ttyS0,115200 console=tty0"
-VA_FEATURES = "gst-va-intel va-intel"
+VA_FEATURES ?= "gst-va-intel va-intel"
MACHINE_EXTRA_RRECOMMENDS += "${VA_FEATURES}"
diff --git a/meta-chiefriver/conf/machine/chiefriver.conf
b/meta-chiefriver/conf/machine/chiefriver.conf
index b8b8754..6d8d3a5 100644
--- a/meta-chiefriver/conf/machine/chiefriver.conf
+++ b/meta-chiefriver/conf/machine/chiefriver.conf
@@ -15,6 +15,6 @@ XSERVER ?= "${XSERVER_IA32_BASE} \
${XSERVER_IA32_I965} \
"
-VA_FEATURES = "gst-va-intel va-intel"
+VA_FEATURES ?= "gst-va-intel va-intel"
MACHINE_EXTRA_RRECOMMENDS += "${VA_FEATURES} lms"
diff --git a/meta-crownbay/conf/machine/crownbay.conf
b/meta-crownbay/conf/machine/crownbay.conf
index d56ef64..624ca56 100644
--- a/meta-crownbay/conf/machine/crownbay.conf
+++ b/meta-crownbay/conf/machine/crownbay.conf
@@ -23,6 +23,6 @@ PREFERRED_VERSION_xf86-input-evdev ?= "2.6.0"
APPEND += "video=vesafb vga=0x318 vmalloc=256MB"
-VA_FEATURES = "gst-va-intel va-intel"
+VA_FEATURES ?= "gst-va-intel va-intel"
MACHINE_EXTRA_RRECOMMENDS += "${VA_FEATURES}"
diff --git a/meta-fri2/conf/machine/fri2.conf b/meta-fri2/conf/machine/fri2.conf
index 587b976..19f2fb0 100644
--- a/meta-fri2/conf/machine/fri2.conf
+++ b/meta-fri2/conf/machine/fri2.conf
@@ -8,7 +8,7 @@ require conf/machine/include/tune-atom.inc
require conf/machine/include/ia32-base.inc
require conf/machine/include/meta-intel.inc
-VA_FEATURES = "gst-va-intel va-intel"
+VA_FEATURES ?= "gst-va-intel va-intel"
MACHINE_FEATURES += "wifi 3g pcbios efi va-impl-mixvideo"
MACHINE_EXTRA_RRECOMMENDS += "linux-firmware-iwlwifi-6000g2a-5 ${VA_FEATURES}"
diff --git a/meta-sugarbay/conf/machine/sugarbay.conf
b/meta-sugarbay/conf/machine/sugarbay.conf
index 1d0e68d..616c2c5 100644
--- a/meta-sugarbay/conf/machine/sugarbay.conf
+++ b/meta-sugarbay/conf/machine/sugarbay.conf
@@ -16,6 +16,6 @@ XSERVER ?= "${XSERVER_IA32_BASE} \
${XSERVER_IA32_I965} \
"
-VA_FEATURES = "gst-va-intel va-intel"
+VA_FEATURES ?= "gst-va-intel va-intel"
MACHINE_EXTRA_RRECOMMENDS += "${VA_FEATURES}"
diff --git a/meta-sys940x/conf/machine/sys940x.conf
b/meta-sys940x/conf/machine/sys940x.conf
index eefca59..44de796 100644
--- a/meta-sys940x/conf/machine/sys940x.conf
+++ b/meta-sys940x/conf/machine/sys940x.conf
@@ -26,6 +26,6 @@ PREFERRED_VERSION_emgd-driver-bin ?= "1.14"
SERIAL_CONSOLE = "115200 ttyS0"
APPEND += "console=ttyS0,115200 console=tty0"
-VA_FEATURES = "gst-va-intel va-intel"
+VA_FEATURES ?= "gst-va-intel va-intel"
MACHINE_EXTRA_RRECOMMENDS += "${VA_FEATURES}"
--
1.7.11.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 0/1] VA_FEATURES typo fix
From: Tom Zanussi This fixes a problem introduced by a recent commit and noticed by Paul Eggleton. The following changes since commit f502e7493694c487767f60df232055bc7b854e69: gstreamer-vaapi: add missing build dependencies (2012-10-23 07:43:46 -0500) are available in the git repository at: git://git.yoctoproject.org/meta-intel-contrib.git tzanussi/va-features-assign-fix http://git.yoctoproject.org/cgit.cgi//log/?h=tzanussi/va-features-assign-fix Tom Zanussi (1): meta-intel: fix VA_FEATURES assignment in machine configs meta-cedartrail/conf/machine/cedartrail.conf | 2 +- meta-chiefriver/conf/machine/chiefriver.conf | 2 +- meta-crownbay/conf/machine/crownbay.conf | 2 +- meta-fri2/conf/machine/fri2.conf | 2 +- meta-sugarbay/conf/machine/sugarbay.conf | 2 +- meta-sys940x/conf/machine/sys940x.conf | 2 +- 6 files changed, 6 insertions(+), 6 deletions(-) -- 1.7.11.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [opkg-utils][PATCH 1/1] opkg-make-index: fix mis-indented else:
On Thu, 2012-10-04 at 18:29 +0200, Martin Jansa wrote:
> From: Marc Olzheim
>
> Signed-off-by: Martin Jansa
> ---
> opkg-make-index | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/opkg-make-index b/opkg-make-index
> index 1c3a8e1..44fa64d 100755
> --- a/opkg-make-index
> +++ b/opkg-make-index
> @@ -213,7 +213,7 @@ if filelist_filename:
> (h,t) = os.path.split(fn)
> if not t: continue
> if t not in files: files[t] = name+':'+fn
> -else: files[t] = files[t] + ',' + name+':'+fn
> +else: files[t] = files[t] + ',' + name+':'+fn
>
> tmp_filelist_filename = ("%s.%d" % (filelist_filename, os.getpid()))
> f = open(tmp_filelist_filename, "w")
Merged to master, thanks.
Richard
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH resend][opkg-utils] opkg.py/opkg-build: fix creation of tar archives
On Wed, 2012-10-24 at 12:53 +0200, Steffen Sledz wrote: > Since openSUSE 12.2 the installed tar uses posix instead of gnu encoding > by default. This format is not fully supported by opkg and results in > ipk packages not installable at the target. > > Collected errors: > * get_header_tar: Unknown typeflag: 0x78: Success. > * get_header_tar: Unknown typeflag: 0x78: Success. > * get_header_tar: Unknown typeflag: 0x78: Success. > * extract_archive: Don't know how to handle > /var/lib/opkg/tmp/opkg-mg997m/chicken-bin-fGRvr4/PaxHeaders.17512/.: No such > file or directory. > * get_header_tar: Unknown typeflag: 0x78: No such file or directory. > * get_header_tar: Unknown typeflag: 0x78: No such file or directory. > ... > > Signed-off-by: Steffen Sledz > --- > opkg-build |6 +++--- > opkg.py|6 +++--- > 2 files changed, 6 insertions(+), 6 deletions(-) Merged to master, thanks. Richard ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
