[yocto] License information of tasks
Hi @all,
I'm building a layer to provide a customized image. Now I'm struggling
a bit by the license informations one have to provide for a task.
First: tasks are packages without content.
| rpm -qpl task-core-boot-1.0-r9.stamp9g20.rpm
| (contains no files)
... so why do they need some license information in the first place?
Second: OK if there are some reasons to provide license informations,
how do I include them?
In task-core-boot there are included like this:
| LICENSE = "MIT"
| LIC_FILES_CHKSUM =
"file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
|
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
No I wanna do the same, but of course relative to the base dir of my layer. But
I don't find a way of doing this ...
| LICENSE = "LGPL-3.0"
| LIC_FILES_CHKSUM =
"file://${LAYERDIR}/LICENSE;md5=5b241fa147528c635da6d1598c4a4056 \
|
file://${LAYERDIR}/COPYING;md5=c79ff39f19dfec6d293b95dea7b07891 \
|
file://${LAYERDIR}/COPYING.LESSER;md5=bfccfe952269fff2b407dd11f2f3083b"
... which looks good but don't work (I'm on 1.3_M3).
% ERROR: Function failed: task-imko-python: LIC_FILES_CHKSUM points to an
invalid file:
% ...task-imko-python-1.0-r1/task-imko-python-1.0/${LAYERDIR}/LICENSE
% ERROR: Logfile of failure stored in:
% .../task-imko-python-1.0-r1/temp/log.do_configure.1179
% Log data follows:
% | DEBUG: Executing python function sysroot_cleansstate
% | DEBUG: Python function sysroot_cleansstate finished
% | DEBUG: Executing shell function do_configure
% | DEBUG: Shell function do_configure finished
% | DEBUG: Executing python function do_qa_configure
% | NOTE: Checking autotools environment for common misconfiguration
% | DEBUG: Python function do_qa_configure finished
% | ERROR: Function failed: task-imko-python: LIC_FILES_CHKSUM points to an
invalid file:
% .../task-imko-python-1.0-r1/task-imko-python-1.0/${LAYERDIR}/LICENSE
% NOTE: package task-imko-python-1.0-r1: task do_configure: Failed
Any ideas?
Cheers, Markus
--
Human beings were created by water to transport it uphill.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] 1.3 M3 Full Pass test results
On Thu, 2012-08-23 at 20:13 +0100, Serban, Laurentiu wrote: > Here are the results for the full pas tests on 1.3 M3 RC2. The commit > used for testing is 8b8748c8f963900b83dc0fdd7757556f917fe4fd. > > Some details about the encountered issues below: > > BSP – Sudoku-savant project build issue (2878) > > ADT – the relocatable sdk issue (2980) causes 13 test cases to be on > faile/blocked state I thought it worked as long as you didn't have to relocate it so no tests should have been blocked, we just have the relocation issue? > , also the Clutter C template issue is unsolved (2577) > > Core Build System – x32 is still an issue (2888), cleaning sstate > issue is still not solved (2897), incremental RPM image generation > (2969), source archiving (2619), the kvm issue was reproduced by > another colleague (2790) Yocto BSP creation via JSON (2693) or for > qemu (2991) fails, multilib issue (2918 – this requires a little more > investigation from QA), > > HOB - all seems ok for RC2 > > Self-hosted-image - cannot start on Virtual Box (X issue), it is very > slow on qemu and it has a m4 package build (3005) issue on VMWare. If > the self-hosted-image is used on machine with internet connectivity > via proxy there will be an initial sanity check failure, but this is > not a blocking issue. > > A mention for the performance testing: on a Ubbuntu 12.04 i7 machine > using 8 threads the build time was 83 minutes (with prior fetching). How does this compare with our other performance numbers. From what I remember, we used to hover around the 105-115 minute mark. Did we have some significant speed gains or is this just an artefact of changing the test machine? Cheers, Richard ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] License information of tasks
On Friday 24 August 2012 12:05:41 Markus Hubig wrote:
> Hi @all,
>
> I'm building a layer to provide a customized image. Now I'm struggling
> a bit by the license informations one have to provide for a task.
>
> First: tasks are packages without content.
>
> | rpm -qpl task-core-boot-1.0-r9.stamp9g20.rpm
> | (contains no files)
>
> ... so why do they need some license information in the first place?
This is something that annoys me as well. I have thought about adding the
ability to declare that a license is not applicable for those recipes that
don't actually distribute any files, in which case a check during do_deploy,
do_package and do_populate_sysroot would be enabled that would fail if the
recipe ended up distributing anything. Unfortunately we don't have hooks in
all of the necessary places to make this practical, but it is still something
I would like to resolve.
> Second: OK if there are some reasons to provide license informations,
> how do I include them?
>
> In task-core-boot there are included like this:
> | LICENSE = "MIT"
> | LIC_FILES_CHKSUM =
> | "file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \|
> | file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c8
> | 0a0384361b4de20420"
>
> No I wanna do the same, but of course relative to the base dir of my layer.
> But I don't find a way of doing this ...
>
> | LICENSE = "LGPL-3.0"
> | LIC_FILES_CHKSUM =
> | "file://${LAYERDIR}/LICENSE;md5=5b241fa147528c635da6d1598c4a4056 \|
> | file://${LAYERDIR}/COPYING;md5=c79ff39f19dfec6d293b95d
> | ea7b07891 \
> | file://${LAYERDIR}/COPYING.LESSER;md5=bfccfe952269fff2
> | b407dd11f2f3083b"
>
> ... which looks good but don't work (I'm on 1.3_M3).
This doesn't work because LAYERDIR is not valid outside of layer.conf.
Some possible solutions:
1) Use something like e.g. ${THISDIR}/../../COPYING.LESSER; seems quite clunky
though.
2) Set your own variable to the value of LAYERDIR in layer.conf and then use
that in the recipe; however that would make the recipe even more hardwired to
the specific layer.
3) Refer to a license file in ${COMMON_LICENSE_DIR}; this is discouraged as it
may break if files in there are moved around although I think that is less
likely in future.
4) Copy the license file into the directory containing the recipe. This is the
recommended method for recipes that do actually distribute files, but seems
excessive for a task.
Ultimately though is it really important that the license for a recipe that
distributes no files be any particular license?
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] License information of tasks
On Fri, Aug 24, 2012 at 11:39:10AM +0100, Paul Eggleton wrote:
> On Friday 24 August 2012 12:05:41 Markus Hubig wrote:
> >
> > First: tasks are packages without content.
> >
> > | rpm -qpl task-core-boot-1.0-r9.stamp9g20.rpm
> > | (contains no files)
> >
> > ... so why do they need some license information in the first place?
>
> This is something that annoys me as well. I have thought about adding the
> ability to declare that a license is not applicable for those recipes that
> don't actually distribute any files, in which case a check during do_deploy,
> do_package and do_populate_sysroot would be enabled that would fail if the
> recipe ended up distributing anything. Unfortunately we don't have hooks in
> all of the necessary places to make this practical, but it is still something
> I would like to resolve.
Hmm, it seems you don't have to use LIC_FILES_CHKSUM in a image recipe. So
maybe one can adapt it from there ...
> 2) Set your own variable to the value of LAYERDIR in layer.conf and then use
> that in the recipe; however that would make the recipe even more hardwired to
> the specific layer.
Hmm OK but this seems nevertheless a good solution ... will try it.
> 3) Refer to a license file in ${COMMON_LICENSE_DIR}; this is discouraged as
> it
> may break if files in there are moved around although I think that is less
> likely in future.
Also OK IMHO ...
> 4) Copy the license file into the directory containing the recipe. This is
> the
> recommended method for recipes that do actually distribute files, but seems
> excessive for a task.
That's bad cause I have to duplicate all files this way. My first thought was
to use the License files I already included into my layers for this ...
> Ultimately though is it really important that the license for a recipe that
> distributes no files be any particular license?
Yes I also think these files (themselves) are covered my the layer license and
since they don't distribute any files don't need an additional license.
Maybe some day there will be a distinction of the licence information between
the Yocto stuff like Layers, tasks, images and recipes and the created
software.
Cheers, Markus
--
Human beings were created by water to transport it uphill.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] 1.3 M3 Full Pass test results
Hello Richard, Even if the installer is used in the default mode, issues still occur (see comment 7). I think the root cause for these is the same, so I did not submit a new bug. Thank you, Laurentiu -Original Message- From: Purdie, Richard Sent: Friday, August 24, 2012 1:22 PM To: Serban, Laurentiu Cc: yocto@yoctoproject.org; Liu, Song; Stewart, David C; Wold, Saul Subject: Re: 1.3 M3 Full Pass test results On Thu, 2012-08-23 at 20:13 +0100, Serban, Laurentiu wrote: > Here are the results for the full pas tests on 1.3 M3 RC2. The commit > used for testing is 8b8748c8f963900b83dc0fdd7757556f917fe4fd. > > Some details about the encountered issues below: > > BSP – Sudoku-savant project build issue (2878) > > ADT – the relocatable sdk issue (2980) causes 13 test cases to be on > faile/blocked state I thought it worked as long as you didn't have to relocate it so no tests should have been blocked, we just have the relocation issue? > , also the Clutter C template issue is unsolved (2577) > > Core Build System – x32 is still an issue (2888), cleaning sstate > issue is still not solved (2897), incremental RPM image generation > (2969), source archiving (2619), the kvm issue was reproduced by > another colleague (2790) Yocto BSP creation via JSON (2693) or for > qemu (2991) fails, multilib issue (2918 – this requires a little more > investigation from QA), > > HOB - all seems ok for RC2 > > Self-hosted-image - cannot start on Virtual Box (X issue), it is very > slow on qemu and it has a m4 package build (3005) issue on VMWare. If > the self-hosted-image is used on machine with internet connectivity > via proxy there will be an initial sanity check failure, but this is > not a blocking issue. > > A mention for the performance testing: on a Ubbuntu 12.04 i7 machine > using 8 threads the build time was 83 minutes (with prior fetching). How does this compare with our other performance numbers. From what I remember, we used to hover around the 105-115 minute mark. Did we have some significant speed gains or is this just an artefact of changing the test machine? Cheers, Richard ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [linux-yocto-3.2][PATCH] arm: Fix linking errors with binutils 2.23
On 12-08-22 04:22 PM, Khem Raj wrote: On Wed, Aug 22, 2012 at 12:24 PM, Bruce Ashfield wrote: I haven't looked yet, will 3.4+ need the same fix ? yes looking at 3.4 code. But havent tried that yet I've merged this to the 3.2 tree and the 3.4 tree. I haven't seen any build failures, but then again, I wasn't seeing any before :) It's pushed to the kernel trees, I'll send some SRCREV updates later today. Cheers, Bruce ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/3] Add -ptest package group
On Thu, 2012-08-23 at 16:20 +0200, Björn Stenberg wrote:
> This patch creates a new package group -ptest to contain the tests for
> each package.
>
> ---
> meta/classes/distutils-common-base.bbclass |5 -
> meta/classes/image.bbclass |6 --
> meta/classes/package.bbclass |8 ++--
> meta/classes/task.bbclass |2 +-
> meta/conf/bitbake.conf | 14 --
> 5 files changed, 27 insertions(+), 8 deletions(-)
>
> diff --git a/meta/classes/distutils-common-base.bbclass
> b/meta/classes/distutils-common-base.bbclass
> index f66a5cd..7db015b 100644
> --- a/meta/classes/distutils-common-base.bbclass
> +++ b/meta/classes/distutils-common-base.bbclass
> @@ -5,7 +5,7 @@ EXTRA_OEMAKE = ""
> export STAGING_INCDIR
> export STAGING_LIBDIR
>
> -PACKAGES = "${PN}-dev ${PN}-dbg ${PN}-doc ${PN}"
> +PACKAGES = "${PN}-dev ${PN}-dbg ${PN}-ptest ${PN}-doc ${PN}"
>
> FILES_${PN} = "${bindir}/* ${libdir}/* ${libdir}/${PYTHON_DIR}/*"
>
> @@ -19,3 +19,6 @@ FILES_${PN}-dbg += "\
>${PYTHON_SITEPACKAGES_DIR}/*/.debug \
>${PYTHON_SITEPACKAGES_DIR}/*/*/.debug \
> "
> +FILES_${PN}-ptest += "\
> + ${PYTHON_SITEPACKAGES_DIR}/${PTEST_NAME} \
> +"
> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> index 72720f1..c154bc2 100644
> --- a/meta/classes/image.bbclass
> +++ b/meta/classes/image.bbclass
> @@ -29,13 +29,13 @@ ROOTFS_BOOTSTRAP_INSTALL =
> "${@base_contains("IMAGE_FEATURES", "package-manageme
> FEATURE_INSTALL = "${@'
> '.join(oe.packagegroup.required_packages(oe.data.typed_value('IMAGE_FEATURES',
> d), d))}"
> FEATURE_INSTALL_OPTIONAL = "${@'
> '.join(oe.packagegroup.optional_packages(oe.data.typed_value('IMAGE_FEATURES',
> d), d))}"
>
> -# packages to install from features, excluding dev/dbg/doc
> +# packages to install from features, excluding dev/dbg/doc/ptest
> NORMAL_FEATURE_INSTALL = "${@'
> '.join(oe.packagegroup.required_packages(normal_groups(d), d))}"
> NORMAL_FEATURE_INSTALL_OPTIONAL = "${@'
> '.join(oe.packagegroup.optional_packages(normal_groups(d), d))}"
>
> def normal_groups(d):
> """Return all the IMAGE_FEATURES, with the exception of our special
> package groups"""
> -extras = set(['dev-pkgs', 'staticdev-pkgs', 'doc-pkgs', 'dbg-pkgs'])
> +extras = set(['dev-pkgs', 'staticdev-pkgs', 'doc-pkgs', 'dbg-pkgs',
> 'ptest-pkgs'])
> features = set(oe.data.typed_value('IMAGE_FEATURES', d))
> return features.difference(extras)
>
> @@ -53,6 +53,8 @@ def complementary_globs(featurevar, d):
> globs.append('*-doc')
> elif feature == 'dbg-pkgs':
> globs.append('*-dbg')
> +elif feature == 'ptest-pkgs':
> +globs.append('*-ptest')
> return ' '.join(globs)
>
> IMAGE_INSTALL_COMPLEMENTARY = '${@complementary_globs("IMAGE_FEATURES", d)}'
> diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
> index d122cd9..6483a1f 100644
> --- a/meta/classes/package.bbclass
> +++ b/meta/classes/package.bbclass
> @@ -1236,7 +1236,7 @@ python package_do_filedeps() {
>
> # Determine dependencies
> for pkg in packages.split():
> -if pkg.endswith('-dbg') or pkg.endswith('-doc') or
> pkg.find('-locale-') != -1 or pkg.find('-localedata-') != -1 or
> pkg.find('-gconv-') != -1 or pkg.find('-charmap-') != -1 or
> pkg.startswith('kernel-module-'):
> +if pkg.endswith('-dbg') or pkg.endswith('-doc') or
> pkg.find('-locale-') != -1 or pkg.find('-localedata-') != -1 or
> pkg.find('-gconv-') != -1 or pkg.find('-charmap-') != -1 or
> pkg.startswith('kernel-module-') or pkg.endswith('-ptest'):
> continue
I think filedeps could be useful in this case, autodetecting any
dependencies scripts in the -ptest package could have for example so I'd
not do the above.
>
> provides_files = []
> @@ -1330,7 +1330,7 @@ python package_do_shlibs() {
> combos.append("-".join(options[0:i]))
> return combos
>
> -if (file.endswith('.dylib') or file.endswith('.so')) and not
> pkg.endswith('-dev') and not pkg.endswith('-dbg'):
> +if (file.endswith('.dylib') or file.endswith('.so')) and not
> pkg.endswith('-dev') and not pkg.endswith('-dbg') and not
> pkg.endswith('-ptest'):
ditto, we want to detect shlib dependencies.
> # Drop suffix
> name = file.rsplit(".",1)[0]
> # Find all combinations
> @@ -1648,6 +1648,8 @@ python package_depchains() {
> depend = depend.replace('-dev', '')
> if depend.endswith('-dbg'):
> depend = depend.replace('-dbg', '')
> +if depend.endswith('-ptest'):
> +depend = depend.replace('-ptest', '')
> pkgname = getname(depend, suffix)
> #bb.note("Adding %s for %s" % (pkgname, depend))
> if pkgname not in rreclist and pkgname != pkg:
> @@ -1669,6 +
[yocto] [PATCH] Yocto-BSP Properties - Layout, Grouping and Naming refactorization
- re-grouped preferences by yocto-bsp logic
- re-arranged & aligned controls
Signed-off-by: Ioana Grigoropol
---
.../sdk/remotetools/YoctoBspPropertyElement.java | 23 +-
.../sdk/remotetools/wizards/bsp/MainPage.java | 11 +-
.../remotetools/wizards/bsp/PropertiesPage.java| 418 +++-
.../remotetools/wizards/bsp/YoctoBSPWizard.java|6 -
4 files changed, 257 insertions(+), 201 deletions(-)
diff --git
a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/YoctoBspPropertyElement.java
b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/YoctoBspPropertyElement.java
index a67a5f8..e88b4bd 100644
---
a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/YoctoBspPropertyElement.java
+++
b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/YoctoBspPropertyElement.java
@@ -10,7 +10,7 @@
***/
package org.yocto.sdk.remotetools;
-public class YoctoBspPropertyElement {
+public class YoctoBspPropertyElement implements
Comparable{
private String name;
private String type;
private String value;
@@ -27,32 +27,39 @@ public class YoctoBspPropertyElement {
public String getName() {
return name;
}
-
+
public void setName(String value) {
name = value;
}
-
+
public String getType() {
return type;
}
-
+
public void setType(String value) {
type = value;
}
-
+
public String getDefaultValue() {
return defaultValue;
}
-
+
public void setDefaultValue(String value) {
this.defaultValue = value;
}
-
+
public String getValue() {
return value;
}
-
+
public void setValue(String value) {
this.value = value;
}
+
+ @Override
+ public int compareTo(YoctoBspPropertyElement o) {
+ return type.compareTo(o.type);
+ }
+
+
}
diff --git
a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/MainPage.java
b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/MainPage.java
index 4a1bbea..5899c8e 100644
---
a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/MainPage.java
+++
b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/MainPage.java
@@ -79,7 +79,7 @@ public class MainPage extends WizardPage {
private YoctoBspElement bspElem;
public MainPage(YoctoBspElement element) {
- super(PAGE_NAME, "yocto-bsp main page", null);
+ super(PAGE_NAME, "yocto-bsp Main page", null);
setMessage("Enter the required fields(with *) to create new
Yocto Project BSP!");
this.bspElem = element;
@@ -89,15 +89,14 @@ public class MainPage extends WizardPage {
public void createControl(Composite parent) {
setErrorMessage(null);
Composite composite = new Composite(parent, SWT.NONE);
- GridData gd = new GridData(SWT.FILL, SWT.CENTER, true, false);
GridLayout layout = new GridLayout(2, false);
+ GridData gd = new GridData(SWT.FILL, SWT.CENTER, true, false);
composite.setLayout(layout);
-
gd.horizontalSpan = 2;
composite.setLayoutData(gd);
labelMetadata = new Label(composite, SWT.NONE);
- labelMetadata.setText("Meta_data location*: ");
+ labelMetadata.setText("Metadata location*: ");
Composite textContainer = new Composite(composite, SWT.NONE);
textContainer.setLayout(new GridLayout(2, false));
textContainer.setLayoutData(new GridData(SWT.FILL, SWT.CENTER,
true, false));
@@ -140,7 +139,7 @@ public class MainPage extends WizardPage {
});
labelBspOutput = new Label(composite, SWT.NONE);
- labelBspOutput.setText("Bsp output location: ");
+ labelBspOutput.setText("BSP output location: ");
textContainer = new Composite(composite, SWT.NONE);
textContainer.setLayout(new GridLayout(2, false));
@@ -156,7 +155,7 @@ public class MainPage extends WizardPage {
setBtnBspOutLoc(addFileSelectButton(textContainer,
textBspOutputLoc));
labelKArch = new Label(composite, SWT.NONE);
- labelKArch.setText("kernel Architecture*: ");
+ labelKArch.setText("Kernel Architecture*: ");
textContainer = new Composite(composite, SWT.NONE);
textContainer.setLayout(new GridLayout(2, false));
diff --git
a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards
[yocto] Errors while creating a new PowerPC 405e tune file
Hi,
I have defined a tune-ppc405e.inc ( suffixed with an 'e' to signify that
it has a hardware floating point unit attached), as follows:
DEFAULTTUNE ?= "ppc405e"
require conf/machine/include/powerpc/arch-powerpc.inc
TUNEVALID[ppc405e] = "Enable ppc405e specific processor optimizations"
TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppc405e", "-mcpu=405fp",
"", d)}"
AVAILTUNES += "ppc405e"
TUNE_FEATURES_tune-ppc405e = "m32 ppc405e fpu-hard"
TUNE_PKGARCH_tune-ppc440e = "ppc405e"
PACKAGE_EXTRA_ARCHS_tune-ppc405e = "${PACKAGE_EXTRA_ARCHS_tune-powerpc} ppc405e"
# glibc configure options to get ppc405e specific library (for sqrt)
GLIBC_EXTRA_OECONF += "${@bb.utils.contains("TUNE_FEATURES", "ppc405e",
"-with-cpu=405fp", "", d)}"
And in my machine, should I be defining TARGET_CPU = "405fp" or "405e" ?
TARGET_CPU = "405fp"
#tune for the 405e cpu
require conf/machine/include/tune-ppc405e.inc
The gcc compiler options for -mcpu=cpu_type can be one of '405' or '405fp'.
I can't get bitbake to build it for some reason, I keep getting errors like
this:
$ bitbake -c fetchall core-image-minimal
Pseudo is not present but is required, building this first before the main build
NOTE: Error expanding variable oe_runconf
| ETA: 00:00:50
NOTE: Error during finalise of
/tool/yocto/meta-openembedded/toolchain-layer/recipes-devtools/gcc/gcc-cross-initial_4.5.bb
ERROR: ExpansionError during parsing
/tool/yocto/meta-openembedded/toolchain-layer/recipes-devtools/gcc/gcc-cross-initial_4.5.bb:
Failure expanding variable EXTRA_OECONF, expression was --with-newlib
--without-headers --disable-shared
--disable-threads --disable-multilib
--disable-__cxa_atexit --enable-languages=c
--program-prefix=powerpc-poky-linux-
--with-sysroot=/tool/yocto/poky/build/tmp/sysroots/virtex5
--with-build-sysroot=/tool/yocto/poky/build/tmp/work/${TUNE_PKGARCH_tune-ppc405e}-poky-linux/gcc-cross-initial-4.5.1+svnr162773-r14/gcc-4_5-branch/build.x86_64-linux.powerpc-poky-linux/tmpsysroot
--disable-libmudflap--disable-libgomp
--disable-libssp--enable-decimal-float=no
${@base_contains('DISTRO_FEATURES', 'ld-is-gold',
'--with-ld=/tool/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/bin/${TUNE_PKGARCH_tune-ppc405e}-poky-linux/powerpc-poky-linux-ld.bfd',
'', d)}${@gettext_oeconf(d)} --enable-__cxa_atexit
--with-long-double-128 which triggered exception SyntaxError: EOL while
scanning string literal (EXTRA_OECONF, line 1)
NOTE: Error expanding variable do_install
NOTE: Error during finalise of
/tool/yocto/meta-openembedded/toolchain-layer/recipes-devtools/gcc/gcc-cross_4.5.bb
ERROR: OE-core's config sanity checker detected a potential misconfiguration.
Either fix the cause of this error or at your own risk disable the checker
(see sanity.conf).
Following is the list of potential problems / advisories:
Error, the PACKAGE_ARCHS variable does not contain TUNE_PKGARCH
(${TUNE_PKGARCH_tune-ppc405e}).
ERROR: Execution of event handler 'check_sanity_eventhandler' failed
ERROR: Command execution failed: Exited with 1
Summary: There were 4 ERROR messages shown, returning a non-zero exit code.
Is this some how related to expanding the variable EXTRA_OECONF_FPU in
gcc-cross-initial.inc (I'm working on a commit that is before Khem's recent
rework on gcc-4.7)
EXTRA_OECONF = "--with-newlib \
--without-headers \
--disable-shared \
--disable-threads \
--disable-multilib \
--disable-__cxa_atexit \
--enable-languages=c \
${OPTSPACE} \
--program-prefix=${TARGET_PREFIX} \
--with-sysroot=${STAGING_DIR_TARGET} \
--with-build-sysroot=${GCCCROSS_BUILDSYSROOT} \
${EXTRA_OECONF_INITIAL} \
${@base_contains('DISTRO_FEATURES', 'ld-is-gold',
'--with-ld=${STAGING_BINDIR_TOOLCHAIN}/${TARGET_PREFIX}ld.bfd', '', d)} \
${EXTRA_OECONF_FPU}"
Best regards,
Elvis Dowson
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 3/3] Enable bash-ptest
On Thu, 2012-08-23 at 16:20 +0200, Björn Stenberg wrote:
> Patch Makefile.in to allow test programs be built on host and ran on
> target.
> Patch tests/run-all to output PASS/FAIL for each testcase.
> Patch recipe to build and install test programs and test suite.
>
> ---
> .../bash/bash-4.2/build-tests.patch| 29
>
> meta/recipes-extended/bash/bash-4.2/run-ptest |2 +
> .../bash/bash-4.2/test-output.patch| 19 +
> meta/recipes-extended/bash/bash.inc| 18
> meta/recipes-extended/bash/bash_4.2.bb |5 +++-
> 5 files changed, 72 insertions(+), 1 deletions(-)
> create mode 100644 meta/recipes-extended/bash/bash-4.2/build-tests.patch
> create mode 100644 meta/recipes-extended/bash/bash-4.2/run-ptest
> create mode 100644 meta/recipes-extended/bash/bash-4.2/test-output.patch
>
> diff --git a/meta/recipes-extended/bash/bash-4.2/build-tests.patch
> b/meta/recipes-extended/bash/bash-4.2/build-tests.patch
> new file mode 100644
> index 000..e92fab3
> --- /dev/null
> +++ b/meta/recipes-extended/bash/bash-4.2/build-tests.patch
> @@ -0,0 +1,29 @@
> +diff -uNr a/Makefile.in b/Makefile.in
> +--- a/Makefile.in2012-06-14 10:15:15.063465304 +0200
> b/Makefile.in2012-06-14 10:47:02.985115849 +0200
> +@@ -827,18 +827,21 @@
> + fi
> +
> + recho$(EXEEXT): $(SUPPORT_SRC)recho.c
> +-@$(CC_FOR_BUILD) $(CCFLAGS_FOR_BUILD) -o $@ $(SUPPORT_SRC)recho.c
> ${LIBS_FOR_BUILD}
> ++@$(CC) $(CCFLAGS) $(LDFLAGS) -o $@ $<
> +
> + zecho$(EXEEXT): $(SUPPORT_SRC)zecho.c
> +-@$(CC_FOR_BUILD) $(CCFLAGS_FOR_BUILD) -o $@ $(SUPPORT_SRC)zecho.c
> ${LIBS_FOR_BUILD}
> ++@$(CC) $(CCFLAGS) $(LDFLAGS) -o $@ $<
> +
> + printenv$(EXEEXT): $(SUPPORT_SRC)printenv.c
> +-@$(CC_FOR_BUILD) $(CCFLAGS_FOR_BUILD) -o $@ $(SUPPORT_SRC)printenv.c
> ${LIBS_FOR_BUILD}
> ++@$(CC) $(CCFLAGS) $(LDFLAGS) -o $@ $<
> +
> + xcase$(EXEEXT): $(SUPPORT_SRC)xcase.c
> +-@$(CC_FOR_BUILD) $(CCFLAGS_FOR_BUILD) -o $@ $(SUPPORT_SRC)xcase.c
> ${LIBS_FOR_BUILD}
> ++@$(CC) $(CCFLAGS) $(LDFLAGS) -o $@ $<
> +
> + test tests check: force $(Program) $(TESTS_SUPPORT)
> ++$(MAKE) runtest
> ++
> ++runtest:
> + @-test -d tests || mkdir tests
> + @cp $(TESTS_SUPPORT) tests
> + @( cd $(srcdir)/tests && \
As it stands, I can bet on upstream saying "no" to this for good reason.
A better concept might be to introduce $(CC_FOR_TEST) which could
default to CC_FOR_BUILD. This would let us do what you're thinking here
yet keep upstream happy too.
Just thinking out loud really...
Cheers,
Richard
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] dev manual section on "customizing images" needs serious adjustment
On 08/23/2012 01:13 AM, Tomas Frydrych wrote: Hi, On 22/08/12 21:37, Robert P. J. Day wrote: One way to get additional software into an image is to create a custom image. The manual should make it clear that this is *the* canonical way to add software to your images. Modifications to local.conf are temporary tweaks for testing/debugging (i.e., you should never feel the need to commit your local.conf to some project version control system). Tomas +1. If you add additional packages to core-image-minimal in your local.conf, you're no longer really building core-image-minimal. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Errors while creating a new PowerPC 405e tune file
Hi, On Aug 24, 2012, at 7:39 PM, Elvis Dowson wrote: > TUNE_PKGARCH_tune-ppc440e = "ppc405e" My bad, it was a typo, I should have been written as follows: TUNE_PKGARCH_tune-ppc405e = "ppc405e" > And in my machine, should I be defining TARGET_CPU = "405fp" or "405e" ? > > TARGET_CPU = "405fp" > #tune for the 405e cpu > require conf/machine/include/tune-ppc405e.inc The only question I have now is, should I be defining TARGET_CPU as 405fp or 405e ? Best regards, Elvis Dowson___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] dev manual section on "customizing images" needs serious adjustment
On Fri, 24 Aug 2012, Scott Garman wrote: > On 08/23/2012 01:13 AM, Tomas Frydrych wrote: > > Hi, > > > > On 22/08/12 21:37, Robert P. J. Day wrote: > > > One way to get additional software into an image is to create a > > > custom image. > > > > The manual should make it clear that this is *the* canonical way to add > > software to your images. Modifications to local.conf are temporary > > tweaks for testing/debugging (i.e., you should never feel the need to > > commit your local.conf to some project version control system). > > > > Tomas > > +1. If you add additional packages to core-image-minimal in your local.conf, > you're no longer really building core-image-minimal. sure. but if you similarly explicitly set IMAGE_INSTALL before inheriting core-image, you're not really "inheriting" core-image either. :-) rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] TARGET_FPU not getting populated for powerpc 405/440 fpu-hard targets
Hi,
I just observed that TARGET_FPU is not getting populated, when you do a
build for fpu-hard targets. For fpu-soft targets, it displays TARGET_FPU =
"soft", but for fpu-hard targets, it display TARGET_FPU = "".
For example, for my tune-ppc440e.inc file
DEFAULTTUNE ?= "ppc440e"
require conf/machine/include/powerpc/arch-powerpc.inc
TUNEVALID[ppc440e] = "Enable ppc440e specific processor optimizations"
TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppc440e", "-mcpu=440fp",
"", d)}"
AVAILTUNES += "ppc440e"
TUNE_FEATURES_tune-ppc440e = "m32 ppc440e fpu-hard"
TUNE_PKGARCH_tune-ppc440e = "ppc440e"
PACKAGE_EXTRA_ARCHS_tune-ppc440e = "${PACKAGE_EXTRA_ARCHS_tune-powerpc} ppc440e"
# glibc configure options to get ppc440e specific library (for sqrt)
GLIBC_EXTRA_OECONF += "${@bb.utils.contains("TUNE_FEATURES", "ppc440e",
"-with-cpu=440fp", "", d)}"
it is empty:
uild Configuration:
BB_VERSION= "1.15.3"
TARGET_ARCH = "powerpc"
TARGET_OS = "linux"
MACHINE = "virtex5"
DISTRO= "poky"
DISTRO_VERSION= "1.2+snapshot-20120824"
TUNE_FEATURES = "m32 ppc440e fpu-hard"
TARGET_FPU= ""
meta
meta-yocto= "(nobranch):77192ec8ed3563920b969306aaa7609d05184255"
toolchain-layer = "(nobranch):3fd2bf4c5e6c3a353aff9795294b7c25f5f50c49"
meta-xilinx =
"master-xilinx-ml507-gcc-4.5:18ab4890b00d12c58f750008688d2e97687e33da"
Similarily, for my tune-ppc405e.inc file:
DEFAULTTUNE ?= "ppc405e"
require conf/machine/include/powerpc/arch-powerpc.inc
TUNEVALID[ppc405e] = "Enable ppc405e specific processor optimizations"
TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppc405e", "-mcpu=405fp",
"", d)}"
AVAILTUNES += "ppc405e"
TUNE_FEATURES_tune-ppc405e = "m32 ppc405e fpu-hard"
TUNE_PKGARCH_tune-ppc405e = "ppc405e"
PACKAGE_EXTRA_ARCHS_tune-ppc405e = "${PACKAGE_EXTRA_ARCHS_tune-powerpc} ppc405e"
# glibc configure options to get ppc405e specific library (for sqrt)
GLIBC_EXTRA_OECONF += "${@bb.utils.contains("TUNE_FEATURES", "ppc405e",
"-with-cpu=405fp", "", d)}"
it is empty:
Build Configuration:
BB_VERSION= "1.15.3"
TARGET_ARCH = "powerpc"
TARGET_OS = "linux"
MACHINE = "virtex5"
DISTRO= "poky"
DISTRO_VERSION= "1.2+snapshot-20120824"
TUNE_FEATURES = "m32 ppc405e fpu-hard"
TARGET_FPU= ""
meta
meta-yocto= "(nobranch):77192ec8ed3563920b969306aaa7609d05184255"
toolchain-layer = "(nobranch):3fd2bf4c5e6c3a353aff9795294b7c25f5f50c49"
meta-xilinx =
"master-xilinx-ml507-gcc-4.5:18ab4890b00d12c58f750008688d2e97687e33da"
The PowerPC405 and 440 processors are on a Xilinx Virtex-4 and Virtex-5 FGPA,
and as such can be attached to a hardware floating point unit.
There is a special gcc compiler option for this situation, which is
-mxilinx-fpu
Perform optimizations for the floating-point unit on Xilinx PPC 405/440. See
RS/6000 and PowerPC Options - Using the GNU Compiler Collection (GCC) for more
information.
What should I do to get TARGET_FPU to fill correctly for hardware floating
point units ?
Best regards,
Elvis Dowson
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Errors while creating a new PowerPC 405e tune file
On Fri, Aug 24, 2012 at 8:44 AM, Elvis Dowson wrote: > > The only question I have now is, should I be defining TARGET_CPU as 405fp or > 405e ? gcc only knows 405fp so thats what you use here ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] dev manual section on "customizing images" needs serious adjustment
On 24/08/12 16:45, Robert P. J. Day wrote: > On Fri, 24 Aug 2012, Scott Garman wrote: > >> On 08/23/2012 01:13 AM, Tomas Frydrych wrote: >>> Hi, >>> >>> On 22/08/12 21:37, Robert P. J. Day wrote: One way to get additional software into an image is to create a custom image. >>> >>> The manual should make it clear that this is *the* canonical way to add >>> software to your images. Modifications to local.conf are temporary >>> tweaks for testing/debugging (i.e., you should never feel the need to >>> commit your local.conf to some project version control system). >>> >>> Tomas >> >> +1. If you add additional packages to core-image-minimal in your local.conf, >> you're no longer really building core-image-minimal. > > sure. but if you similarly explicitly set IMAGE_INSTALL before > inheriting core-image, you're not really "inheriting" core-image > either. :-) That is quite a different thing: core-image-minimal is a recipe to build an image with defined contents, in contrast core-image is a class, and the whole point of classes is that recipes can inherit and override them. Tomas ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] TARGET_FPU not getting populated for powerpc 405/440 fpu-hard targets
On Fri, Aug 24, 2012 at 9:27 AM, Elvis Dowson wrote: >I just observed that TARGET_FPU is not getting populated, when you do > a build for fpu-hard targets. For fpu-soft targets, it displays TARGET_FPU = > "soft", but for fpu-hard targets, it display TARGET_FPU = "". that means default is hard for this architecture. This option is essentially used to configure gcc unless your fpu is special like fsl one's you are good here. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] TARGET_FPU not getting populated for powerpc 405/440 fpu-hard targets
Hi Khem,
On Aug 24, 2012, at 8:35 PM, Khem Raj wrote:
> On Fri, Aug 24, 2012 at 9:27 AM, Elvis Dowson wrote:
>> I just observed that TARGET_FPU is not getting populated, when you do
>> a build for fpu-hard targets. For fpu-soft targets, it displays TARGET_FPU =
>> "soft", but for fpu-hard targets, it display TARGET_FPU = "".
>
> that means default is hard for this architecture. This option is
> essentially used to configure gcc
> unless your fpu is special like fsl one's you are good here.
The FPU unit is an IP core, that is attached to a generic PowerPC405 or
PowerPC440 embedded processor core on the FPGA, which by default doesn't
contain an FPU unit.
In the Xilinx FPGA hardware project, I have to add this FPU unit, and there are
some additional options that I can see relevant to this setup with the FPU
unit, such as -mxilinx-fpu and -mfpu=dp_full
Should I specify them in TUNE_CCARGS (as shown below) or
TUNE_FEATURES_tune-ppc405e (not done below) or specify the same values for both
variables ?
TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppc405e", "-mcpu=405fp
-mxilinx-fpu -mfpu=dp_full", "", d)}"
AVAILTUNES += "ppc405e"
TUNE_FEATURES_tune-ppc405e = "m32 ppc405e fpu-hard"
Best regards,
Elvis Dowson___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] TARGET_FPU not getting populated for powerpc 405/440 fpu-hard targets
On Fri, Aug 24, 2012 at 9:49 AM, Elvis Dowson wrote:
>
> Should I specify them in TUNE_CCARGS (as shown below) or
> TUNE_FEATURES_tune-ppc405e (not done below) or specify the same values for
> both variables ?
>
> TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppc405e",
> "-mcpu=405fp -mxilinx-fpu -mfpu=dp_full", "", d)}"
yes. However if there are some special ABI extentions becasue of FP
that gcc should configure itself with
then that should be specified in TARGET_FPU. I havent looked into gcc
code to check if it knows about xilinx-fpu
at configure time
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] TARGET_FPU not getting populated for powerpc 405/440 fpu-hard targets
On 8/24/12 11:49 AM, Elvis Dowson wrote:
Hi Khem,
On Aug 24, 2012, at 8:35 PM, Khem Raj wrote:
On Fri, Aug 24, 2012 at 9:27 AM, Elvis Dowson mailto:elvis.dow...@gmail.com>> wrote:
I just observed that TARGET_FPU is not getting populated, when you do
a build for fpu-hard targets. For fpu-soft targets, it displays TARGET_FPU =
"soft", but for fpu-hard targets, it display TARGET_FPU = "".
that means default is hard for this architecture. This option is
essentially used to configure gcc
unless your fpu is special like fsl one's you are good here.
The FPU unit is an IP core, that is attached to a generic PowerPC405 or
PowerPC440 embedded processor core on the FPGA, which by default doesn't contain
an FPU unit.
In the Xilinx FPGA hardware project, I have to add this FPU unit, and there are
some additional options that I can see relevant to this setup with the FPU unit,
such as -mxilinx-fpu and -mfpu=dp_full
Should I specify them in TUNE_CCARGS (as shown below)
or TUNE_FEATURES_tune-ppc405e (not done below) or specify the same values for
both variables ?
TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppc405e", "-mcpu=405fp
-mxilinx-fpu -mfpu=dp_full", "", d)}"
AVAILTUNES += "ppc405e"
TUNE_FEATURES_tune-ppc405e = "m32 ppc405e fpu-hard"
fpu-hard is the classic PowerPC FPU unit. If that is what these ip blocks
implement then there is nothing further required.
If the unit does NOT include a classic PowerPC FPU, then you should not be using
fpu-hard.
If it -also- implements additional FPU instructions via the -m...fpu stuff
specific to the IP blocks, then that is where the target_fpu comes in and some
other changes will be necessary It's been a while since I worked through
this, but the e500 stuff may be a reasonable example of how to implement it.
--Mark
Best regards,
Elvis Dowson
___
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] configuring WiFi in Yocto
When I configured WiFi with Yocto on a n450 based netbook, all I had to do was get the right drivers for the hardware included in the Yocto 3.2 kernel, then I could use the GUI Connection Manager to configure the WiFi so the hardware would connect to my WiFi network. However, I'm now trying to configure a different WiFi on a Cedartrail system. The card is a Realtek RTL8188CE and the hardware is a DN2800MT Cedartrail board. For Cedartrail the current BSP under Denzil is on kernel 3.0. Not sure what made the difference, but Connection Manager does not have an option for Wireless networks. iwconfig list both lo and eth0, both of course have no wireless extensions. I was expecting to see wlan0. If I do lspci -v, it shows I have my RTL8188CE hardware connected to the kernel module rtl8192ce, which was loaded in support of the wifi card along with the other modules I put into my config fragment file: CONFIG_RTL8192CE=m CONFIG_RTL8192C_COMMON=m CONFIG_RTLWIFI=m CONFIG_MAC80211=m CONFIG_CFG80211=m What does it take to get the wlan0 device so Connection Manger will recognize it? Jim A ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 3/3] Enable bash-ptest
On 08/23/2012 07:20 AM, Björn Stenberg wrote:
Patch Makefile.in to allow test programs be built on host and ran on
target.
Patch tests/run-all to output PASS/FAIL for each testcase.
Patch recipe to build and install test programs and test suite.
---
.../bash/bash-4.2/build-tests.patch| 29
meta/recipes-extended/bash/bash-4.2/run-ptest |2 +
.../bash/bash-4.2/test-output.patch| 19 +
meta/recipes-extended/bash/bash.inc| 18
meta/recipes-extended/bash/bash_4.2.bb |5 +++-
5 files changed, 72 insertions(+), 1 deletions(-)
create mode 100644 meta/recipes-extended/bash/bash-4.2/build-tests.patch
create mode 100644 meta/recipes-extended/bash/bash-4.2/run-ptest
create mode 100644 meta/recipes-extended/bash/bash-4.2/test-output.patch
diff --git a/meta/recipes-extended/bash/bash-4.2/build-tests.patch
b/meta/recipes-extended/bash/bash-4.2/build-tests.patch
new file mode 100644
index 000..e92fab3
--- /dev/null
+++ b/meta/recipes-extended/bash/bash-4.2/build-tests.patch
Thanks for proposing and getting the initial implementation started,
this has been something we have been thinking about for a while, great
to have the things like this become reality!
When introducing new patches, please follow the guidelines for patches
and commit message:
http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
I know this is still and RFC, but your commits themselves also need
Signed-off-by:
@@ -0,0 +1,29 @@
+diff -uNr a/Makefile.in b/Makefile.in
+--- a/Makefile.in 2012-06-14 10:15:15.063465304 +0200
b/Makefile.in 2012-06-14 10:47:02.985115849 +0200
+@@ -827,18 +827,21 @@
+ fi
+
+ recho$(EXEEXT): $(SUPPORT_SRC)recho.c
+- @$(CC_FOR_BUILD) $(CCFLAGS_FOR_BUILD) -o $@ $(SUPPORT_SRC)recho.c
${LIBS_FOR_BUILD}
++ @$(CC) $(CCFLAGS) $(LDFLAGS) -o $@ $<
+
+ zecho$(EXEEXT): $(SUPPORT_SRC)zecho.c
+- @$(CC_FOR_BUILD) $(CCFLAGS_FOR_BUILD) -o $@ $(SUPPORT_SRC)zecho.c
${LIBS_FOR_BUILD}
++ @$(CC) $(CCFLAGS) $(LDFLAGS) -o $@ $<
+
+ printenv$(EXEEXT):$(SUPPORT_SRC)printenv.c
+- @$(CC_FOR_BUILD) $(CCFLAGS_FOR_BUILD) -o $@ $(SUPPORT_SRC)printenv.c
${LIBS_FOR_BUILD}
++ @$(CC) $(CCFLAGS) $(LDFLAGS) -o $@ $<
+
+ xcase$(EXEEXT): $(SUPPORT_SRC)xcase.c
+- @$(CC_FOR_BUILD) $(CCFLAGS_FOR_BUILD) -o $@ $(SUPPORT_SRC)xcase.c
${LIBS_FOR_BUILD}
++ @$(CC) $(CCFLAGS) $(LDFLAGS) -o $@ $<
+
+ test tests check: force $(Program) $(TESTS_SUPPORT)
++ $(MAKE) runtest
++
++runtest:
+ @-test -d tests || mkdir tests
+ @cp $(TESTS_SUPPORT) tests
+ @( cd $(srcdir)/tests && \
diff --git a/meta/recipes-extended/bash/bash-4.2/run-ptest
b/meta/recipes-extended/bash/bash-4.2/run-ptest
new file mode 100644
index 000..8dd3b99
--- /dev/null
+++ b/meta/recipes-extended/bash/bash-4.2/run-ptest
@@ -0,0 +1,2 @@
+#!/bin/sh
+make -k THIS_SH=/bin/bash BUILD_DIR=. runtest
diff --git a/meta/recipes-extended/bash/bash-4.2/test-output.patch
b/meta/recipes-extended/bash/bash-4.2/test-output.patch
new file mode 100644
index 000..065a85c
--- /dev/null
+++ b/meta/recipes-extended/bash/bash-4.2/test-output.patch
@@ -0,0 +1,19 @@
+diff -uNr a/tests/run-all b/tests/run-all
+--- a/tests/run-all2012-06-14 10:15:15.007467700 +0200
b/tests/run-all2012-06-14 10:19:26.464678067 +0200
+@@ -22,6 +22,14 @@
+ case $x in
+ $0|run-minimal|run-gprof) ;;
+ *.orig|*~) ;;
+- *) echo $x ; sh $x ;;
++ *) echo $x
++ output=`sh $x`
++ if [ -n "$output" ]; then
++ echo "$output"
++ echo "FAIL: $x"
++ else
++ echo "PASS: $x"
++ fi
++ ;;
+ esac
+ done
diff --git a/meta/recipes-extended/bash/bash.inc
b/meta/recipes-extended/bash/bash.inc
index 3684191..04f9940 100644
--- a/meta/recipes-extended/bash/bash.inc
+++ b/meta/recipes-extended/bash/bash.inc
@@ -21,18 +21,36 @@ ALTERNATIVE_PRIORITY = "100"
export AUTOHEADER = "true"
+RDEPENDS_${PN}-ptest += "make"
+FILES_${PN}-dbg += "${PTEST_PATH}/.debug"
+
do_configure_prepend () {
if [ ! -e acinclude.m4 ]; then
cat aclocal.m4 > acinclude.m4
fi
}
+do_compile_append () {
+ oe_runmake recho zecho printenv xcase
+}
+
One thing that we have discussed a couple of times, but no real outcome
yet is to make the building of tests conditional so as more recipes are
enabled with this kind of change, we don't extend the default build time
too long.
What's been discussed is using DISTRO_FEATURE to test first.
Thoughts?
do_install_append () {
# Move /usr/bin/bash to /bin/bash, if need
if [ "${base_bindir}" != "${bindir}" ]; then
mkdir -p ${D}${base_bindir}
mv ${D}${bindir}/bash ${D}${base_bindir}
[yocto] New task progress interface with Yocto 1.3 ?
Hi, I'm building against the latest yocto master branch, and noticed that the task progress now summarizes the total number of active theads: NOTE: Resolving any missing task queue dependencies NOTE: Preparing runqueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks Currently 6 running tasks (334 of 1485): 0: icu-native-3.6-r9 do_compile (pid 58438) 1: python-native-2.7.3-r0.1 do_compile (pid 31435) 2: popt-native-1.16-r2 do_configure (pid 55290) 3: gnutls-native-2.12.20-r8.3 do_compile (pid 55897) 4: acl-native-2.2.51-r3 do_configure (pid 56626) 5: libpcre-native-8.31-r0 do_configure (pid 62244) Is this update part of the upcoming Yocto 1.3 release? Best regards, Elvis Dowson___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] New task progress interface with Yocto 1.3 ?
Yes isn't it cool On Friday, August 24, 2012, Elvis Dowson wrote: > Hi, > I'm building against the latest yocto master branch, and noticed that the task progress now summarizes the total number of active theads: > NOTE: Resolving any missing task queue dependencies > NOTE: Preparing runqueue > NOTE: Executing SetScene Tasks > NOTE: Executing RunQueue Tasks > Currently 6 running tasks (334 of 1485): > 0: icu-native-3.6-r9 do_compile (pid 58438) > 1: python-native-2.7.3-r0.1 do_compile (pid 31435) > 2: popt-native-1.16-r2 do_configure (pid 55290) > 3: gnutls-native-2.12.20-r8.3 do_compile (pid 55897) > 4: acl-native-2.2.51-r3 do_configure (pid 56626) > 5: libpcre-native-8.31-r0 do_configure (pid 62244) > Is this update part of the upcoming Yocto 1.3 release? > Best regards, > Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] New task progress interface with Yocto 1.3 ?
On Aug 25, 2012, at 12:56 AM, Khem Raj wrote: > Yes isn't it cool Yes, it's definitely an improvement! Elvis ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 0/2][meta-intel] Cover letter to update pvr driver to v1.0.2 in meta-cedartral, denzil branch
From: Rahul Saxena Cover letter to update pvr driver to v1.0.2 in meta-cedartrail. This update of the driver supports B3 stepping of the Cedarview processor and also supports DP/eDP ports. Please update denzil branch with this patch series. Signed-off-by: Rahul Saxena -- The following changes since commit ff7fdafba88a5b7676f601b3d16a97ce7d48c4a9: crownbay: make v3.4 the default kernel (2012-07-31 23:08:05 -0500) are available in the git repository at: git://git.pokylinux.org/meta-intel-contrib rsaxena_1_3_M3 http://git.pokylinux.org/cgit.cgi/meta-intel-contrib/log/?h=rsaxena_1_3_M3 Rahul Saxena (2): meta-cedartrail: Update SRCREV for the linux-yocto kernel pvr branch meta-cedartrail: Update PVR graphics driver to version 1.0.2 meta-cedartrail/README |2 +- .../xorg-driver/cdv-pvr-driver.inc | 37 - .../xorg-driver/cdv-pvr-driver_1.0.2.bb| 143 .../xorg-driver/cdv-pvr-driver_1.0.bb | 99 -- .../recipes-kernel/linux/linux-yocto_3.0.bbappend |2 +- 5 files changed, 145 insertions(+), 138 deletions(-) delete mode 100644 meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver.inc create mode 100644 meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.2.bb delete mode 100644 meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.bb -- 1.7.4.1 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/2] meta-cedartrail: Update SRCREV for the linux-yocto kernel pvr branch
From: Rahul Saxena Update SRCREV to point to yocto/pvr kernel branch with v1.0.2 pvr driver support. Signed-off-by: Rahul Saxena --- .../recipes-kernel/linux/linux-yocto_3.0.bbappend |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend b/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend index 35c4755..4f1c800 100644 --- a/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend +++ b/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend @@ -17,7 +17,7 @@ KERNEL_FEATURES_append_cedartrail-nopvr += " cfg/smp.scc" SRCREV_machine_pn-linux-yocto_cedartrail ?= "1e79e03d115ed177882ab53909a4f3555e434833" SRCREV_meta_pn-linux-yocto_cedartrail ?= "46e8fc2bbbe73514e8d99101adaaa373f760ffa7" -SRCREV_pvr_pn-linux-yocto_cedartrail ?= "997f5644664b31ebefd6e16c451c4a3729eb378a" +SRCREV_pvr_pn-linux-yocto_cedartrail ?= "7828ab82533828b924dbfad5158e274a8bb04df3" SRCREV_machine_pn-linux-yocto_cedartrail-nopvr ?= "1e79e03d115ed177882ab53909a4f3555e434833" SRCREV_meta_pn-linux-yocto_cedartrail-nopvr ?= "a4ac64fe873f08ef718e2849b88914725dc99c1c" -- 1.7.4.1 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 2/2] meta-cedartrail: Update PVR graphics driver to version 1.0.2
From: Rahul Saxena
This update of the driver enables support for B3 stepping of
Cedarview processor and also support for DP/eDP ports.
Signed-off-by: Rahul Saxena
---
meta-cedartrail/README |2 +-
.../xorg-driver/cdv-pvr-driver.inc | 37 -
.../xorg-driver/cdv-pvr-driver_1.0.2.bb| 143
.../xorg-driver/cdv-pvr-driver_1.0.bb | 99 --
4 files changed, 144 insertions(+), 137 deletions(-)
delete mode 100644
meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver.inc
create mode 100644
meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.2.bb
delete mode 100644
meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.bb
diff --git a/meta-cedartrail/README b/meta-cedartrail/README
index 493e831..715cad9 100755
--- a/meta-cedartrail/README
+++ b/meta-cedartrail/README
@@ -61,7 +61,7 @@ Power VR Graphics user-space driver binaries are covered by a
"Intel Free Distribution Binary License". The build of this driver
can be enabled by adding the following line to the local.conf file:
-LICENSE_FLAGS_WHITELIST += "license_cdv-pvr-driver_1.0"
+LICENSE_FLAGS_WHITELIST += "license_cdv-pvr-driver_1.0.2"
To enable the layer that does not support Power VR graphics
add the following to the local.conf file:
diff --git a/meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver.inc
b/meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver.inc
deleted file mode 100644
index 787c1fb..000
--- a/meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver.inc
+++ /dev/null
@@ -1,37 +0,0 @@
-SUMMARY = "Cedartrail PowerVR Graphics Driver version [Gold] 1.0 binaries"
-DESCRIPTION = "2D, 3D and Media user space driver for Cedartrail platform \
-The binaries are covered by the Intel Free Distribution Binary License. \
-The user must make himself/herself aware of the Licensing terms \
-before enabling build of the Cedartrail PowerVR Graphics Driver via \
-this recipe. Please see the README in meta-cedartrail for instructions \
-for enabling the build of the driver "
-
-LICENSE_FLAGS = "license_${PN}_${PV}"
-LICENSE = "Intel Free Distribution Binary License"
-
-LIC_FILES_CHKSUM = " \
-
file://${S}/usr/share/doc/psb-video-cdv-0.16/license.txt;md5=b14d99f8d4ed664e9ce95057f0bb5b65
\
-
file://${S}/usr/share/doc/pvr-bin-cdv-1.7.788837_10/license.txt;md5=b14d99f8d4ed664e9ce95057f0bb5b65"
-
-INC_PR = "r1"
-
-DEPENDS = "rpm-native"
-
-FILES_${PN} += "${libdir}/dri ${libdir}/pvr/cdv/dri ${libdir}/pvr/cdv
${libdir}/xorg/modules/drivers"
-FILES_${PN}-dev += "${libdir}/dri ${libdir}/pvr/cdv/dri
${libdir}/xorg/modules/drivers"
-FILES_${PN}-dbg += "${libdir}/xorg/modules/drivers/.debug ${libdir}/dri/.debug
${libdir}/pvr/cdv/dri/.debug"
-
-FILES_${PN} += "${base_libdir}/firmware"
-FILES_${PN} += "${sysconfdir}/X11/xorg.conf.d"
-
-FILES_${PN} += "${libdir}/lib*.so"
-FILES_${PN}-dev += "${libdir}/lib*.so"
-FILES_${PN}-dbg += "${libdir}/.debug"
-
-FILES_${PN} += "${libdir}/pvr/cdv/xorg/modules/drivers"
-
-FILES_${PN} += "${datadir}/doc/psb-video-cdv-0.16/license.txt"
-FILES_${PN} += "${datadir}/doc/pvr-bin-cdv-1.7.788837_10/license.txt"
-
-
-
diff --git
a/meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.2.bb
b/meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.2.bb
new file mode 100644
index 000..d62c1d2
--- /dev/null
+++ b/meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.2.bb
@@ -0,0 +1,143 @@
+SUMMARY = "Cedartrail PowerVR Graphics Driver version 1.0.2 binaries"
+DESCRIPTION = "2D, 3D and Media user space driver for Cedartrail platform \
+The binaries are covered by the Intel Free Distribution Binary License. \
+The user must make himself/herself aware of the Licensing terms \
+before enabling build of the Cedartrail PowerVR Graphics Driver via \
+this recipe. Please see the README in meta-cedartrail for instructions \
+for enabling the build of the driver "
+
+LICENSE_FLAGS = "license_${PN}_${PV}"
+LICENSE = "Intel Free Distribution Binary License"
+LIC_FILES_CHKSUM = " \
+
file://${S}/usr/share/doc/psb-video-cdv-${PSB-VIDEO-REV}/license.txt;md5=b14d99f8d4ed664e9ce95057f0bb5b65
\
+
file://${S}/usr/share/doc/pvr-bin-cdv-${PVR-BIN-REV_N}/license.txt;md5=b14d99f8d4ed664e9ce95057f0bb5b65"
+
+DEPENDS = "rpm-native libva"
+
+PR = "r1"
+
+PSB-VIDEO = "psb-video-cdv-0.17-2.1.i586.rpm"
+PSB-VIDEO-REV = "0.17"
+
+PVR-BIN = "pvr-bin-cdv-1.7.862890_05-1.1.i586.rpm"
+PVR-BIN-REV = "1.7.862890"
+PVR-BIN-REV_N = "1.7.862890_05"
+
+LIBWSBM = "libwsbm-cdv-1.1.0-3.1.i586.rpm"
+
+
+NON-OSS-PATH =
"http://repo.meego.com/MeeGo/builds/1.2.0/1.2.0.10.1.20120723.1/repos/non-oss/ia32/packages/";
+OSS-PATH =
"http://repo.meego.com/MeeGo/updates/1.2.0/repos/oss/ia32/packages/";
+
+
+SRC_URI = "${NON-OSS-PATH}${PSB-VIDEO};name=psbrpm \
+ ${NON-OSS-PATH}${PVR-BIN};name=pvrrpm \
+ ${OSS-PATH}${LIBW
[yocto] [PATCH 0/4] remove ia32-base.inc and fix crownbay branch
From: Tom Zanussi This removes ia32-base to meta/conf/machine/include and separates out the remaining meta-intel-specific variables into a meta-intel.inc. Merging this depends on the move to oe-core being accepted. For details see: https://bugzilla.yoctoproject.org/show_bug.cgi?id=2996 Also fixes a problem with the crownbay branch that appeared while test building following the latest yocto-kernel class changes. The following changes since commit c9e0d1edb1c7e1d2fa328fb1fb820b627ba02119: ia32-base.inc: Drop glibc --with-tls option, its now the only option for glibc (2012-08-22 14:16:59 +0100) are available in the git repository at: git://git.yoctoproject.org/meta-intel.git tzanussi/ia32-base-rm.v1 http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/log/?h=tzanussi/ia32-base-rm.v1 Tom Zanussi (4): meta-intel.inc: new file ia32-base.inc: remove meta-intel.inc: have appropriate BSPs use it crownbay: fix KBRANCH conf/machine/include/ia32-base.inc | 65 -- conf/machine/include/meta-intel.inc| 16 ++ meta-crownbay/conf/machine/crownbay.conf | 1 + .../recipes-kernel/linux/linux-yocto_3.4.bbappend | 2 +- meta-fri2/conf/machine/fri2.conf | 1 + meta-romley/conf/machine/romley.conf | 1 + meta-sys940x/conf/machine/sys940x.conf | 1 + 7 files changed, 21 insertions(+), 66 deletions(-) delete mode 100644 conf/machine/include/ia32-base.inc create mode 100644 conf/machine/include/meta-intel.inc -- 1.7.11.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/4] meta-intel.inc: new file
From: Tom Zanussi Move a couple intel-specific variables into a new meta-intel.inc include file. meta-intel.inc is meant to contain variables and definitions that only make sense and are only available if the meta-intel layer is included in bblayers.conf. This is in preparation for moving the rest into oe-core. Signed-off-by: Tom Zanussi --- conf/machine/include/ia32-base.inc | 7 --- conf/machine/include/meta-intel.inc | 16 2 files changed, 16 insertions(+), 7 deletions(-) create mode 100644 conf/machine/include/meta-intel.inc diff --git a/conf/machine/include/ia32-base.inc b/conf/machine/include/ia32-base.inc index f8b7b94..af583ae 100644 --- a/conf/machine/include/ia32-base.inc +++ b/conf/machine/include/ia32-base.inc @@ -55,11 +55,4 @@ XSERVER_IA32_I965 = "xf86-video-intel \ mesa-dri-driver-i965 \ " -XSERVER_IA32_EMGD = "emgd-driver-bin \ - " - XSERVER_IA32_VESA = "xf86-video-vesa" - -XSERVER_IA32_MATROX_MGA = "xserver-xorg-module-xaa \ - xf86-video-mga \ - " diff --git a/conf/machine/include/meta-intel.inc b/conf/machine/include/meta-intel.inc new file mode 100644 index 000..f0e538d --- /dev/null +++ b/conf/machine/include/meta-intel.inc @@ -0,0 +1,16 @@ +# +# BSP variables and settings specific to the meta-intel layer. +# You must include the meta-intel layer in your bblayers.conf +# to use them. +# + +# +# XSERVER subcomponents, used to build the XSERVER variable +# +XSERVER_IA32_EMGD = "emgd-driver-bin \ + " + +XSERVER_IA32_MATROX_MGA = "xserver-xorg-module-xaa \ + xf86-video-mga \ + " + -- 1.7.11.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 3/4] meta-intel.inc: have appropriate BSPs use it
From: Tom Zanussi
ia32-base.inc no longer contains everything these BSPs need - some of
what was in that file is now in meta-intel.inc, so we need to include
that too.
Signed-off-by: Tom Zanussi
---
meta-crownbay/conf/machine/crownbay.conf | 1 +
meta-fri2/conf/machine/fri2.conf | 1 +
meta-romley/conf/machine/romley.conf | 1 +
meta-sys940x/conf/machine/sys940x.conf | 1 +
4 files changed, 4 insertions(+)
diff --git a/meta-crownbay/conf/machine/crownbay.conf
b/meta-crownbay/conf/machine/crownbay.conf
index 7d5e597..dba735a 100644
--- a/meta-crownbay/conf/machine/crownbay.conf
+++ b/meta-crownbay/conf/machine/crownbay.conf
@@ -8,6 +8,7 @@ PREFERRED_VERSION_linux-yocto ?= "3.4%"
require conf/machine/include/tune-atom.inc
require conf/machine/include/ia32-base.inc
+require conf/machine/include/meta-intel.inc
MACHINE_FEATURES += "gst-va-mixvideo"
diff --git a/meta-fri2/conf/machine/fri2.conf b/meta-fri2/conf/machine/fri2.conf
index f90deb3..a928f0f 100644
--- a/meta-fri2/conf/machine/fri2.conf
+++ b/meta-fri2/conf/machine/fri2.conf
@@ -6,6 +6,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"
diff --git a/meta-romley/conf/machine/romley.conf
b/meta-romley/conf/machine/romley.conf
index f7cfa18..ab4d3c0 100644
--- a/meta-romley/conf/machine/romley.conf
+++ b/meta-romley/conf/machine/romley.conf
@@ -9,6 +9,7 @@ PREFERRED_VERSION_linux-yocto ?= "3.2%"
require conf/machine/include/tune-x86_64.inc
require conf/machine/include/ia32-base.inc
+require conf/machine/include/meta-intel.inc
XSERVER ?= "${XSERVER_IA32_BASE} \
${XSERVER_IA32_EXT} \
diff --git a/meta-sys940x/conf/machine/sys940x.conf
b/meta-sys940x/conf/machine/sys940x.conf
index 18f769d..9db2b2a 100644
--- a/meta-sys940x/conf/machine/sys940x.conf
+++ b/meta-sys940x/conf/machine/sys940x.conf
@@ -6,6 +6,7 @@
require conf/machine/include/tune-atom.inc
require conf/machine/include/ia32-base.inc
+require conf/machine/include/meta-intel.inc
# Add "pcbios" if you have a non-efi version of the firmware
MACHINE_FEATURES += "efi pcbios gst-va-mixvideo"
--
1.7.11.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 4/4] crownbay: fix KBRANCH
From: Tom Zanussi
KBRANCH_crownbay is set to standard/default/crownbay, which isn't even
a 3.4 branch.
Set it to standard/crownbay, which is.
Signed-off-by: Tom Zanussi
---
meta-crownbay/recipes-kernel/linux/linux-yocto_3.4.bbappend | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-crownbay/recipes-kernel/linux/linux-yocto_3.4.bbappend
b/meta-crownbay/recipes-kernel/linux/linux-yocto_3.4.bbappend
index 4f9dd70..a384ca0 100644
--- a/meta-crownbay/recipes-kernel/linux/linux-yocto_3.4.bbappend
+++ b/meta-crownbay/recipes-kernel/linux/linux-yocto_3.4.bbappend
@@ -2,7 +2,7 @@ FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
COMPATIBLE_MACHINE_crownbay = "crownbay"
KMACHINE_crownbay = "crownbay"
-KBRANCH_crownbay = "standard/default/crownbay"
+KBRANCH_crownbay = "standard/crownbay"
COMPATIBLE_MACHINE_crownbay-noemgd = "crownbay-noemgd"
KMACHINE_crownbay-noemgd = "crownbay"
--
1.7.11.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 2/4] ia32-base.inc: remove
From: Tom Zanussi This has been moved to oe-core, so remove it. Signed-off-by: Tom Zanussi --- conf/machine/include/ia32-base.inc | 58 -- 1 file changed, 58 deletions(-) delete mode 100644 conf/machine/include/ia32-base.inc diff --git a/conf/machine/include/ia32-base.inc b/conf/machine/include/ia32-base.inc deleted file mode 100644 index af583ae..000 --- a/conf/machine/include/ia32-base.inc +++ /dev/null @@ -1,58 +0,0 @@ -# -# base machine settings for ia32-architecture BSPs -# - -# -# common settings for Intel-based machines -# -MACHINE_FEATURES += "screen keyboard pci usbhost ext2 ext3 x86 \ - acpi serial usbgadget alsa" - -MACHINE_EXTRA_RRECOMMENDS += "kernel-modules eee-acpi-scripts" -MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "grub" - -IMAGE_FSTYPES += "ext3 cpio.gz live" - -KERNEL_IMAGETYPE ?= "bzImage" - -SERIAL_CONSOLE ?= "115200 ttyS0" - -# -# glibc-related variables -# -GLIBC_ADDONS ?= "nptl" - -# -# kernel-related variables -# -PREFERRED_PROVIDER_virtual/kernel ??= "linux-yocto" -PREFERRED_VERSION_linux-yocto ??= "3.0%" - -# -# XSERVER subcomponents, used to build the XSERVER variable -# -XSERVER_IA32_BASE = "xserver-xorg \ - xf86-input-mouse \ - xf86-input-keyboard \ - xf86-input-evdev \ - xf86-input-synaptics \ - mesa-dri \ - " - -XSERVER_IA32_EXT = "xserver-xorg-extension-dri \ - xserver-xorg-extension-dri2 \ - xserver-xorg-extension-glx \ - xserver-xorg-extension-extmod \ - xserver-xorg-extension-dbe \ - xserver-xorg-module-libint10 \ - " - -XSERVER_IA32_I915 = "xf86-video-intel \ - mesa-dri-driver-i915 \ - " - -XSERVER_IA32_I965 = "xf86-video-intel \ - mesa-dri-driver-i965 \ - " - -XSERVER_IA32_VESA = "xf86-video-vesa" -- 1.7.11.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/2][meta-intel] Cover letter to update pvr driver to v1.0.2 in meta-cedartral, denzil branch: Correction master branch
Need to make a correction: This patch series is not for denzil branch, it is for the master branch. Pl pull into master branch. My apologies for any confusion this may have caused. Thanks Rahul -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of rahul.sax...@intel.com Sent: Friday, August 24, 2012 4:11 PM To: yocto@yoctoproject.org; Zanussi, Tom; dvh...@linux.intel.com Subject: [yocto] [PATCH 0/2][meta-intel] Cover letter to update pvr driver to v1.0.2 in meta-cedartral, denzil branch From: Rahul Saxena Cover letter to update pvr driver to v1.0.2 in meta-cedartrail. This update of the driver supports B3 stepping of the Cedarview processor and also supports DP/eDP ports. Please update denzil branch with this patch series. Signed-off-by: Rahul Saxena -- The following changes since commit ff7fdafba88a5b7676f601b3d16a97ce7d48c4a9: crownbay: make v3.4 the default kernel (2012-07-31 23:08:05 -0500) are available in the git repository at: git://git.pokylinux.org/meta-intel-contrib rsaxena_1_3_M3 http://git.pokylinux.org/cgit.cgi/meta-intel-contrib/log/?h=rsaxena_1_3_M3 Rahul Saxena (2): meta-cedartrail: Update SRCREV for the linux-yocto kernel pvr branch meta-cedartrail: Update PVR graphics driver to version 1.0.2 meta-cedartrail/README |2 +- .../xorg-driver/cdv-pvr-driver.inc | 37 - .../xorg-driver/cdv-pvr-driver_1.0.2.bb| 143 .../xorg-driver/cdv-pvr-driver_1.0.bb | 99 -- .../recipes-kernel/linux/linux-yocto_3.0.bbappend |2 +- 5 files changed, 145 insertions(+), 138 deletions(-) delete mode 100644 meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver.inc create mode 100644 meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.2.bb delete mode 100644 meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.bb -- 1.7.4.1 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
