Re: [yocto] core-image-sato keyboard
What is your bootargs ? We also encountered this issue long time ago. The following bootargs line would cause this problem: setenv bootargs 'console=tty0 console=ttyO2,115200n8 root=/dev/mmcblk0p2 rootwait rootfstype=ext3 ro' Try to change "console=tty0 console=ttyO2,115200n8" to "console=ttyO2,115200n8 console=tty0" . Please refer the bug 1823 (https://bugzilla.yoctoproject.org/show_bug.cgi?id=1823). Thanks, Yi On 2012?10?07? 03:20, Edward Vidal wrote: Hello, Just built core-image-sato for beagleboard xM C. I have a usb keyboard and mouse connected. The Mouse works but not the keyboard when Terminal is selected. The virtual keyboard works okay. The following is what I see with dmesg. usb 1-2.2: new low-speed USB device number 4 using ehci-omap input: CHESEN USB Keyboard as /devices/platform/usbhs_omap/ehci-omap.0/usb1/1-2/1-2.2/1-2.2:1.0/input/input 0 generic-usb 0003:0A81:0101.0001: input: USB HID v1.10 Keyboard [CHESEN USB Keyboard] on usb-ehci-omap.0-2.2 /input0 input: CHESEN USB Keyboard as /devices/platform/usbhs_omap/ehci-omap.0/usb1/1-2/1-2.2/1-2.2:1.1/input/input 1 generic-usb 0003:0A81:0101.0002: input: USB HID v1.10 Device [CHESEN USB Keyboard] on usb-ehci-omap.0-2.2/i nput1 The file /etc/formfactor/machconfig # Assume a USB mouse and touchscreen are connected HAVE_TOUCHSCREEN=0 HAVE_KEYBOARD=1 I chmod +x /etc/formfactor/config and /etc/formfactor/matchconfig Thanks in advance for any help ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Meta Intel / Cedartrail / Denzil - how to get unionfs in the kernel
On 7 Oct 2012, at 22:41, Bruce Ashfield wrote: > On Sun, Oct 7, 2012 at 6:08 PM, Chris Tapp wrote: >> On 7 Oct 2012, at 03:00, Saxena, Rahul wrote: >> >>> Try adding the unionfs feature (below) to your kernel: >>> >>> http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.0/tree/meta/cfg/kernel-cache/features/unionfs?h=meta >>> >>> create a file my_cedartrail.scc with following line: >>> include features/unionfs/unionfs.scc >>> >>> put this file in a dir linux-yocto, the dir being created in >>> >>> meta-cedartrail/recipes-kernel/linux >>> >>> add following line in >>> meta-cedartrail/recipes-kernel/Linux/linux-yocto_3.0.bbappend >>> >>> SRC_URI +="file://my_cedartrail.scc" >> >> Thanks - I thought just running 'menuconfig' would allow me to enable it >> (for a quick test). >> >> However, this still doesn't seem to be working. I can see that >> 'my_cedartrail.scc' gets fetched in to the build area, but I still don't see >> CONFIG_UNION_FS if I run 'menuconfig'. There is also no 'unionfs' folder in >> fs/ of the build tree. >> >> Also, if I specify an invalid feature (e.g. feature2/unionfs/unionfs.scc) >> I'm not seeing any diagnostic. > > unionfs was never merged to the 3.0 kernel, I re-added it to the development > trees for 3.2 and the 3.4 kernel (aufs for the 3.6 tree at the moment). The > meta > data is carried forward from the older kernels as a placeholder and is > documented > in the .scc file itself: > > --- > kconf non-hardware unionfs.cfg > > # commented pending update to a newer version ported to 2.6.35+ > # patch unionfs-2.5.4-integration.patch > --- > > So to get unionfs in the 3.0 kernel, we'd need a port .. but since > we've moved on > quite a bit past 3.0, I don't know of any pending ports myself. Thanks Bruce. I guess I need to ask the Intel guys if there are any plans to move Cedartrail on from 3.0 ? > Cheers, > > Bruce > >> >>> >>> -Original Message- >>> From: yocto-boun...@yoctoproject.org >>> [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Chris Tapp >>> Sent: Saturday, October 06, 2012 5:43 PM >>> To: yocto@yoctoproject.org Project >>> Subject: [yocto] Meta Intel / Cedartrail / Denzil - how to get unionfs in >>> the kernel >>> >>> I' trying to enable unionfs in the 3.0.32 kernel for the cedartrail BSP >>> under Denzil 7.0.1. >>> >>> However, the CONFIG_UNION_FS config flag isn't in the .config ... >>> >>> Is there something else I need to enable, or do I need to find another way? >>> >>> Chris Tapp >>> >>> opensou...@keylevel.com >>> www.keylevel.com >>> >>> >>> >>> ___ >>> yocto mailing list >>> yocto@yoctoproject.org >>> https://lists.yoctoproject.org/listinfo/yocto >> >> Chris Tapp >> >> opensou...@keylevel.com >> www.keylevel.com >> >> >> >> ___ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto > > > > -- > "Thou shalt not follow the NULL pointer, for chaos and madness await > thee at its end" Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] meta-gumstix proceedings
Hi, as some of you might know, gumstix created an official BSP layer [1][2]. To avoid confusion I renamed my layer from meta-gumstix to meta-gumstix-community [3]. Users should either switch to the official meta-gumstix layer or rename meta-gumstix to meta-gumstix-community [3] in git configuration (users of angstrom-setup-scripts should also change the name in layers.txt). Andreas [1] http://sourceforge.net/mailarchive/message.php?msg_id=29914700 [2] https://github.com/gumstix/meta-gumstix [3] https://gitorious.org/schnitzeltony-oe-meta/meta-gumstix-community ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-gumstix proceedings
Hi Andreas, On Monday 08 October 2012 12:54:46 Andreas Müller wrote: > as some of you might know, gumstix created an official BSP layer > [1][2]. To avoid confusion I renamed my layer from meta-gumstix to > meta-gumstix-community [3]. Users should either switch to the official > meta-gumstix layer or rename meta-gumstix to meta-gumstix-community > [3] in git configuration (users of angstrom-setup-scripts should also > change the name in layers.txt). So what should we do with the layer index [4]? Do we list both? What is the delta between them, and is there a hope that there will be only one layer at some point? Cheers, Paul [4] http://www.openembedded.org/wiki/LayerIndex -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Meta Intel / Cedartrail / Denzil - how to get unionfs in the kernel
On Mon, Oct 8, 2012 at 3:58 AM, Chris Tapp wrote: > On 7 Oct 2012, at 22:41, Bruce Ashfield wrote: > >> On Sun, Oct 7, 2012 at 6:08 PM, Chris Tapp wrote: >>> On 7 Oct 2012, at 03:00, Saxena, Rahul wrote: >>> Try adding the unionfs feature (below) to your kernel: http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.0/tree/meta/cfg/kernel-cache/features/unionfs?h=meta create a file my_cedartrail.scc with following line: include features/unionfs/unionfs.scc put this file in a dir linux-yocto, the dir being created in meta-cedartrail/recipes-kernel/linux add following line in meta-cedartrail/recipes-kernel/Linux/linux-yocto_3.0.bbappend SRC_URI +="file://my_cedartrail.scc" >>> >>> Thanks - I thought just running 'menuconfig' would allow me to enable it >>> (for a quick test). >>> >>> However, this still doesn't seem to be working. I can see that >>> 'my_cedartrail.scc' gets fetched in to the build area, but I still don't >>> see CONFIG_UNION_FS if I run 'menuconfig'. There is also no 'unionfs' >>> folder in fs/ of the build tree. >>> >>> Also, if I specify an invalid feature (e.g. feature2/unionfs/unionfs.scc) >>> I'm not seeing any diagnostic. >> >> unionfs was never merged to the 3.0 kernel, I re-added it to the development >> trees for 3.2 and the 3.4 kernel (aufs for the 3.6 tree at the moment). The >> meta >> data is carried forward from the older kernels as a placeholder and is >> documented >> in the .scc file itself: >> >> --- >> kconf non-hardware unionfs.cfg >> >> # commented pending update to a newer version ported to 2.6.35+ >> # patch unionfs-2.5.4-integration.patch >> --- >> >> So to get unionfs in the 3.0 kernel, we'd need a port .. but since >> we've moved on >> quite a bit past 3.0, I don't know of any pending ports myself. > > Thanks Bruce. > > I guess I need to ask the Intel guys if there are any plans to move > Cedartrail on from 3.0 ? It will have to happen post yocto 1.3 (as far as I know), since the 3.0 kernel will be dropped at that point. For the short term, it's likely easier to backport/update unionfs than it would be to update the BSP .. but I can't speak for the time to be spent doing it :) Cheers, Bruce > >> Cheers, >> >> Bruce >> >>> -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Chris Tapp Sent: Saturday, October 06, 2012 5:43 PM To: yocto@yoctoproject.org Project Subject: [yocto] Meta Intel / Cedartrail / Denzil - how to get unionfs in the kernel I' trying to enable unionfs in the 3.0.32 kernel for the cedartrail BSP under Denzil 7.0.1. However, the CONFIG_UNION_FS config flag isn't in the .config ... Is there something else I need to enable, or do I need to find another way? Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto >>> >>> Chris Tapp >>> >>> opensou...@keylevel.com >>> www.keylevel.com >>> >>> >>> >>> ___ >>> yocto mailing list >>> yocto@yoctoproject.org >>> https://lists.yoctoproject.org/listinfo/yocto >> >> >> >> -- >> "Thou shalt not follow the NULL pointer, for chaos and madness await >> thee at its end" > > Chris Tapp > > opensou...@keylevel.com > www.keylevel.com > > > -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto Developer Day at ELCE 2012
Aloha all, If possible could someone advise on what the content of the Yocto developr Day will be at this year's ELCE? I'm thinking of attending but need to know what it entails and how useful it would be for me, not just so I don't waste time, but also so that I can make the required case to management to send me there. I understand there will be a mix of begginer and advanced sessions/labs but knowing the type of content in those sessions would be useful. Many thanks, Andy -- Andrew Wafaa IRC: FunkyPenguin GPG: 0x3A36312F ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [yocto-docs][PATCH 00/11] Documentation improvements
Add some missing variables to the variable reference and improve the descriptions of others. Also fix references to "package" where we mean "recipe" and a couple of other issues I noticed at the same time. The following changes since commit 821162221818f5ce53bb903aeef57c85314f5083: documentation: dev-manual - mentioned SRC_URI in the kernel example (2012-10-05 11:25:03 -0700) are available in the git repository at: git://git.yoctoproject.org/poky-contrib paule/doc-fixes-5 http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=paule/doc-fixes-5 Paul Eggleton (11): documentation: dev-manual: fix spelling documentation: poky-ref-manual: correct LICENSE_DIR -> LICENSE_PATH documentation: poky-ref-manual: improve MACHINE_* variable descriptions documentation: poky-ref-manual: extend description of MACHINE variable documentation: poky-ref-manual: add PACKAGECONFIG variable documentation: poky-ref-manual: extend DISTRO description documentation: poky-ref-manual: add information on *_FEATURES_BACKFILL documentation: poky-ref-manual: fix description of SUMMARY variable documentation: poky-ref-manual: remove references to ipkg documentation: poky-ref-manual: replace "package" with "recipe" where appropriate documentation: poky-ref-manual: update directory structure information documentation/dev-manual/dev-manual-newbie.xml |2 +- documentation/poky-ref-manual/faq.xml |2 +- documentation/poky-ref-manual/ref-features.xml | 46 documentation/poky-ref-manual/ref-structure.xml | 30 ++- documentation/poky-ref-manual/ref-variables.xml | 267 +++ 5 files changed, 249 insertions(+), 98 deletions(-) -- 1.7.9.5 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [yocto-docs][PATCH 01/11] documentation: dev-manual: fix spelling
sence -> sense Signed-off-by: Paul Eggleton --- documentation/dev-manual/dev-manual-newbie.xml |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation/dev-manual/dev-manual-newbie.xml b/documentation/dev-manual/dev-manual-newbie.xml index 9b922b1..20cf234 100644 --- a/documentation/dev-manual/dev-manual-newbie.xml +++ b/documentation/dev-manual/dev-manual-newbie.xml @@ -325,7 +325,7 @@ PE). Poky: The term "poky" can mean several things. -In its most general sence, it is an open-source project that was initially developed +In its most general sense, it is an open-source project that was initially developed by OpenedHand. With OpenedHand, poky was developed off of the existing OpenEmbedded build system becoming a build system for embedded images. After Intel Corporation aquired OpenedHand, the project poky became the basis for -- 1.7.9.5 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [yocto-docs][PATCH 03/11] documentation: poky-ref-manual: improve MACHINE_* variable descriptions
Adjust the descriptions so that it is clearer that these are specific
to a machine and should appear in the machine's .conf file, and are
intended to affect the image contents, not the dependencies of a
specific package. Also change the examples so that they demonstrate more
realistic usage scenarios for these variables.
Signed-off-by: Paul Eggleton
---
documentation/poky-ref-manual/ref-variables.xml | 124 +++
1 file changed, 60 insertions(+), 64 deletions(-)
diff --git a/documentation/poky-ref-manual/ref-variables.xml
b/documentation/poky-ref-manual/ref-variables.xml
index 62c2596..af1c9e1 100644
--- a/documentation/poky-ref-manual/ref-variables.xml
+++ b/documentation/poky-ref-manual/ref-variables.xml
@@ -1354,8 +1354,8 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR =
"${INC_PR}.3"
-A list of required packages to install as part of the
package being
-built.
+A list of required machine-specific packages to install as
part of
+the image being built.
The build process depends on these packages being present.
Furthermore, because this is a "machine essential"
variable, the list of
packages are essential for the machine to boot.
@@ -1365,16 +1365,18 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR =
"${INC_PR}.3"
This variable is similar to the
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS
-variable with the exception that the package being built
has a build
+variable with the exception that the image being built has
a build
dependency on the variable's list of packages.
In other words, the image will not build if a file in this
list is not found.
-For example, suppose you are building a runtime package
that depends
-on a certain disk driver.
-In this case, you would use the following:
+For example, suppose the machine you are building for
requires
+a specific program to be run during boot to initialise the
hardware.
+In this case, assuming the package name for the program was
+example-init, you would use the
following in the
+.conf file for the machine:
- MACHINE_ESSENTIAL_EXTRA_RDEPENDS += ""
+ MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "example-init"
@@ -1384,8 +1386,8 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR =
"${INC_PR}.3"
-A list of recommended packages to install as part of the
package being
-built.
+A list of recommended machine-specific packages to install
as part of
+the image being built.
The build process does not depend on these packages being
present.
Furthermore, because this is a "machine essential"
variable, the list of
packages are essential for the machine to boot.
@@ -1395,46 +1397,41 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR =
"${INC_PR}.3"
This variable is similar to the
MACHINE_ESSENTIAL_EXTRA_RDEPENDS
-variable with the exception that the package being built
does not have a build
+variable with the exception that the image being built
does not have a build
dependency on the variable's list of packages.
-In other words, the image will build if a file in this
list is not found.
-However, because this is one of the "essential" variables,
the resulting image
-might not boot on the machine.
-Or, if the machine does boot using the image, the machine
might not be fully
-functional.
-
-
-Consider an example where you have a custom kernel with a
disk driver
-built into the kernel itself, rather than using the driver
built as a module.
-If you include the package that has the driver module as
part of
-the variable's list, the
-build process will not find that package.
-However, because these packages are "recommends" packages,
the build will
-not fail due to the missing package.
-Not accounting for any other problems, the custom kernel
would still boot the machine.
+In other word
[yocto] [yocto-docs][PATCH 02/11] documentation: poky-ref-manual: correct LICENSE_DIR -> LICENSE_PATH
LICENSE_PATH is the correct variable to use for 1.3 - see:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=3118
Fixes documentation for [YOCTO #3118].
Signed-off-by: Paul Eggleton
---
documentation/poky-ref-manual/ref-variables.xml |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/documentation/poky-ref-manual/ref-variables.xml
b/documentation/poky-ref-manual/ref-variables.xml
index fd04017..62c2596 100644
--- a/documentation/poky-ref-manual/ref-variables.xml
+++ b/documentation/poky-ref-manual/ref-variables.xml
@@ -1327,15 +1327,15 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR =
"${INC_PR}.3"
-LICENSE_DIR
+LICENSE_PATH
Path to additional licenses used during the build.
By default, the OpenEmbedded build system uses
COMMON_LICENSE_DIR
to define the directory that holds common license text
used during the build.
-The LICENSE_DIR variable allows you
to extend that
+The LICENSE_PATH variable allows you
to extend that
location to other areas that have additional licenses:
- LICENSE_DIR += "/path/to/additional/common/licenses"
+ LICENSE_PATH += "/path/to/additional/common/licenses"
--
1.7.9.5
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [yocto-docs][PATCH 05/11] documentation: poky-ref-manual: add PACKAGECONFIG variable
Add a description of the PACKAGECONFIG variable to the variable
glossary.
Signed-off-by: Paul Eggleton
---
documentation/poky-ref-manual/ref-variables.xml | 31 +++
1 file changed, 31 insertions(+)
diff --git a/documentation/poky-ref-manual/ref-variables.xml
b/documentation/poky-ref-manual/ref-variables.xml
index fa2bc7f..0bb3094 100644
--- a/documentation/poky-ref-manual/ref-variables.xml
+++ b/documentation/poky-ref-manual/ref-variables.xml
@@ -1577,6 +1577,37 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR =
"${INC_PR}.3"
+PACKAGECONFIG
+
+
+Provides a means of enabling or disabling features of a
recipe
+on a per-recipe basis. The
PACKAGECONFIG
+variable itself specifies a space-separated list of the
features
+to enable, whilst the named flags set on the variable
specify
+for each feature the additional build dependencies
+(DEPENDS)
+that should be added if the feature is enabled, and any
extra arguments
+that should be added to the configure script argument list
+(EXTRA_OECONF)
+if the feature is enabled or disabled.
+
+
+For example, the following taken from the
librsvg
+recipe will add --with-croco to the
+configure script arguments and
libcroco to
+DEPENDS
+by default; however, if "croco" is removed from
PACKAGECONFIG
+(for example, by using a bbappend in another layer) then
+--without-croco will be added to the
configure
+script arguments instead:
+
+ PACKAGECONFIG ??= "croco"
+ PACKAGECONFIG[croco] = "--with-croco,--without-croco,libcroco"
+
+
+
+
+
PACKAGES
The list of packages to be created from the recipe.
--
1.7.9.5
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [yocto-docs][PATCH 06/11] documentation: poky-ref-manual: extend DISTRO description
Extend the description of the DISTRO variable so that it mentions that this points to a .conf file under conf/distro and mentions what happens if the value is left blank. Signed-off-by: Paul Eggleton --- documentation/poky-ref-manual/ref-variables.xml | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/documentation/poky-ref-manual/ref-variables.xml b/documentation/poky-ref-manual/ref-variables.xml index 0bb3094..ba81f96 100644 --- a/documentation/poky-ref-manual/ref-variables.xml +++ b/documentation/poky-ref-manual/ref-variables.xml @@ -448,7 +448,16 @@ DISTRO -The short name of the distribution. + +The short name of the distribution. This corresponds to a file with the +extension .conf located in a conf/distro directory +within the metadata that contains the distribution configuration. The +value must not contain spaces, and is typically all lower-case. + + +If blank, a set of default configuration will be used, which is specified +within meta/conf/distro/defaultsetup.conf. + -- 1.7.9.5 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [yocto-docs][PATCH 04/11] documentation: poky-ref-manual: extend description of MACHINE variable
Extend the description of the MACHINE variable so that it mentions that
this points to a .conf file under conf/machine.
Signed-off-by: Paul Eggleton
---
documentation/poky-ref-manual/ref-variables.xml |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/documentation/poky-ref-manual/ref-variables.xml
b/documentation/poky-ref-manual/ref-variables.xml
index af1c9e1..fa2bc7f 100644
--- a/documentation/poky-ref-manual/ref-variables.xml
+++ b/documentation/poky-ref-manual/ref-variables.xml
@@ -1346,7 +1346,11 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR =
"${INC_PR}.3"
MACHINE
-Specifies the target device.
+
+Specifies the target device. This corresponds to a file
with the
+extension .conf located in a
conf/machine directory
+within the metadata that contains the target device
configuration.
+
--
1.7.9.5
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [yocto-docs][PATCH 07/11] documentation: poky-ref-manual: add information on *_FEATURES_BACKFILL
Document DISTRO_FEATURES_BACKFILL and MACHINE_FEATURES_BACKFILL. We may wish to expand upon this in future, but at least this explains what these variables are for and how to use them. Also add a link from the DISTRO_FEATURES entry to the section that lists valid DISTRO_FEATURES items. Signed-off-by: Paul Eggleton --- documentation/poky-ref-manual/ref-features.xml | 46 +++ documentation/poky-ref-manual/ref-variables.xml | 54 ++- 2 files changed, 99 insertions(+), 1 deletion(-) diff --git a/documentation/poky-ref-manual/ref-features.xml b/documentation/poky-ref-manual/ref-features.xml index 159d56d..81ba8e5 100644 --- a/documentation/poky-ref-manual/ref-features.xml +++ b/documentation/poky-ref-manual/ref-features.xml @@ -171,6 +171,52 @@ + + +Feature backfilling + + +Sometimes, it is necessary for a new feature to be added to control existing +functionality that was previously enabled by default and not able to be disabled. +In order to ensure that the feature remains enabled for users with existing +configurations that upgrade to a new version of the core metadata without that +configuration having to be changed, whilst still allowing others who want to turn +the feature off to do so, the backfilling mechanism was introduced. This +functionality is available for DISTRO_FEATURES +and MACHINE_FEATURES. + + + +An example is the "pulseaudio" distro feature. Previously, PulseAudio support +was enabled within the Qt and GStreamer frameworks; however some users desired +to be able to disable this. To allow this to be disabled without affecting +existing configurations in which PulseAudio support should remain enabled, +"pulseaudio" was added to +DISTRO_FEATURES_BACKFILL +within meta/conf/bitbake.conf; this means that "pulseaudio" +is automatically added to DISTRO_FEATURES without the distro +configuration needing to be updated to do so itself. +Those who do not want PulseAudio support can add "pulseaudio" to +DISTRO_FEATURES_BACKFILL_CONSIDERED +in their distro .conf file and this will disable adding "pulseaudio" to +DISTRO_FEATURES. + + + +Another example is the "rtc" machine feature. Previously, real time clock (RTC) +support was enabled for all target devices; however certain targets do not have +this capability. To allow this to be disabled by such machines without affecting +other machines in which RTC support should remain enabled, "rtc" was added to +MACHINE_FEATURES_BACKFILL +within meta/conf/bitbake.conf; this means that "rtc" +is automatically added to MACHINE_FEATURES without the +machine configuration needing to be updated to do so itself. +For machines that not need RTC support can add "rtc" to +MACHINE_FEATURES_BACKFILL_CONSIDERED +in their machine .conf file and this will disable adding "rtc" to +MACHINE_FEATURES. + +
[yocto] [yocto-docs][PATCH 08/11] documentation: poky-ref-manual: fix description of SUMMARY variable
* Use correct/up-to-date names of package systems
* SUMMARY does not default to the value of DESCRIPTION, it's the other
way around (although the logic may be improved in future so that this
is the effect).
Signed-off-by: Paul Eggleton
---
documentation/poky-ref-manual/ref-variables.xml |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/documentation/poky-ref-manual/ref-variables.xml
b/documentation/poky-ref-manual/ref-variables.xml
index c71a959..ccdb0e8 100644
--- a/documentation/poky-ref-manual/ref-variables.xml
+++ b/documentation/poky-ref-manual/ref-variables.xml
@@ -2217,9 +2217,9 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR =
"${INC_PR}.3"
SUMMARY
The short (72 characters or less) summary of the binary
package for packaging
-systems such as ipkg,
rpm or
-debian.
-By default, this variable inherits
DESCRIPTION.
+systems such as opkg,
rpm or
+dpkg.
+
--
1.7.9.5
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [yocto-docs][PATCH 09/11] documentation: poky-ref-manual: remove references to ipkg
We haven't supported ipkg for some time now - it was replaced by opkg (whilst still using the ipk package format). Signed-off-by: Paul Eggleton --- documentation/poky-ref-manual/faq.xml |2 +- documentation/poky-ref-manual/ref-variables.xml |4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/documentation/poky-ref-manual/faq.xml b/documentation/poky-ref-manual/faq.xml index 943d22a..945c7f1 100644 --- a/documentation/poky-ref-manual/faq.xml +++ b/documentation/poky-ref-manual/faq.xml @@ -166,7 +166,7 @@ The OpenEmbedded build system can build packages in various formats such as -ipk for ipkg/opkg, +ipk for opkg, Debian package (.deb), or RPM. The packages can then be upgraded using the package tools on the device, much like on a desktop distribution such as Ubuntu or Fedora. diff --git a/documentation/poky-ref-manual/ref-variables.xml b/documentation/poky-ref-manual/ref-variables.xml index ccdb0e8..dd858d3 100644 --- a/documentation/poky-ref-manual/ref-variables.xml +++ b/documentation/poky-ref-manual/ref-variables.xml @@ -114,8 +114,8 @@ A list of packages not to install despite being recommended by a recipe. -Support for this variable exists only for images that use the -ipkg packaging system. +Support for this variable exists only when using the +ipk packaging backend. -- 1.7.9.5 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [yocto-docs][PATCH 11/11] documentation: poky-ref-manual: update directory structure information
* Add meta-yocto, meta-yocto-bsp and meta-hob * Remove meta-rt - this was merged into OE-Core (meta) * Remove meta-demoapps - this was dropped Signed-off-by: Paul Eggleton --- documentation/poky-ref-manual/ref-structure.xml | 30 --- 1 file changed, 21 insertions(+), 9 deletions(-) diff --git a/documentation/poky-ref-manual/ref-structure.xml b/documentation/poky-ref-manual/ref-structure.xml index fcdf7b1..75bc2eb 100644 --- a/documentation/poky-ref-manual/ref-structure.xml +++ b/documentation/poky-ref-manual/ref-structure.xml @@ -93,25 +93,37 @@ This directory contains the OpenEmbedded Core metadata. -The directory holds machine definitions, the Yocto Project distribution, -and the packages that make up a given system. +The directory holds recipes, common classes, and machine +configuration for emulated targets (qemux86, qemuarm, +and so on.) - -meta-demoapps/ + +meta-yocto/ -This directory contains recipes for applications and demos that are not part of the -OpenEmbedded core. +This directory contains the configuration for the Poky +reference distribution. - -meta-rt/ + +meta-yocto-bsp/ -This directory contains recipes for real-time kernels. +This directory contains the Yocto Project reference +hardware BSPs. + + + + +meta-hob/ + + +This directory contains template recipes used by the +Hob +build UI. -- 1.7.9.5 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Meta Intel / Cedartrail / Denzil - how to get unionfs in the kernel
-Original Message- From: Bruce Ashfield [mailto:bruce.ashfi...@gmail.com] Sent: Monday, October 08, 2012 7:00 AM To: Chris Tapp Cc: Saxena, Rahul; yocto@yoctoproject.org Project Subject: Re: [yocto] Meta Intel / Cedartrail / Denzil - how to get unionfs in the kernel On Mon, Oct 8, 2012 at 3:58 AM, Chris Tapp wrote: > On 7 Oct 2012, at 22:41, Bruce Ashfield wrote: > >> On Sun, Oct 7, 2012 at 6:08 PM, Chris Tapp wrote: >>> On 7 Oct 2012, at 03:00, Saxena, Rahul wrote: >>> Try adding the unionfs feature (below) to your kernel: http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.0/tree/meta /cfg/kernel-cache/features/unionfs?h=meta create a file my_cedartrail.scc with following line: include features/unionfs/unionfs.scc put this file in a dir linux-yocto, the dir being created in meta-cedartrail/recipes-kernel/linux add following line in meta-cedartrail/recipes-kernel/Linux/linux-yocto_3.0.bbappend SRC_URI +="file://my_cedartrail.scc" >>> >>> Thanks - I thought just running 'menuconfig' would allow me to enable it >>> (for a quick test). >>> >>> However, this still doesn't seem to be working. I can see that >>> 'my_cedartrail.scc' gets fetched in to the build area, but I still don't >>> see CONFIG_UNION_FS if I run 'menuconfig'. There is also no 'unionfs' >>> folder in fs/ of the build tree. >>> >>> Also, if I specify an invalid feature (e.g. feature2/unionfs/unionfs.scc) >>> I'm not seeing any diagnostic. >> >> unionfs was never merged to the 3.0 kernel, I re-added it to the >> development trees for 3.2 and the 3.4 kernel (aufs for the 3.6 tree >> at the moment). The meta data is carried forward from the older >> kernels as a placeholder and is documented in the .scc file itself: >> >> --- >> kconf non-hardware unionfs.cfg >> >> # commented pending update to a newer version ported to 2.6.35+ # >> patch unionfs-2.5.4-integration.patch >> --- >> >> So to get unionfs in the 3.0 kernel, we'd need a port .. but since >> we've moved on quite a bit past 3.0, I don't know of any pending >> ports myself. > > Thanks Bruce. > > I guess I need to ask the Intel guys if there are any plans to move > Cedartrail on from 3.0 ? It will have to happen post yocto 1.3 (as far as I know), since the 3.0 kernel will be dropped at that point. For the short term, it's likely easier to backport/update unionfs than it would be to update the BSP .. but I can't speak for the time to be spent doing it :) Cheers, Bruce Chris, There are no plans to port Cedartrail BSP to support any other Kernel other than 3.0. The reason is that the Cedartrail PVR Graphics driver is supported only for 3.0 kernel. Rahul > >> Cheers, >> >> Bruce >> >>> -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Chris Tapp Sent: Saturday, October 06, 2012 5:43 PM To: yocto@yoctoproject.org Project Subject: [yocto] Meta Intel / Cedartrail / Denzil - how to get unionfs in the kernel I' trying to enable unionfs in the 3.0.32 kernel for the cedartrail BSP under Denzil 7.0.1. However, the CONFIG_UNION_FS config flag isn't in the .config ... Is there something else I need to enable, or do I need to find another way? Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto >>> >>> Chris Tapp >>> >>> opensou...@keylevel.com >>> www.keylevel.com >>> >>> >>> >>> ___ >>> yocto mailing list >>> yocto@yoctoproject.org >>> https://lists.yoctoproject.org/listinfo/yocto >> >> >> >> -- >> "Thou shalt not follow the NULL pointer, for chaos and madness await >> thee at its end" > > Chris Tapp > > opensou...@keylevel.com > www.keylevel.com > > > -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Meta Intel / Cedartrail / Denzil - how to get unionfs in the kernel
>-Original Message- >From: yocto-boun...@yoctoproject.org [mailto:yocto- >boun...@yoctoproject.org] On Behalf Of Chris Tapp >Sent: Monday, October 08, 2012 12:59 AM >To: Bruce Ashfield >Cc: yocto@yoctoproject.org Project >Subject: Re: [yocto] Meta Intel / Cedartrail / Denzil - how to get unionfs in >the >kernel > >On 7 Oct 2012, at 22:41, Bruce Ashfield wrote: > >> On Sun, Oct 7, 2012 at 6:08 PM, Chris Tapp >wrote: >>> On 7 Oct 2012, at 03:00, Saxena, Rahul wrote: >>> Try adding the unionfs feature (below) to your kernel: http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto- >3.0/tree/meta/cfg/kernel-cache/features/unionfs?h=meta create a file my_cedartrail.scc with following line: include features/unionfs/unionfs.scc put this file in a dir linux-yocto, the dir being created in meta-cedartrail/recipes-kernel/linux add following line in meta-cedartrail/recipes-kernel/Linux/linux- >yocto_3.0.bbappend SRC_URI +="file://my_cedartrail.scc" >>> >>> Thanks - I thought just running 'menuconfig' would allow me to enable it >(for a quick test). >>> >>> However, this still doesn't seem to be working. I can see that >'my_cedartrail.scc' gets fetched in to the build area, but I still don't see >CONFIG_UNION_FS if I run 'menuconfig'. There is also no 'unionfs' folder in >fs/ of the build tree. >>> >>> Also, if I specify an invalid feature (e.g. feature2/unionfs/unionfs.scc) >>> I'm >not seeing any diagnostic. >> >> unionfs was never merged to the 3.0 kernel, I re-added it to the >development >> trees for 3.2 and the 3.4 kernel (aufs for the 3.6 tree at the moment). The >meta >> data is carried forward from the older kernels as a placeholder and is >> documented >> in the .scc file itself: >> >> --- >> kconf non-hardware unionfs.cfg >> >> # commented pending update to a newer version ported to 2.6.35+ >> # patch unionfs-2.5.4-integration.patch >> --- >> >> So to get unionfs in the 3.0 kernel, we'd need a port .. but since >> we've moved on >> quite a bit past 3.0, I don't know of any pending ports myself. > >Thanks Bruce. > >I guess I need to ask the Intel guys if there are any plans to move Cedartrail >on >from 3.0 ? If the interest is to have unionfs, you can still get it from 3.2 or 3.4 Kernel. But the downside is you will be missing the PVR Graphics and will be falling back to the basic vesa graphics mode. PVR graphics has support only for 3.0 kernel only, so we had only put the 3.0 kernel recipe in the meta-intel. We do not have plans to port PVR graphics to 3.4 kernel. We can update the Cedartrail BSP to have 3.2 and 3.4 kernel but it will be vesa graphics support only. Thanks Kishore. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [yocto-docs][PATCH 10/11] documentation: poky-ref-manual: replace "package" with "recipe" where appropriate
We have to take care when using "package" to avoid confusion, even when
referring to variables with a historical package association (PV, PN
etc.).
Signed-off-by: Paul Eggleton
---
documentation/poky-ref-manual/ref-variables.xml | 25 ---
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/documentation/poky-ref-manual/ref-variables.xml
b/documentation/poky-ref-manual/ref-variables.xml
index dd858d3..7153731 100644
--- a/documentation/poky-ref-manual/ref-variables.xml
+++ b/documentation/poky-ref-manual/ref-variables.xml
@@ -200,14 +200,14 @@
BBFILE_PRIORITY
Assigns the priority for recipe files in each
layer.
-This variable is useful in situations where the same
package appears in
+This variable is useful in situations where the same
recipe appears in
more than one layer.
Setting this variable allows you to prioritize a
-layer against other layers that contain the same package -
effectively
+layer against other layers that contain the same recipe -
effectively
letting you control the precedence for the multiple
layers.
The precedence established through this variable stands
regardless of a
-layer's package version (PV
variable).
-For example, a layer that has a package with a higher
PV value but for
+recipe's version (PV variable).
+For example, a layer that has a recipe with a higher
PV value but for
which the BBFILE_PRIORITY is set to
have a lower precedence still has a
lower precedence.
A larger value for the
BBFILE_PRIORITY variable results in a higher
@@ -269,7 +269,7 @@
BP
The base recipe name and version but without any special
-package name suffix (i.e. -native,
lib64-,
+recipe name suffix (i.e. -native,
lib64-,
and so forth).
BP is comprised of the following:
@@ -280,7 +280,7 @@
BPN
-Bare name of package with any suffixes like -cross
-native removed.
+Bare name of recipe with any suffixes like -cross
-native removed.
@@ -825,7 +825,8 @@ FILESPATH = "${@base_set_filespath([
"${FILE_DIRNAME}/${PF}", \
HOMEPAGE
-Website where more info about package can be found
+Website where more information about the software the
recipe is building
+can be found.
@@ -2356,7 +2357,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR =
"${INC_PR}.3"
The pathname of the working directory in which the
OpenEmbedded build system
-builds packages.
+builds a recipe.
This directory is located within the
TMPDIR directory structure and
changes
as different packages are built.
@@ -2369,9 +2370,9 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR =
"${INC_PR}.3"
The package architecture - PACKAGE_ARCH
The target machine - MACHINE
The target operating system - TARGET_OS
-The package name - PN
-The package version - PV
-The package revision - PR
+The recipe name - PN
+The recipe version - PV
+The recipe revision - PR
@@ -2403,7 +2404,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR =
"${INC_PR}.3"
named poky and a default build
directory
at poky/build.
In this case, the working directory the build system uses
to build
-the acl package, which is dependent
on a
+the acl recipe, which is being built
for a
MIPS-based device, is the following:
~/poky/build/tmp/work/mips-poky-linux/acl-2.2.51-r2
--
1.7.9.5
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [yocto-docs][PATCH 00/11] Documentation improvements
On Monday 08 October 2012 16:38:06 Paul Eggleton wrote: > Add some missing variables to the variable reference and improve > the descriptions of others. Also fix references to "package" where > we mean "recipe" and a couple of other issues I noticed at the same > time. > > > The following changes since commit 821162221818f5ce53bb903aeef57c85314f5083: > > documentation: dev-manual - mentioned SRC_URI in the kernel example > (2012-10-05 11:25:03 -0700) > > are available in the git repository at: > > git://git.yoctoproject.org/poky-contrib paule/doc-fixes-5 > http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=paule/doc-fixes-5 > > Paul Eggleton (11): > documentation: dev-manual: fix spelling > documentation: poky-ref-manual: correct LICENSE_DIR -> LICENSE_PATH > documentation: poky-ref-manual: improve MACHINE_* variable > descriptions > documentation: poky-ref-manual: extend description of MACHINE > variable > documentation: poky-ref-manual: add PACKAGECONFIG variable > documentation: poky-ref-manual: extend DISTRO description > documentation: poky-ref-manual: add information on > *_FEATURES_BACKFILL > documentation: poky-ref-manual: fix description of SUMMARY variable > documentation: poky-ref-manual: remove references to ipkg > documentation: poky-ref-manual: replace "package" with "recipe" where > appropriate > documentation: poky-ref-manual: update directory structure > information > > documentation/dev-manual/dev-manual-newbie.xml |2 +- > documentation/poky-ref-manual/faq.xml |2 +- > documentation/poky-ref-manual/ref-features.xml | 46 > documentation/poky-ref-manual/ref-structure.xml | 30 ++- > documentation/poky-ref-manual/ref-variables.xml | 267 > +++ 5 files changed, 249 insertions(+), 98 deletions(-) Apologies if 10/11 comes through twice, there was some kind of issue with getting the original mail through to the mailing list server so I resent it. 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] Move 'tag=' for a few SRC_URIs to SRCREV
Sending in response to: - http://lists.yoctoproject.org/pipermail/yocto/2012-September/011802.html Building with BB_NO_NETWORK can fail if recipes specify 'tag=' in SRC_URI, since bitbake must contact the source repository to verify which hash the tag currently points to. Since tags can, in principle, change, current best practice is to omit 'tag=' from SRC_URIs and instead specify the required revision hash in SRCREV. SHA hashes *cannot* change, so they should not need to be checked, in theory; however, bitbake currently has no mechanism for distinguishing between human-friendly tags like 'v2.1.2' and SHA-1 sums like 'fdb6c0402337d9607c7a39155088eaf033742752': both will result in a call to `git ls-remote` to verify the tag, which is problematic for BB_NO_NETWORK builds. The second part of this patch was, I think, already submitted, but not yet applied to master[?]: - http://lists.yoctoproject.org/pipermail/yocto/2012-September/011949.html Evade Flow (2): Move 'tag=' to SRCREV in btrfs-tools recipe Move 'tag=' to SRCREV in mtd-utils recipe .../btrfs-tools/btrfs-tools_git.bb |3 ++- meta/recipes-devtools/mtd/mtd-utils_1.5.0.bb |3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) -- 1.7.9.5 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/2] Move 'tag=' to SRCREV in btrfs-tools recipe
Signed-off-by: Evade Flow
---
.../btrfs-tools/btrfs-tools_git.bb |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/btrfs-tools/btrfs-tools_git.bb
b/meta/recipes-devtools/btrfs-tools/btrfs-tools_git.bb
index c2ae298..e963a74 100644
--- a/meta/recipes-devtools/btrfs-tools/btrfs-tools_git.bb
+++ b/meta/recipes-devtools/btrfs-tools/btrfs-tools_git.bb
@@ -12,7 +12,8 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=fcb02dc552a041dee27e4b85c7396067"
SECTION = "base"
DEPENDS = "util-linux attr"
-SRC_URI =
"git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git;protocol=git;tag=fdb6c0402337d9607c7a39155088eaf033742752;branch=master"
+SRCREV = "fdb6c0402337d9607c7a39155088eaf033742752"
+SRC_URI =
"git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git;protocol=git"
S = "${WORKDIR}/git"
--
1.7.9.5
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 2/2] Move 'tag=' to SRCREV in mtd-utils recipe
Signed-off-by: Evade Flow
---
meta/recipes-devtools/mtd/mtd-utils_1.5.0.bb |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/mtd/mtd-utils_1.5.0.bb
b/meta/recipes-devtools/mtd/mtd-utils_1.5.0.bb
index 1a9d4d3..bdfb022 100644
--- a/meta/recipes-devtools/mtd/mtd-utils_1.5.0.bb
+++ b/meta/recipes-devtools/mtd/mtd-utils_1.5.0.bb
@@ -6,7 +6,8 @@ LICENSE = "GPLv2+"
LIC_FILES_CHKSUM = "file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \
file://include/common.h;beginline=1;endline=17;md5=ba05b07912a44ea2bf81ce409380049c"
-SRC_URI =
"git://git.infradead.org/mtd-utils.git;protocol=git;tag=ca39eb1d98e736109c64ff9c1aa2a6ecca222d8f
\
+SRCREV = "ca39eb1d98e736109c64ff9c1aa2a6ecca222d8f"
+SRC_URI = "git://git.infradead.org/mtd-utils.git;protocol=git \
file://add-exclusion-to-mkfs-jffs2-git-2.patch"
S = "${WORKDIR}/git/"
--
1.7.9.5
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-ti] meta-gumstix proceedings
On Mon, Oct 08, 2012 at 12:18:24PM +0100, Paul Eggleton wrote: > Hi Andreas, > > On Monday 08 October 2012 12:54:46 Andreas Müller wrote: > > as some of you might know, gumstix created an official BSP layer > > [1][2]. To avoid confusion I renamed my layer from meta-gumstix to > > meta-gumstix-community [3]. Users should either switch to the official > > meta-gumstix layer or rename meta-gumstix to meta-gumstix-community > > [3] in git configuration (users of angstrom-setup-scripts should also > > change the name in layers.txt). > > So what should we do with the layer index [4]? Do we list both? What is the > delta between them, and is there a hope that there will be only one layer at > some point? Paul, FYI, http://thread.gmane.org/gmane.linux.distributions.gumstix.general/65109/focus=65131 -- Denys ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Meta Intel / Cedartrail / Denzil - how to get unionfs in the kernel
On 8 Oct 2012, at 17:35, Bodke, Kishore K wrote: > > >> -Original Message- >> From: yocto-boun...@yoctoproject.org [mailto:yocto- >> boun...@yoctoproject.org] On Behalf Of Chris Tapp >> Sent: Monday, October 08, 2012 12:59 AM >> To: Bruce Ashfield >> Cc: yocto@yoctoproject.org Project >> Subject: Re: [yocto] Meta Intel / Cedartrail / Denzil - how to get unionfs >> in the >> kernel >> >> On 7 Oct 2012, at 22:41, Bruce Ashfield wrote: >> >>> On Sun, Oct 7, 2012 at 6:08 PM, Chris Tapp >> wrote: On 7 Oct 2012, at 03:00, Saxena, Rahul wrote: > Try adding the unionfs feature (below) to your kernel: > > http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto- >> 3.0/tree/meta/cfg/kernel-cache/features/unionfs?h=meta > > create a file my_cedartrail.scc with following line: > include features/unionfs/unionfs.scc > > put this file in a dir linux-yocto, the dir being created in > > meta-cedartrail/recipes-kernel/linux > > add following line in meta-cedartrail/recipes-kernel/Linux/linux- >> yocto_3.0.bbappend > > SRC_URI +="file://my_cedartrail.scc" Thanks - I thought just running 'menuconfig' would allow me to enable it >> (for a quick test). However, this still doesn't seem to be working. I can see that >> 'my_cedartrail.scc' gets fetched in to the build area, but I still don't see >> CONFIG_UNION_FS if I run 'menuconfig'. There is also no 'unionfs' folder in >> fs/ of the build tree. Also, if I specify an invalid feature (e.g. feature2/unionfs/unionfs.scc) I'm >> not seeing any diagnostic. >>> >>> unionfs was never merged to the 3.0 kernel, I re-added it to the >> development >>> trees for 3.2 and the 3.4 kernel (aufs for the 3.6 tree at the moment). The >> meta >>> data is carried forward from the older kernels as a placeholder and is >>> documented >>> in the .scc file itself: >>> >>> --- >>> kconf non-hardware unionfs.cfg >>> >>> # commented pending update to a newer version ported to 2.6.35+ >>> # patch unionfs-2.5.4-integration.patch >>> --- >>> >>> So to get unionfs in the 3.0 kernel, we'd need a port .. but since >>> we've moved on >>> quite a bit past 3.0, I don't know of any pending ports myself. >> >> Thanks Bruce. >> >> I guess I need to ask the Intel guys if there are any plans to move >> Cedartrail on >> from 3.0 ? > > If the interest is to have unionfs, you can still get it from 3.2 or 3.4 > Kernel. > > But the downside is you will be missing the PVR Graphics and will be falling > back to the > basic vesa graphics mode. Tricky. One of the reasons for specifying Cedartrail was the accelerated graphics. However, I've got code running without acceleration and it looks like it should be fast enough to do what I need without it. > PVR graphics has support only for 3.0 kernel only, so we had only put the > 3.0 kernel recipe in the meta-intel. > > We do not have plans to port PVR graphics to 3.4 kernel. That's a pity, as this platform has a very good level of performance. I guess I'll have to be patient and wait for Ivy Bridge graphics ;-) > We can update the Cedartrail BSP to have 3.2 and 3.4 kernel but it will be > vesa graphics support only. How much work would this take? It looks like there is no unification FS support in 3.0 that I could use instead, but this is only for a low-volume project and I wouldn't like to think it was using resource that could be deployed more effectively else where. Thanks for your input on this - looks like I may need to revise my deployment strategy for this project ;-) Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Meta Intel / Cedartrail / Denzil - how to get unionfs in the kernel
On Mon, 2012-10-08 at 21:02 +0100, Chris Tapp wrote: > On 8 Oct 2012, at 17:35, Bodke, Kishore K wrote: > > > > > > >> -Original Message- > >> From: yocto-boun...@yoctoproject.org [mailto:yocto- > >> boun...@yoctoproject.org] On Behalf Of Chris Tapp > >> Sent: Monday, October 08, 2012 12:59 AM > >> To: Bruce Ashfield > >> Cc: yocto@yoctoproject.org Project > >> Subject: Re: [yocto] Meta Intel / Cedartrail / Denzil - how to get unionfs > >> in the > >> kernel > >> > >> On 7 Oct 2012, at 22:41, Bruce Ashfield wrote: > >> > >>> On Sun, Oct 7, 2012 at 6:08 PM, Chris Tapp > >> wrote: > On 7 Oct 2012, at 03:00, Saxena, Rahul wrote: > > > Try adding the unionfs feature (below) to your kernel: > > > > http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto- > >> 3.0/tree/meta/cfg/kernel-cache/features/unionfs?h=meta > > > > create a file my_cedartrail.scc with following line: > > include features/unionfs/unionfs.scc > > > > put this file in a dir linux-yocto, the dir being created in > > > > meta-cedartrail/recipes-kernel/linux > > > > add following line in meta-cedartrail/recipes-kernel/Linux/linux- > >> yocto_3.0.bbappend > > > > SRC_URI +="file://my_cedartrail.scc" > > Thanks - I thought just running 'menuconfig' would allow me to enable it > >> (for a quick test). > > However, this still doesn't seem to be working. I can see that > >> 'my_cedartrail.scc' gets fetched in to the build area, but I still don't > >> see > >> CONFIG_UNION_FS if I run 'menuconfig'. There is also no 'unionfs' folder in > >> fs/ of the build tree. > > Also, if I specify an invalid feature (e.g. > feature2/unionfs/unionfs.scc) I'm > >> not seeing any diagnostic. > >>> > >>> unionfs was never merged to the 3.0 kernel, I re-added it to the > >> development > >>> trees for 3.2 and the 3.4 kernel (aufs for the 3.6 tree at the moment). > >>> The > >> meta > >>> data is carried forward from the older kernels as a placeholder and is > >>> documented > >>> in the .scc file itself: > >>> > >>> --- > >>> kconf non-hardware unionfs.cfg > >>> > >>> # commented pending update to a newer version ported to 2.6.35+ > >>> # patch unionfs-2.5.4-integration.patch > >>> --- > >>> > >>> So to get unionfs in the 3.0 kernel, we'd need a port .. but since > >>> we've moved on > >>> quite a bit past 3.0, I don't know of any pending ports myself. > >> > >> Thanks Bruce. > >> > >> I guess I need to ask the Intel guys if there are any plans to move > >> Cedartrail on > >> from 3.0 ? > > > > If the interest is to have unionfs, you can still get it from 3.2 or 3.4 > > Kernel. > > > > But the downside is you will be missing the PVR Graphics and will be > > falling back to the > > basic vesa graphics mode. > > Tricky. One of the reasons for specifying Cedartrail was the accelerated > graphics. However, I've got code running without acceleration and it looks > like it should be fast enough to do what I need without it. > > > PVR graphics has support only for 3.0 kernel only, so we had only put the > > 3.0 kernel recipe in the meta-intel. > > > > We do not have plans to port PVR graphics to 3.4 kernel. > > That's a pity, as this platform has a very good level of performance. I guess > I'll have to be patient and wait for Ivy Bridge graphics ;-) > Another option would be to try to do the kernel work needed to move the driver to a later kernel - we have a similar situation with EMGD, which also typically lags by a few kernel versions, so we just go ahead and fix up whatever needs fixing up for the later kernels in order to keep it working as we uprev the kernels. Since 3.0 is going away soon and there seems to be interest in Cedar Trail, we should see what we can do to keep it alive with the pvr graphics support going forward. Tom > > We can update the Cedartrail BSP to have 3.2 and 3.4 kernel but it will be > > vesa graphics support only. > > How much work would this take? It looks like there is no unification FS > support in 3.0 that I could use instead, but this is only for a low-volume > project and I wouldn't like to think it was using resource that could be > deployed more effectively else where. > > Thanks for your input on this - looks like I may need to revise my deployment > strategy for this project ;-) > > Chris Tapp > > opensou...@keylevel.com > www.keylevel.com > > > > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Meta Intel / Cedartrail / Denzil - how to get unionfs in the kernel
>-Original Message-
>From: Chris Tapp [mailto:opensou...@keylevel.com]
>Sent: Monday, October 08, 2012 1:03 PM
>To: Bodke, Kishore K
>Cc: Bruce Ashfield; yocto@yoctoproject.org Project
>Subject: Re: [yocto] Meta Intel / Cedartrail / Denzil - how to get unionfs in
>the
>kernel
>
>On 8 Oct 2012, at 17:35, Bodke, Kishore K wrote:
>
>>
>>
>>> -Original Message-
>>> From: yocto-boun...@yoctoproject.org [mailto:yocto-
>>> boun...@yoctoproject.org] On Behalf Of Chris Tapp
>>> Sent: Monday, October 08, 2012 12:59 AM
>>> To: Bruce Ashfield
>>> Cc: yocto@yoctoproject.org Project
>>> Subject: Re: [yocto] Meta Intel / Cedartrail / Denzil - how to get unionfs
>>> in
>the
>>> kernel
>>>
>>> On 7 Oct 2012, at 22:41, Bruce Ashfield wrote:
>>>
On Sun, Oct 7, 2012 at 6:08 PM, Chris Tapp
>>> wrote:
> On 7 Oct 2012, at 03:00, Saxena, Rahul wrote:
>
>> Try adding the unionfs feature (below) to your kernel:
>>
>> http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-
>>> 3.0/tree/meta/cfg/kernel-cache/features/unionfs?h=meta
>>
>> create a file my_cedartrail.scc with following line:
>> include features/unionfs/unionfs.scc
>>
>> put this file in a dir linux-yocto, the dir being created in
>>
>> meta-cedartrail/recipes-kernel/linux
>>
>> add following line in meta-cedartrail/recipes-kernel/Linux/linux-
>>> yocto_3.0.bbappend
>>
>> SRC_URI +="file://my_cedartrail.scc"
>
> Thanks - I thought just running 'menuconfig' would allow me to enable it
>>> (for a quick test).
>
> However, this still doesn't seem to be working. I can see that
>>> 'my_cedartrail.scc' gets fetched in to the build area, but I still don't see
>>> CONFIG_UNION_FS if I run 'menuconfig'. There is also no 'unionfs' folder in
>>> fs/ of the build tree.
>
> Also, if I specify an invalid feature (e.g. feature2/unionfs/unionfs.scc)
>I'm
>>> not seeing any diagnostic.
unionfs was never merged to the 3.0 kernel, I re-added it to the
>>> development
trees for 3.2 and the 3.4 kernel (aufs for the 3.6 tree at the moment). The
>>> meta
data is carried forward from the older kernels as a placeholder and is
documented
in the .scc file itself:
---
kconf non-hardware unionfs.cfg
# commented pending update to a newer version ported to 2.6.35+
# patch unionfs-2.5.4-integration.patch
---
So to get unionfs in the 3.0 kernel, we'd need a port .. but since
we've moved on
quite a bit past 3.0, I don't know of any pending ports myself.
>>>
>>> Thanks Bruce.
>>>
>>> I guess I need to ask the Intel guys if there are any plans to move
>>> Cedartrail
>on
>>> from 3.0 ?
>>
>> If the interest is to have unionfs, you can still get it from 3.2 or 3.4
>> Kernel.
>>
>> But the downside is you will be missing the PVR Graphics and will be falling
>back to the
>> basic vesa graphics mode.
>
>Tricky. One of the reasons for specifying Cedartrail was the accelerated
>graphics. However, I've got code running without acceleration and it looks like
>it should be fast enough to do what I need without it.
>
>> PVR graphics has support only for 3.0 kernel only, so we had only put the
>> 3.0
>kernel recipe in the meta-intel.
>>
>> We do not have plans to port PVR graphics to 3.4 kernel.
>
>That's a pity, as this platform has a very good level of performance. I guess
>I'll
>have to be patient and wait for Ivy Bridge graphics ;-)
>
>> We can update the Cedartrail BSP to have 3.2 and 3.4 kernel but it will be
>vesa graphics support only.
>
>How much work would this take? It looks like there is no unification FS support
>in 3.0 that I could use instead, but this is only for a low-volume project and
>I
>wouldn't like to think it was using resource that could be deployed more
>effectively else where.
>
>Thanks for your input on this - looks like I may need to revise my deployment
>strategy for this project ;-)
>
For denzil, try with this by creating a new file in
meta-cedartrail/recipes-kernel/linux/linux-yocto_3.2.bbappend.
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
SRC_URI_cedartrail-nopvr =
"git://git.yoctoproject.org/linux-yocto-3.2;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
COMPATIBLE_MACHINE_cedartrail-nopvr = "cedartrail"
KMACHINE_cedartrail-nopvr = "cedartrail"
KBRANCH_cedartrail-nopvr = "yocto/standard/cedartrail"
KERNEL_FEATURES_append_cedartrail-nopvr += " cfg/smp.scc"
SRCREV_machine_pn-linux-yocto_cedartrail-nopvr ?=
"8b8cfaaab2b8d79ac56e8c9a85bad9ae7bca399c"
SRCREV_meta_pn-linux-yocto_cedartrail-nopvr ?=
"486f7aec824b4127e91ef53228823e996b3696f0"
Add these below lines to meta-cedartrail/conf/machine/cedartrail-nopvr.conf
PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
PREFERRED_VERSION_linux-yocto ?= "3.2%"
Add MACHINE = "cedartrail-nopvr" to your local.conf and build.
Ofcourse you should be adding your unionfs r
[yocto] Agenda: Yocto Project Technical Team Meeting - Tuesday, October 09, 2012 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada).
Agenda: * Opens collection - 5 min (Song) * Yocto 1.3 status - 10 min (Song/team) https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.3_Status - Medium+ bugs review: https://bugzilla.yoctoproject.org/buglist.cgi?bug_status=NEW&bug_status=ACCEPTED&bug_status=REOPENED&bug_status=NEEDINFO&bug_status=WaitForUpstream&list_id=16013&priority=Medium%2B&query_format=advanced&target_milestone=1.3&target_milestone=1.3%20M1&target_milestone=1.3%20M2&target_milestone=1.3%20M3&target_milestone=1.3%20M4&target_milestone=1.3%20M5&target_milestone=1.3.1&target_milestone=1.3.2&order=assigned_to%20DESC%2Cpriority%2Cbug_status%20DESC%2Cbug_id&query_based_on= * Yocto 1.4 feature open discussion - 10 min (team) https://wiki.yoctoproject.org/wiki/Yocto_1.4_Features * SWAT team rotation: Saul * Opens - 10 min * Team sharing - 20 min -Original Appointment- We encourage people attending the meeting to logon the Yocto IRC chancel during the meeting (optional): Yocto IRC: http://webchat.freenode.net/?channels=#yocto IRC Tutorial: http://www.irchelp.org/irchelp/irctutorial.html Conference details Conference name: Yocto Technical Team Conference date/start time: Tue Jun 26, 2012 at 10:00 AM Central Daylight Time Participants: 30 Duration: 60 minutes Participant passcode: 76994298 Dial-in number: 1.972.995. US Toll Free number: 1.877.561.6828 BlackBerry users, click this link to join your conference as a participant: 1.972.995.x76994298# Depending on where you are dialing from, either your BlackBerry will pause and enter the passcode automatically or you will be prompted to click again to dial the passcode. Local and Global Access Numbers Country Dial-in number Australia: 1800 636 843 Czech Republic: 242 430 350 China (Beijing): >From office dial 8-995 or 8784277 Beijing Out of Office dial 5878 4277 China (Shanghai): >From office dial 8-995 or 3073322 Shanghai Out of Office dial 2307 3322 China (Shenzen): >From office dial 8-995 or 6007877 Shenzen Out of Office dial 2600 7877 China (Other Cities): >From IP phone dial 8-995 Other cities - Non IP phone dial 021-23073322 Denmark: 8060 1400 Finland: 09 41333477 France: 0497 275888 Germany: 08161 803232 Holland: 030 2417490 India: BSNL subscribers use 1800 425 9996 (Toll Free) Airtel subscribers use 0008 009 861 212 (Toll Free) From TI Campus use 8995 Others use 2509 9555 (Landline within Bangalore) or 80 2509 9555 (Outside Bangalore) Israel: 09 790 6715 Italy: 039 69061234 (039 is local city code not country code) Japan: >From TI Campus use 8 995 Outside TI use 03 4331 3777 Malaysia: >From IP phone dial 2643799 >From Kuala Lumpur dial 4264 3799 Outside Kuala Lumpur dial (03)4264 3799 Norway: 2 295 8744 Philippines: >From Baguio City use 4471177 >From Metro Manila area use 8702477 Singapore: >From IP phone dial 3894777 Outside TI use 6389 4777 South Korea: >From IP phone dial 5606998 >From Seoul dial 5606998 Outside Seoul dial (02)5606998 Sweden: 08 58755577 Taiwan: >From IP phone dial 1363 >From Taipei dial 2241 1363 Outside Taipei dial (02)2241 1363 Turkey: Landline Only dial 0811 288 0001 then enter 877 633 1123 UK: 01604 663003 US: 972 995 or 1877 561 6828 Recurring conferences First scheduled conference: Tue Jun 26, 2012 Recurrence frequency: Weekly - Every 1 week(s) on Tuesday Recurrence ends: End on Fri Jun 21, 2013, 10:40 AM CDT ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Meta Intel / Cedartrail / Denzil - how to get unionfs in the kernel
On 8 Oct 2012, at 21:30, Bodke, Kishore K wrote:
< snip ... >
Thanks for the really fast response on this :-)
> For denzil, try with this by creating a new file in
> meta-cedartrail/recipes-kernel/linux/linux-yocto_3.2.bbappend.
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>
> SRC_URI_cedartrail-nopvr =
> "git://git.yoctoproject.org/linux-yocto-3.2;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
I had to add 'bareclone=1' to this to get it to run.
> COMPATIBLE_MACHINE_cedartrail-nopvr = "cedartrail"
> KMACHINE_cedartrail-nopvr = "cedartrail"
> KBRANCH_cedartrail-nopvr = "yocto/standard/cedartrail"
> KERNEL_FEATURES_append_cedartrail-nopvr += " cfg/smp.scc"
>
> SRCREV_machine_pn-linux-yocto_cedartrail-nopvr ?=
> "8b8cfaaab2b8d79ac56e8c9a85bad9ae7bca399c"
> SRCREV_meta_pn-linux-yocto_cedartrail-nopvr ?=
> "486f7aec824b4127e91ef53228823e996b3696f0"
I think it's nearly there, but I get a failure when validating the branch:
NOTE: package
linux-yocto-3.2.18+git1+486f7aec824b4127e91ef53228823e996b3696f0_1+8b8cfaaab2b8d79ac56e8c9a85bad9ae7bca399c-r1:
task do_validate_branches: Started
ERROR: Function failed: do_validate_branches (see
/media/SSD-RAID/build-denzil-git-sjs-cedartrail/tmp/work/cedartrail_nopvr-sjs-linux/linux-yocto-3.2.18+git1+486f7aec824b4127e91ef53228823e996b3696f0_1+8b8cfaaab2b8d79ac56e8c9a85bad9ae7bca399c-r1/temp/log.do_validate_branches.25866
for further information)
ERROR: Logfile of failure stored in:
/media/SSD-RAID/build-denzil-git-sjs-cedartrail/tmp/work/cedartrail_nopvr-sjs-linux/linux-yocto-3.2.18+git1+486f7aec824b4127e91ef53228823e996b3696f0_1+8b8cfaaab2b8d79ac56e8c9a85bad9ae7bca399c-r1/temp/log.do_validate_branches.25866
Log data follows:
| ERROR: Function failed: do_validate_branches (see
/media/SSD-RAID/build-denzil-git-sjs-cedartrail/tmp/work/cedartrail_nopvr-sjs-linux/linux-yocto-3.2.18+git1+486f7aec824b4127e91ef53228823e996b3696f0_1+8b8cfaaab2b8d79ac56e8c9a85bad9ae7bca399c-r1/temp/log.do_validate_branches.25866
for further information)
NOTE: package
linux-yocto-3.2.18+git1+486f7aec824b4127e91ef53228823e996b3696f0_1+8b8cfaaab2b8d79ac56e8c9a85bad9ae7bca399c-r1:
task do_validate_branches: Failed
ERROR: Task 0
(/media/SSD-RAID/poky-git/meta/recipes-kernel/linux/linux-yocto_3.2.bb,
do_validate_branches) failed with exit code '1'
> Add these below lines to meta-cedartrail/conf/machine/cedartrail-nopvr.conf
>
> PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
> PREFERRED_VERSION_linux-yocto ?= "3.2%"
>
> Add MACHINE = "cedartrail-nopvr" to your local.conf and build.
>
> Ofcourse you should be adding your unionfs related stuff by some means either
> by menuconfig or by creating .scc file.
Of course, and that's the bit I understand ;-)
> Thanks
> Kishore.
>
Chris Tapp
opensou...@keylevel.com
www.keylevel.com
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCHv3 0/1] meta-intel misc commits
On Fri, 2012-10-05 at 19:17 -0700, nitin.a.kam...@intel.com wrote: > From: Nitin A Kamble > > Updated the kernel command line for crownbay BSP, after discussions with > Darren. > > Thanks, > Nitin > > The following changes since commit 7228f6b0c81817c8a8455ea78271abfd5d66fed8: > > meta-tlk: fix ignored SRC_URI appends (2012-10-05 14:47:55 -0500) > > 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 (1): > crownbay.conf: add kernel parameters for EMGD video acceleration > > meta-crownbay/conf/machine/crownbay.conf |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > Pulled into meta-intel/master. Thanks, Tom ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Meta Intel / Cedartrail / Denzil - how to get unionfs in the kernel
On 8 Oct 2012, at 22:03, Chris Tapp wrote:
> On 8 Oct 2012, at 21:30, Bodke, Kishore K wrote:
>
> < snip ... >
>
> Thanks for the really fast response on this :-)
>
>> For denzil, try with this by creating a new file in
>> meta-cedartrail/recipes-kernel/linux/linux-yocto_3.2.bbappend.
>>
>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>
>> SRC_URI_cedartrail-nopvr =
>> "git://git.yoctoproject.org/linux-yocto-3.2;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
>
> I had to add 'bareclone=1' to this to get it to run.
>
>> COMPATIBLE_MACHINE_cedartrail-nopvr = "cedartrail"
>> KMACHINE_cedartrail-nopvr = "cedartrail"
>> KBRANCH_cedartrail-nopvr = "yocto/standard/cedartrail"
>> KERNEL_FEATURES_append_cedartrail-nopvr += " cfg/smp.scc"
>>
>> SRCREV_machine_pn-linux-yocto_cedartrail-nopvr ?=
>> "8b8cfaaab2b8d79ac56e8c9a85bad9ae7bca399c"
>> SRCREV_meta_pn-linux-yocto_cedartrail-nopvr ?=
>> "486f7aec824b4127e91ef53228823e996b3696f0"
>
> I think it's nearly there, but I get a failure when validating the branch:
>
> NOTE: package
> linux-yocto-3.2.18+git1+486f7aec824b4127e91ef53228823e996b3696f0_1+8b8cfaaab2b8d79ac56e8c9a85bad9ae7bca399c-r1:
> task do_validate_branches: Started
> ERROR: Function failed: do_validate_branches (see
> /media/SSD-RAID/build-denzil-git-sjs-cedartrail/tmp/work/cedartrail_nopvr-sjs-linux/linux-yocto-3.2.18+git1+486f7aec824b4127e91ef53228823e996b3696f0_1+8b8cfaaab2b8d79ac56e8c9a85bad9ae7bca399c-r1/temp/log.do_validate_branches.25866
> for further information)
> ERROR: Logfile of failure stored in:
> /media/SSD-RAID/build-denzil-git-sjs-cedartrail/tmp/work/cedartrail_nopvr-sjs-linux/linux-yocto-3.2.18+git1+486f7aec824b4127e91ef53228823e996b3696f0_1+8b8cfaaab2b8d79ac56e8c9a85bad9ae7bca399c-r1/temp/log.do_validate_branches.25866
> Log data follows:
> | ERROR: Function failed: do_validate_branches (see
> /media/SSD-RAID/build-denzil-git-sjs-cedartrail/tmp/work/cedartrail_nopvr-sjs-linux/linux-yocto-3.2.18+git1+486f7aec824b4127e91ef53228823e996b3696f0_1+8b8cfaaab2b8d79ac56e8c9a85bad9ae7bca399c-r1/temp/log.do_validate_branches.25866
> for further information)
> NOTE: package
> linux-yocto-3.2.18+git1+486f7aec824b4127e91ef53228823e996b3696f0_1+8b8cfaaab2b8d79ac56e8c9a85bad9ae7bca399c-r1:
> task do_validate_branches: Failed
> ERROR: Task 0
> (/media/SSD-RAID/poky-git/meta/recipes-kernel/linux/linux-yocto_3.2.bb,
> do_validate_branches) failed with exit code '1'
Got it - I should have realised this would need to be using the latest denzil
head.
I've now got a working unionfs. A few minor kernel configuration issues to sort
(e.g. Apple HID for my keyboard) and I'll be there.
Thanks again for the help.
One final question - does lack of PVR mean I won't have a framebuffer device?
I've got the vesa one, but I can't use video=... in the kernel command line.
Not a show stopper by any means, but the video= stanza is much easier for
general users to modify.
>> Add these below lines to meta-cedartrail/conf/machine/cedartrail-nopvr.conf
>>
>> PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
>> PREFERRED_VERSION_linux-yocto ?= "3.2%"
>>
>> Add MACHINE = "cedartrail-nopvr" to your local.conf and build.
>>
>> Ofcourse you should be adding your unionfs related stuff by some means
>> either by menuconfig or by creating .scc file.
>
> Of course, and that's the bit I understand ;-)
>
>> Thanks
>> Kishore.
>>
>
> Chris Tapp
>
> opensou...@keylevel.com
> www.keylevel.com
>
>
>
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
Chris Tapp
opensou...@keylevel.com
www.keylevel.com
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] The BitBake equivalent of "Hello, World!"
I am continuing my work on creating a "Hello, World!" BitBake project. Because
of the excellent help I got before, things have gone reasonably well, but I'm
again running into something I don't know how to fix.
As before, the entire contents of my very small project appear at the end of
this message. Here's what works fine:
$ ../BitBake/bin/bitbake-layers show-layers
Parsing recipes..done.
layer pathpriority
==
LayerA/home/pturley/Workspace/Hello/LayerA1
$ ../BitBake/bin/bitbake-layers show-recipes
Parsing recipes..done.
=== Available recipes: ===
a:
LayerA 1
When I tried this:
../BitBake/bin/bitbake -c listtasks a
I got a Python stack trace that ended here:
File "../BitBake/lib/bb/runqueue.py", line 902, in
RunQueue.check_stamp_task(task=0, taskname='do_listtasks', recurse=False):
# If the stamp is missing its not current
>if not os.access(stampfile, os.F_OK):
logger.debug(2, "Stampfile %s not available", stampfile)
TypeError: coercing to Unicode: need string or buffer, NoneType found
This code isn't expecting the "stampfile" variable to be "None" (which it is),
so it freaks out. I made a very simple fix to get past the problem:
if not stampfile or not os.access(stampfile, os.F_OK):
That made a dramatic difference, and enabled me to get this far:
$ ../BitBake/bin/bitbake -c listtasks a
Loading cache: 100%
|###| ETA: 00:00:00
Loaded 2 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing RunQueue Tasks
NOTE: Running task 1 of 1 (ID: 0,
/home/pturley/Workspace/Hello/LayerA/a.bb, do_listtasks)
ERROR: T variable not set, unable to build
ERROR: Task 0 (/home/pturley/Workspace/Hello/LayerA/a.bb, do_listtasks)
failed with exit code '1'
NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be rerun
and 1 failed.
Summary: 1 task failed:
/home/pturley/Workspace/Hello/LayerA/a.bb, do_listtasks
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
$ ../BitBake/bin/bitbake a
Loading cache: 100%
|###| ETA: 00:00:00
Loaded 2 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing RunQueue Tasks
NOTE: Running task 1 of 1 (ID: 0,
/home/pturley/Workspace/Hello/LayerA/a.bb, do_build)
ERROR: T variable not set, unable to build
ERROR: Task 0 (/home/pturley/Workspace/Hello/LayerA/a.bb, do_build) failed
with exit code '1'
NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be rerun
and 1 failed.
Summary: 1 task failed:
/home/pturley/Workspace/Hello/LayerA/a.bb, do_build
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
As you can see, BitBake is expecting the "T" variable to be set. I don't think
I've ever seen this variable -- so I don't know what it's for or what I should
change.
Can anyone offer a hint?
├── build
│ │
│ ├── classes
│ │ │
│ │ └── base.bbclass
│ │
│ │ +---
│ │ | addtask listtasks
│ │ |
│ │ | do_listtasks[nostamp] = "1"
│ │ |
│ │ | python do_listtasks() {
│ │ | import sys
│ │ | # emit variables and shell functions
│ │ | #bb.data.emit_env(sys.__stdout__, d)
│ │ | # emit the metadata which isnt valid shell
│ │ | for e in d.keys():
│ │ | if d.getVarFlag(e, 'task'):
│ │ | bb.plain("%s" % e)
│ │ | }
│ │ |
│ │ | addtask build
│ │ |
│ │ | do_build() {
│ │ | echo "Hello"
│ │ | }
│ │ +---
│ │
│ └── conf
│ │
│ ├── bblayers.conf
│ │
│ │ +---
│ │ | BBLAYERS ?= " \
│ │ |/home/pturley/Workspace/Hello/LayerA \
│ │ |"
│ │ +---
│ │
│ └── bitbake.conf
│
│ +---
│ | CACHE = "${TOPDIR}/cache"
│ +---
│
├── LayerA
│ │
│ ├── a.bb
│ │
│ │ +---
│ │ | DESCRIPTION = "Layer A Main Recipe"
│ │ | PN = 'a'
│ │ | PV = '1'
│ │ +---
Re: [yocto] The BitBake equivalent of "Hello, World!"
The T variable points to a directory were Bitbake places temporary files
when building a particular package. It is typically set to
T = ${WORKDIR}/temp
WORKDIR is the directory into which Bitbake unpacks and builds a package.
The default bitbake.conf file sets this variable.
T is not to be confused with TMPDIR which points to the root of the
directory tree where Bitbake puts the output of an entire build.
:rjs
On Mon, Oct 8, 2012 at 5:30 PM, Patrick Turley
wrote:
> I am continuing my work on creating a "Hello, World!" BitBake project.
> Because of the excellent help I got before, things have gone reasonably
> well, but I'm again running into something I don't know how to fix.
>
> As before, the entire contents of my very small project appear at the
> end of this message. Here's what works fine:
>
>
> $ ../BitBake/bin/bitbake-layers show-layers
> Parsing recipes..done.
>
> layer pathpriority
> ==
> LayerA/home/pturley/Workspace/Hello/LayerA1
>
> $ ../BitBake/bin/bitbake-layers show-recipes
> Parsing recipes..done.
> === Available recipes: ===
> a:
> LayerA 1
>
>
> When I tried this:
>
>
> ../BitBake/bin/bitbake -c listtasks a
>
>
> I got a Python stack trace that ended here:
>
>
>File "../BitBake/lib/bb/runqueue.py", line 902, in
> RunQueue.check_stamp_task(task=0, taskname='do_listtasks', recurse=False):
> # If the stamp is missing its not current
> >if not os.access(stampfile, os.F_OK):
> logger.debug(2, "Stampfile %s not available",
> stampfile)
> TypeError: coercing to Unicode: need string or buffer, NoneType found
>
>
> This code isn't expecting the "stampfile" variable to be "None" (which
> it is), so it freaks out. I made a very simple fix to get past the problem:
>
>
> if not stampfile or not os.access(stampfile, os.F_OK):
>
>
> That made a dramatic difference, and enabled me to get this far:
>
>
> $ ../BitBake/bin/bitbake -c listtasks a
> Loading cache: 100%
> |###| ETA:
> 00:00:00
> Loaded 2 entries from dependency cache.
> NOTE: Resolving any missing task queue dependencies
> NOTE: Preparing runqueue
> NOTE: Executing RunQueue Tasks
> NOTE: Running task 1 of 1 (ID: 0, /home/pturley/Workspace/Hello/LayerA/
> a.bb, do_listtasks)
> ERROR: T variable not set, unable to build
> ERROR: Task 0 (/home/pturley/Workspace/Hello/LayerA/a.bb,
> do_listtasks) failed with exit code '1'
> NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be
> rerun and 1 failed.
>
> Summary: 1 task failed:
> /home/pturley/Workspace/Hello/LayerA/a.bb, do_listtasks
> Summary: There was 1 ERROR message shown, returning a non-zero exit
> code.
>
> $ ../BitBake/bin/bitbake a
> Loading cache: 100%
> |###| ETA:
> 00:00:00
> Loaded 2 entries from dependency cache.
> NOTE: Resolving any missing task queue dependencies
> NOTE: Preparing runqueue
> NOTE: Executing RunQueue Tasks
> NOTE: Running task 1 of 1 (ID: 0, /home/pturley/Workspace/Hello/LayerA/
> a.bb, do_build)
> ERROR: T variable not set, unable to build
> ERROR: Task 0 (/home/pturley/Workspace/Hello/LayerA/a.bb, do_build)
> failed with exit code '1'
> NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be
> rerun and 1 failed.
>
> Summary: 1 task failed:
> /home/pturley/Workspace/Hello/LayerA/a.bb, do_build
> Summary: There was 1 ERROR message shown, returning a non-zero exit
> code.
>
>
> As you can see, BitBake is expecting the "T" variable to be set. I
> don't think I've ever seen this variable -- so I don't know what it's for
> or what I should change.
>
> Can anyone offer a hint?
>
>
>
>
>
> ├── build
> │ │
> │ ├── classes
> │ │ │
> │ │ └── base.bbclass
> │ │
> │ │ +---
> │ │ | addtask listtasks
> │ │ |
> │ │ | do_listtasks[nostamp] = "1"
> │ │ |
> │ │ | python do_listtasks() {
> │ │ | import sys
> │ │ | # emit variables and shell functions
> │ │ | #bb.data.emit_env(sys.__stdout__, d)
> │ │ | # emit the metadata which isnt valid shell
> │ │ | for e in d.keys():
> │ │ | if d.getVarFlag(e, 'task'):
> │ │ | bb.plain("%s" % e)
> │ │ | }
> │ │ |
> │ │ | addtask build
> │ │ |
> │ │ | do_build() {
> │ │ | echo "Hello"
> │ │ | }
> │ │ +---
> │ │
> │
