On 01/16/2014 11:47 AM, Otavio Salvador wrote:
On Thu, Jan 16, 2014 at 8:46 AM, Koen Kooi koen.k...@linaro.org
mailto:koen.k...@linaro.org wrote:
Op 16 jan. 2014, om 11:38 heeft Otavio Salvador
ota...@ossystems.com.br mailto:ota...@ossystems.com.br het
volgende geschreven:
On
Marks original commit message and variable documentation state that stripping
and splitting are independent of eachother, but package.bbclass ANDs the two
INHIBIT flags to see which files can be stripped and/or split.
Original behaviour:
INHIBIT_PACKAGE_STRIP: no strip, no debug split
Fix the build error of autogen-native which depends on guile-native:
ysroots/x86_64-linux/usr/include/guile/2.0/libguile/error.h:40:24: error:
expected ')' before '__attribute__'
sysroots/x86_64-linux/usr/include/guile/2.0/libguile/error.h:40:24: error:
expected ',' or ';' before ')' token
The following changes since commit eb0dc3fca77d82c21ad05330b006258ef363dba2:
e2fsprogs/populate-extfs.sh: fix a problem on dash (2014-01-20 17:25:58 +0800)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib rbt/ag
Hi Mark,
I've tested the archiver.bbclass with rm_work.bbclasss again, it works for me,
it seems that you only downloaded the archiver.bbclass was not enough, would
you please try this PULL? It is really on oe-core-contrib now:-) And if the
error occurs, would you please show the configuration
Hi Martin,
I've tested the archiver.bbclass with rm_work.bbclasss again, it works for me,
it seems that you only downloaded the archiver.bbclass was not enough, would
you please try this PULL? It is based on oe-core and on oe-core-contrib now:-)
And if the error occurs, would you please show
On Mon, 2014-01-20 at 13:40 +0200, Fathi Boudra wrote:
Signed-off-by: Fathi Boudra fathi.bou...@linaro.org
---
meta/recipes-extended/ltp/ltp_20130904.bb | 78
---
meta/recipes-extended/ltp/ltp_20140115.bb | 78
+++
2 files changed,
From: Koen Kooi k...@dominion.thruhere.net
Apps testing for systemd config get confused when both /usr/lib/systemd and
/lib/systemd exist. This fixes (among other things) dracut systemd detections.
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
meta/recipes-core/systemd/systemd_208.bb
The note issues when OECMAKE_BUILDPATH and OECMAKE_SOURCEPATH were being used
stated that an in-tree build would be done, but the default is in fact an
out-of-tree build.
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/classes/cmake.bbclass |2 +-
1 file changed, 1 insertion(+), 1
Good point, thanks. Patch sent.
Ross
On 16 January 2014 10:26, Stefan Herbrechtsmeier
ste...@herbrechtsmeier.net wrote:
Am 10.01.2014 18:54, schrieb Ross Burton:
Set B=${WORKDIR}/build in cmake.bbclass so that recipes using
cmake.bbclass do
out-of-tree builds by default.
You should
On 21 January 2014 12:41, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Mon, 2014-01-20 at 13:40 +0200, Fathi Boudra wrote:
Signed-off-by: Fathi Boudra fathi.bou...@linaro.org
---
meta/recipes-extended/ltp/ltp_20130904.bb | 78
---
The default value for HOMEPAGE of unknown has been in place since the
early OE-Classic days, but it doesn't really make sense - unknown is
not a valid URL and it just means we have to explicitly check for this
hardcoded string if we're displaying the value in some form of UI, such
as Toaster.
On Tue, Jan 21, 2014 at 06:41:04PM +0800, Robert Yang wrote:
Hi Martin,
I've tested the archiver.bbclass with rm_work.bbclasss again, it works for me,
it seems that you only downloaded the archiver.bbclass was not enough, would
you please try this PULL? It is based on oe-core and on
On Tue, Jan 21, 2014 at 12:01:21PM +0100, Koen Kooi wrote:
From: Koen Kooi k...@dominion.thruhere.net
Apps testing for systemd config get confused when both /usr/lib/systemd and
/lib/systemd exist. This fixes (among other things) dracut systemd detections.
Signed-off-by: Koen Kooi
On 01/21/2014 02:01 PM, Martin Jansa wrote:
On Tue, Jan 21, 2014 at 12:01:21PM +0100, Koen Kooi wrote:
From: Koen Kooi k...@dominion.thruhere.net
Apps testing for systemd config get confused when both /usr/lib/systemd and
/lib/systemd exist. This fixes (among other things) dracut systemd
On Sun, Jan 12, 2014 at 06:33:11PM +0100, Martin Jansa wrote:
* since last freetype upgrade cmake cannot detect it
* e.g. webkit-efl requires freetype and is failing because of this
ping
+ Ross as he is working on cmake as well as freetype
Signed-off-by: Martin Jansa martin.ja...@gmail.com
On Tue, 2014-01-21 at 10:47 +0100, Koen Kooi wrote:
Marks original commit message and variable documentation state that stripping
and splitting are independent of eachother, but package.bbclass ANDs the two
INHIBIT flags to see which files can be stripped and/or split.
Original behaviour:
On 01/21/2014 02:57 PM, Richard Purdie wrote:
On Tue, 2014-01-21 at 10:47 +0100, Koen Kooi wrote:
Marks original commit message and variable documentation state that stripping
and splitting are independent of eachother, but package.bbclass ANDs the two
INHIBIT flags to see which files can be
On 1/21/14, 8:03 AM, Koen Kooi wrote:
On 01/21/2014 02:57 PM, Richard Purdie wrote:
On Tue, 2014-01-21 at 10:47 +0100, Koen Kooi wrote:
Marks original commit message and variable documentation state that stripping
and splitting are independent of eachother, but package.bbclass ANDs the two
This corrects and improves pybootchartgui. It starts by correcting two
flaws introduced in my last update of pybootchartgui. It then makes a
little simplification, followed up by improving the naming of split
output files. Finally it introduces a new option (--full-time or -T)
which makes sure the
When --full-time (or -T) is used, the graph allways shows the full
time regardless of which processes are currently shown. This is
especially useful in combinationm with the -s flag when outputting to
multiple files.
Signed-off-by: Peter Kjellerstedt peter.kjellerst...@axis.com
---
Add minimum width zero-padding to the index used in split output files
with -s and -o. I.e., if -s 200 is used, then the index will be
zero-padded to three digits width.
Signed-off-by: Peter Kjellerstedt peter.kjellerst...@axis.com
---
scripts/pybootchartgui/pybootchartgui/main.py.in | 4 +++-
1
Signed-off-by: Peter Kjellerstedt peter.kjellerst...@axis.com
---
scripts/pybootchartgui/pybootchartgui/parsing.py | 39 +---
1 file changed, 14 insertions(+), 25 deletions(-)
diff --git a/scripts/pybootchartgui/pybootchartgui/parsing.py
[YOCTO #5588]
Signed-off-by: Peter Kjellerstedt peter.kjellerst...@axis.com
---
scripts/pybootchartgui/pybootchartgui/parsing.py | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/scripts/pybootchartgui/pybootchartgui/parsing.py
On Tue, 2014-01-21 at 15:03 +0100, Koen Kooi wrote:
On 01/21/2014 02:57 PM, Richard Purdie wrote:
On Tue, 2014-01-21 at 10:47 +0100, Koen Kooi wrote:
Marks original commit message and variable documentation state that
stripping and splitting are independent of eachother, but
Hi,
I build a sdk with latest stable dora and in includes some x86 directories in
the arm sysroot:
pwd
/opt/poky/1.5.1/sysroots/armv5te-poky-linux-gnueabi
find | grep /opt
./opt
./opt/poky
./opt/poky/1.5.1
./opt/poky/1.5.1/sysroots
./opt/poky/1.5.1/sysroots/x86_64-pokysdk-linux
On 21 January 2014 13:02, Martin Jansa martin.ja...@gmail.com wrote:
+ Ross as he is working on cmake as well as freetype
I think I need to state for the record that I only fixed up cmake's
S/B stuff because it was driving me insane, and hate cmake. :)
Ross
The OpenEmbedded eV is the organizational structure of the OpenEmbedded
project. See:
http://www.openembedded.org/wiki/Organization
The Organization itself doesn't have much to do with the day to day work
of the project, but does provide contact points for outside entities and
the membership
Backport a patch from upstream which fixes failures building
guile-native on newer distros such as Ubuntu 13.10. (This does not
affect dora or master because we are using Guile 2.0.9 there, which
already contains this patch.)
Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com
---
From: Saul Wold s...@linux.intel.com
(From OE-Core master rev: bc6258f88705b0e7989089a8666ac5e5d2355823)
Signed-off-by: Saul Wold s...@linux.intel.com
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
.../grep/grep-2.5.1a/fix-for-texinfo-5.1.patch | 13
One backport from master (already in dora) and one dylan-specific patch
to fix failures building dylan on newer distributions such as Ubuntu 13.10.
The following changes since commit bca606597de6c5c2de98ae1949857e4481623939:
build-appliance-image: Update to dylan head revision (2014-01-15
Hi,
Yes, the gcc configured for SPE (--target=powerpc-fsl_networking-linux-gnuspe)
can generate both SPE and non-SPE code provided that software
floating point is used.
There are a couple of parameters (-mabi=no-spe -mno-spe) that will turn
off SPE vector instructions generation. If the code
On Tue, 2014-01-21 at 17:39 +, alexandru.sar...@freescale.com wrote:
Yes, the gcc configured for SPE (--target=powerpc-fsl_networking-linux-gnuspe)
can generate both SPE and non-SPE code provided that software
floating point is used.
There are a couple of parameters (-mabi=no-spe
Signed-off-by: Saul Wold s...@linux.intel.com
---
.../lsb/{lsbinitscripts_9.50.bb = lsbinitscripts_9.52.bb} | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
rename meta/recipes-extended/lsb/{lsbinitscripts_9.50.bb =
lsbinitscripts_9.52.bb} (78%)
diff --git
Signed-off-by: Saul Wold s...@linux.intel.com
---
.../libcgroup/{libcgroup_0.38.bb = libcgroup_0.41.bb}| 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
rename meta/recipes-core/libcgroup/{libcgroup_0.38.bb = libcgroup_0.41.bb}
(88%)
diff --git
On 01/21/2014 04:17 AM, Paul Eggleton wrote:
The default value for HOMEPAGE of unknown has been in place since the
early OE-Classic days, but it doesn't really make sense - unknown is
not a valid URL and it just means we have to explicitly check for this
hardcoded string if we're displaying the
Hi Saul,
On Tuesday 21 January 2014 14:09:16 Saul Wold wrote:
On 01/21/2014 04:17 AM, Paul Eggleton wrote:
The default value for HOMEPAGE of unknown has been in place since the
early OE-Classic days, but it doesn't really make sense - unknown is
not a valid URL and it just means we have to
On Tue, 2014-01-21 at 12:17 +, Paul Eggleton wrote:
The default value for HOMEPAGE of unknown has been in place since the
early OE-Classic days, but it doesn't really make sense - unknown is
not a valid URL and it just means we have to explicitly check for this
hardcoded string if we're
On 01/21/2014 02:12 PM, Paul Eggleton wrote:
Hi Saul,
On Tuesday 21 January 2014 14:09:16 Saul Wold wrote:
On 01/21/2014 04:17 AM, Paul Eggleton wrote:
The default value for HOMEPAGE of unknown has been in place since the
early OE-Classic days, but it doesn't really make sense - unknown is
corei7 offers a significant advancement since the previous core2
cpu-type described in the tune-core2 file.
From the GCC(1):
Intel Core i7 CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3,
SSSE3, SSE4.1 and SSE4.2 instruction set support.
This offers optimizations for Nehalem and
ia32 implies 32bit, while these files provide descriptions for IA32,
X86_64, and X32 architectures. The term x86 fits this used better
without resorting to using the term Intel which isn't quite right as
it excludes things like the tune-c3 file describing a Via CPU.
Signed-off-by: Darren Hart
As x86_64 has been demoted to an ABI definition rather than a concrete
tune file, replace it with core2-64 for the qemux86-64 machine.
Signed-off-by: Darren Hart dvh...@linux.intel.com
---
meta/conf/machine/qemux86-64.conf |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
All,
The following lays the groundwork for some rethinking of support for x86
platforms. In particular, the meta-intel layer will undergo some major
refactoring once this is merged. We believe it is of value to keep as much
of the tune files available in oe-core as possible, rather than isolating
Describe the expected usage of base architecture tune files and
arch-specific files, specifically the stacking of generations.
Signed-off-by: Darren Hart dvh...@linux.intel.com
Cc: Richard Purdie richard.pur...@intel.com
Cc: Paul Eggleton paul.eggle...@intel.com
Cc: Tom Zanussi
No new content, just correcting a few typographical errors.
Signed-off-by: Darren Hart dvh...@linux.intel.com
Cc: Richard Purdie richard.pur...@intel.com
Cc: Paul Eggleton paul.eggle...@intel.com
Cc: Tom Zanussi tom.zanu...@intel.com
Cc: Nitin Kamble nitin.a.kam...@intel.com
Cc: Mark Hatle
The generic x86 build supports i586 by default, so this specific tune
file technically doesn't add any specific ARCHes to PACKAGE_EXTRA_ARCHS.
For consistency, append the current tune to PACKAGE_EXTRA_ARCHS.
Since we do not have specific tune files for i386 and i486, just drop
them.
These could
Use the new names for the x86 tunes files (x86 instead of ia32).
Signed-off-by: Darren Hart dvh...@linux.intel.com
---
.../conf/machine/include/genericx86-common.inc |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
-march specifies which ISA to use. -mtune specifies which cpu-type to
optimize instruction ordering for, but not which ISA to use. There are
times when it may make sense to specify mtune=generic and use a more
specific march, such as core2, but the opposite makes little sense at
all: use cpu-type
Use require instead of include to avoid silent errors when the required
tune files change name or are moved. It's going to fail anyway, it might
as well fail with an error message that is immediately helpful.
Signed-off-by: Darren Hart dvh...@linux.intel.com
---
Before making content changes, cleanup the various whitespace errors in
this file. Mostly end-of-line whitepsace.
Signed-off-by: Darren Hart dvh...@linux.intel.com
Cc: Richard Purdie richard.pur...@intel.com
Cc: Paul Eggleton paul.eggle...@intel.com
Cc: Tom Zanussi tom.zanu...@intel.com
Cc: Nitin
As x86_64 has been demoted to an ABI definition rather than a concrete
tune file, replace it with core2-64 for the genericx86-64 machine.
Signed-off-by: Darren Hart dvh...@linux.intel.com
---
meta-yocto-bsp/conf/machine/genericx86-64.conf |3 ++-
1 file changed, 2 insertions(+), 1
On Tuesday 21 January 2014 22:12:13 Paul Eggleton wrote:
Hi Saul,
On Tuesday 21 January 2014 14:09:16 Saul Wold wrote:
On 01/21/2014 04:17 AM, Paul Eggleton wrote:
The default value for HOMEPAGE of unknown has been in place since the
early OE-Classic days, but it doesn't really make
Aside from the movbe and specialized instruction scheduling for the lack
of out-of-order scheduling in the older Atom CPUs, the core2 tune covers
these CPUs adequately. Since the current atom tune just uses core2
anyway, go ahead and make this explicit here.
Signed-off-by: Darren Hart
Core2 has both a 32b and a 64b variant. Currently, core2 implies 32b,
while core2_64 is the 64b version. This implicit 32b mode will become
confusing in later architectures, such as corei7, where it would be
natural for people to assume corei7 meant 64 bit.
Rather than carrying forward an
Inherit the PACKAGE_EXTRA_ARCHS from i586 and only explicitly add core2
here.
Signed-off-by: Darren Hart dvh...@linux.intel.com
Cc: Richard Purdie richard.pur...@intel.com
Cc: Paul Eggleton paul.eggle...@intel.com
Cc: Tom Zanussi tom.zanu...@intel.com
Cc: Nitin Kamble nitin.a.kam...@intel.com
Cc:
On Tuesday 21 January 2014 22:23:18 Richard Purdie wrote:
On Tue, 2014-01-21 at 12:17 +, Paul Eggleton wrote:
The default value for HOMEPAGE of unknown has been in place since the
early OE-Classic days, but it doesn't really make sense - unknown is
not a valid URL and it just means we
On Tue, 2014-01-21 at 22:22 +, Paul Eggleton wrote:
On Tuesday 21 January 2014 22:12:13 Paul Eggleton wrote:
Hi Saul,
On Tuesday 21 January 2014 14:09:16 Saul Wold wrote:
On 01/21/2014 04:17 AM, Paul Eggleton wrote:
The default value for HOMEPAGE of unknown has been in place
On Tue, 2014-01-21 at 22:39 +, Paul Eggleton wrote:
On Tuesday 21 January 2014 22:23:18 Richard Purdie wrote:
On Tue, 2014-01-21 at 12:17 +, Paul Eggleton wrote:
The default value for HOMEPAGE of unknown has been in place since the
early OE-Classic days, but it doesn't really make
On Tue, Jan 21, 2014 at 02:39:47PM -0800, Darren Hart wrote:
ia32 implies 32bit, while these files provide descriptions for IA32,
X86_64, and X32 architectures. The term x86 fits this used better
without resorting to using the term Intel which isn't quite right as
it excludes things like the
On Tue, Jan 21, 2014 at 02:39:58PM -0800, Darren Hart wrote:
Aside from the movbe and specialized instruction scheduling for the lack
of out-of-order scheduling in the older Atom CPUs, the core2 tune covers
these CPUs adequately. Since the current atom tune just uses core2
anyway, go ahead and
On Tue, 2014-01-21 at 23:58 +0100, Martin Jansa wrote:
On Tue, Jan 21, 2014 at 02:39:58PM -0800, Darren Hart wrote:
Aside from the movbe and specialized instruction scheduling for the lack
of out-of-order scheduling in the older Atom CPUs, the core2 tune covers
these CPUs adequately. Since
On Tue, 2014-01-21 at 23:55 +0100, Martin Jansa wrote:
On Tue, Jan 21, 2014 at 02:39:47PM -0800, Darren Hart wrote:
ia32 implies 32bit, while these files provide descriptions for IA32,
X86_64, and X32 architectures. The term x86 fits this used better
without resorting to using the term
On Tue, Jan 21, 2014 at 03:12:15PM -0800, Darren Hart wrote:
On Tue, 2014-01-21 at 23:58 +0100, Martin Jansa wrote:
On Tue, Jan 21, 2014 at 02:39:58PM -0800, Darren Hart wrote:
Aside from the movbe and specialized instruction scheduling for the lack
of out-of-order scheduling in the older
* now with update-alternatives-cworth completely gone should correctly
replace it on target as well
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
meta/recipes-devtools/opkg-utils/opkg-utils_git.bb | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
* unfortunatelly that note about armv7 matching also armv7a is no
longer valid since armv7 include in armv7 was replaced with
armv6+neon in this commit:
commit 75b8adbc042e0f65fb1286bc550d02becd3b6aea
Author: Khem Raj raj.k...@gmail.com
Date: Tue Mar 27 18:37:45 2012 -0700
On Tue, 2014-01-21 at 14:40 -0800, Darren Hart wrote:
All,
The following lays the groundwork for some rethinking of support for x86
platforms. In particular, the meta-intel layer will undergo some major
refactoring once this is merged. We believe it is of value to keep as much
of the tune
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
meta/conf/machine/include/tune-cortexr4.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/conf/machine/include/tune-cortexr4.inc
b/meta/conf/machine/include/tune-cortexr4.inc
index 57b6717..bde649f 100644
---
From: Andrei Gherzan and...@gherzan.ro
Use thumb instructions for Cortex-M3 to avoid this gcc error:
'error: target CPU does not support ARM mode'.
Extracted from Cortex-M3 Technical Reference Manual:
The processor implements the ARM v7-M architecture. This includes the entire
16-bit Thumb
* this means that recipes with ARM_INSTRUCTION_SET explicitly changed
to arm will be built in feed without thumb suffix
* I'm not sure if the rest of system correctly supports different
TUNE_PKGARCHs for different recipes, this is one of the reasons why
this is WIP/RFC
Signed-off-by: Martin
Only first patch was properly tested, the rest is just something I've
noticed when looking at feature-arm-thumb.inc and there was similar
request from Andrei last week
http://lists.openembedded.org/pipermail/openembedded-core/2014-January/088207.html
The following changes since commit
* unfortunatelly that note about armv7 matching also armv7a is no
longer valid since armv7 include in armv7a was replaced with
armv6+neon in this commit:
commit 75b8adbc042e0f65fb1286bc550d02becd3b6aea
Author: Khem Raj raj.k...@gmail.com
Date: Tue Mar 27 18:37:45 2012 -0700
* so that it's highlighted correctly
---
meta/conf/machine/include/arm/feature-arm-thumb.inc | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/meta/conf/machine/include/arm/feature-arm-thumb.inc
b/meta/conf/machine/include/arm/feature-arm-thumb.inc
index
* it will be inherited by all higher architectures, except few exceptions which
support only thumb and not arm
* respect missing arm in TUNE_FEATURES in feature-arm-thumb.inc
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
meta/conf/machine/include/arm/arch-armv4.inc| 2 +-
On Wed, Jan 22, 2014 at 12:43:12AM +0100, Martin Jansa wrote:
* unfortunatelly that note about armv7 matching also armv7a is no
longer valid since armv7 include in armv7 was replaced with
armv6+neon in this commit:
commit 75b8adbc042e0f65fb1286bc550d02becd3b6aea
Author: Khem Raj
ia32 implies 32bit, while these files provide descriptions for IA32,
X86_64, and X32 architectures. The term x86 fits this used better
without resorting to using the term Intel which isn't quite right as
it excludes things like the tune-c3 file describing a Via CPU.
Signed-off-by: Darren Hart
Update the substrates to use x86-base instead of ia32-base and core2-64
instead of x86-64. Update the core2 bit to include the DEFAULTTUNE to be
explicit.
Signed-off-by: Darren Hart dvh...@linux.intel.com
Cc: Richard Purdie richard.pur...@linuxfoundation.org
Cc: Paul Eggleton
The generic x86 build supports i586 by default, so this specific tune
file technically doesn't add any specific ARCHes to PACKAGE_EXTRA_ARCHS.
For consistency, append the current tune to PACKAGE_EXTRA_ARCHS.
Since we do not have specific tune files for i386 and i486, just drop
them.
These could
All,
The following lays the groundwork for some rethinking of support for x86
platforms. In particular, the meta-intel layer will undergo some major
refactoring once this is merged. We believe it is of value to keep as much
of the tune files available in oe-core as possible, rather than isolating
As x86_64 has been demoted to an ABI definition rather than a concrete
tune file, replace it with core2-64 for the genericx86-64 machine.
Signed-off-by: Darren Hart dvh...@linux.intel.com
Cc: Richard Purdie richard.pur...@linuxfoundation.org
Cc: Paul Eggleton paul.eggle...@intel.com
Cc: Tom
Aside from the movbe and specialized instruction scheduling for the lack
of out-of-order scheduling in the older Atom CPUs, the core2 tune covers
these CPUs adequately. Since the current atom tune just uses core2
anyway, go ahead and make this explicit here.
Signed-off-by: Darren Hart
No new content, just correcting a few typographical errors.
Signed-off-by: Darren Hart dvh...@linux.intel.com
Cc: Richard Purdie richard.pur...@linuxfoundation.org
Cc: Paul Eggleton paul.eggle...@intel.com
Cc: Tom Zanussi tom.zanu...@intel.com
Cc: Nitin Kamble nitin.a.kam...@intel.com
Cc: Mark
Describe the expected usage of base architecture tune files and
arch-specific files, specifically the stacking of generations.
Signed-off-by: Darren Hart dvh...@linux.intel.com
Cc: Richard Purdie richard.pur...@linuxfoundation.org
Cc: Paul Eggleton paul.eggle...@intel.com
Cc: Tom Zanussi
-march specifies which ISA to use. -mtune specifies which cpu-type to
optimize instruction ordering for, but not which ISA to use. There are
times when it may make sense to specify mtune=generic and use a more
specific march, such as core2, but the opposite makes little sense at
all: use cpu-type
The tune-x86_64.inc file is conceptually flawed. x86_64 is more akin to
the x86 and x86-32 ABIs defined in arch-x86.inc than it is a concrete
tune file, such as i586 or core2 - to the extent that everything but the
default tune is defined in the arch-x86.inc file. This becomes very
apparant when
Use require instead of include to avoid silent errors when the required
tune files change name or are moved. It's going to fail anyway, it might
as well fail with an error message that is immediately helpful.
Signed-off-by: Darren Hart dvh...@linux.intel.com
Cc: Richard Purdie
As x86_64 has been demoted to an ABI definition rather than a concrete
tune file, replace it with core2-64 for the qemux86-64 machine.
Signed-off-by: Darren Hart dvh...@linux.intel.com
Cc: Richard Purdie richard.pur...@linuxfoundation.org
Cc: Paul Eggleton paul.eggle...@intel.com
Cc: Tom Zanussi
Use the new names for the x86 tunes files (x86 instead of ia32).
Signed-off-by: Darren Hart dvh...@linux.intel.com
Cc: Richard Purdie richard.pur...@linuxfoundation.org
Cc: Paul Eggleton paul.eggle...@intel.com
Cc: Tom Zanussi tom.zanu...@intel.com
Cc: Nitin Kamble nitin.a.kam...@intel.com
Cc:
corei7 offers a significant advancement since the previous core2
cpu-type described in the tune-core2 file.
From the GCC(1):
Intel Core i7 CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3,
SSSE3, SSE4.1 and SSE4.2 instruction set support.
This offers optimizations for Nehalem and
Before making content changes, cleanup the various whitespace errors in
this file. Mostly end-of-line whitepsace.
Signed-off-by: Darren Hart dvh...@linux.intel.com
Cc: Richard Purdie richard.pur...@linuxfoundation.org
Cc: Paul Eggleton paul.eggle...@intel.com
Cc: Tom Zanussi tom.zanu...@intel.com
Update the x86_64 architecture bsp creator to include choices for core2
and corei7 tune files.
Signed-off-by: Darren Hart dvh...@linux.intel.com
Cc: Richard Purdie richard.pur...@linuxfoundation.org
Cc: Paul Eggleton paul.eggle...@intel.com
Cc: Tom Zanussi tom.zanu...@intel.com
Cc: Nitin Kamble
Replace core2 with core2_32 where appropriate for the new
x86 tune naming.
Signed-off-by: Darren Hart dvh...@linux.intel.com
Cc: Scott Rifenbark scott.m.rifenb...@intel.com
Cc: Richard Purdie richard.pur...@linuxfoundation.org
Cc: Paul Eggleton paul.eggle...@intel.com
Cc: Tom Zanussi
Core2 has both a 32b and a 64b variant. Currently, core2 implies 32b,
while core2_64 is the 64b version. This implicit 32b mode will become
confusing in later architectures, such as corei7, where it would be
natural for people to assume corei7 meant 64 bit.
Rather than carrying forward an
Inherit the PACKAGE_EXTRA_ARCHS from i586 and only explicitly add core2
here.
Signed-off-by: Darren Hart dvh...@linux.intel.com
Cc: Richard Purdie richard.pur...@linuxfoundation.org
Cc: Paul Eggleton paul.eggle...@intel.com
Cc: Tom Zanussi tom.zanu...@intel.com
Cc: Nitin Kamble
I created this after a git grep to look for files impacted by the x86
tune changes. I need a careful review here to determine if this is in
fact the right thing to do.
Signed-off-by: Darren Hart dvh...@linux.intel.com
Cc: Richard Purdie richard.pur...@linuxfoundation.org
Cc: Paul Eggleton
On Tue, Jan 21, 2014 at 04:58:46PM -0800, Darren Hart wrote:
ia32 implies 32bit, while these files provide descriptions for IA32,
X86_64, and X32 architectures. The term x86 fits this used better
without resorting to using the term Intel which isn't quite right as
it excludes things like the
The following changes since commit 4659d29b1040349116549644e45035a5b37d9311:
sstate.bbclass: remove previous version's stamp (2014-01-21 10:36:23 +)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib ChenQi/busybox-1.22.1
To correctly integrate with busybox in our system, we should add
'stat' to base_bindir_progs so that the 'stat' commands from busybox
and coreutils both register to /bin/stat.
Previously there was a patch in busybox to move 'stat' to /usr/bin.
But as we can easily solve this integration problem
This solves the integration problem with busybox.
Previously, there was a patch in busybox to move 'watch' to /usr/bin.
Such patch is not accepted by upsteam and really not necessary as
our ALTERNATIVE system can easily solve such intergration problem.
Signed-off-by: Chen Qi
As busybox has been upgraded, rename this bbappend file to make it
match the current version of busybox.
Signed-off-by: Chen Qi qi.c...@windriver.com
---
...{busybox_1.21.1.bbappend = busybox_%.bbappend} |0
1 file changed, 0 insertions(+), 0 deletions(-)
rename
Upgrade busybox to the stable release 1.22.1.
During this upgrade, 9 patches are removed. Reasons are detailed below.
The following 6 patches are removed as they have been merged.
meta/recipes-core/busybox/busybox/busybox-lineedit-initialize-delptr.patch
1 - 100 of 106 matches
Mail list logo
