[oe] [RFC][PATCH] distro: Move thumb into distro features
* Currenlty we define the thumb specific overrides in machine tune files
and as machine conf files are included before the distro conf files
the overrides dont get right values and set incorrectly.
* This patch moves the tune-thumb.inc from machine/include into
distro/include and lets distro decide on thumb and thumb-interworking
features based on the machine selected. If a machine which does not
support thumb like all armv4 based machines is selected then distro
makes correct decision now to disable thumb and thumb-interworking
based upon the machine seletected.
Signed-off-by: Khem Raj raj.k...@gmail.com
---
conf/distro/angstrom-2008.1.conf|1 +
conf/distro/gmustix.conf|2 +
conf/distro/include/arm-thumb.inc | 32 +++
conf/distro/kaeilos-2010.conf |1 +
conf/distro/kaeilos.conf|1 +
conf/distro/micro.conf |1 +
conf/distro/minimal.conf|3 +-
conf/distro/shr.conf|1 +
conf/distro/slugos.conf |2 +
conf/machine/include/ixp4xx.inc |1 -
conf/machine/include/tune-arm1136-novfp.inc |3 --
conf/machine/include/tune-arm1136jf-s.inc |3 --
conf/machine/include/tune-arm1176jzf-s.inc |3 --
conf/machine/include/tune-arm920t.inc |4 ---
conf/machine/include/tune-arm926ejs.inc |3 --
conf/machine/include/tune-arm9tdmi.inc |4 ---
conf/machine/include/tune-armv7.inc |4 ---
conf/machine/include/tune-ep9312.inc|3 --
conf/machine/include/tune-thumb.inc | 32 ---
conf/machine/include/tune-xscale.inc|4 ---
conf/machine/palmz31.conf |3 --
conf/machine/palmz72.conf |3 --
22 files changed, 43 insertions(+), 71 deletions(-)
create mode 100644 conf/distro/include/arm-thumb.inc
delete mode 100644 conf/machine/include/tune-thumb.inc
diff --git a/conf/distro/angstrom-2008.1.conf b/conf/distro/angstrom-2008.1.conf
index 7c70c84..84e8096 100644
--- a/conf/distro/angstrom-2008.1.conf
+++ b/conf/distro/angstrom-2008.1.conf
@@ -136,6 +136,7 @@ PREFERRED_VERSION_binutils-cross-sdk_avr32 = 2.17
# Toolchain virtuals:
require conf/distro/include/toolchain-${TOOLCHAIN_TYPE}.inc
+require conf/distro/include/arm-thumb.inc
PREFERRED_PROVIDER_dbus-glib = dbus-glib
PREFERRED_PROVIDER_hotplug = udev
diff --git a/conf/distro/gmustix.conf b/conf/distro/gmustix.conf
index 17f8056..5dd519d 100644
--- a/conf/distro/gmustix.conf
+++ b/conf/distro/gmustix.conf
@@ -5,6 +5,8 @@
INHERIT += package_tar package_ipk
LIBC = uclibc
require conf/distro/include/${LIBC}.inc
+require conf/distro/include/arm-thumb.inc
+
TARGET_OS = linux-uclibc
TARGET_FPU = soft
IMAGE_FSTYPES = jffs2
diff --git a/conf/distro/include/arm-thumb.inc
b/conf/distro/include/arm-thumb.inc
new file mode 100644
index 000..cd88bb4
--- /dev/null
+++ b/conf/distro/include/arm-thumb.inc
@@ -0,0 +1,32 @@
+#tune file for thumb instructions
+
+ARM_INSTRUCTION_SET ?= arm
+# arm thumb
+#The instruction set the compiler should use when generating application
+#code. The kernel is always compiled with arm code at present. arm code
+#is the original 32 bit ARM instruction set, thumb code is the 16 bit
+#encoded RISC sub-set. Thumb code is smaller (maybe 70% of the ARM size)
+#but requires more instructions (140% for 70% smaller code) so may be
+#slower.
+
+THUMB_INTERWORK ?= no
+# yes no
+#Whether to compile with code to allow interworking between the two
+#instruction sets. This allows thumb code to be executed on a primarily
+#arm system and vice versa. It is strongly recommended that DISTROs not
+#turn this off - the actual cost is very small.
+
+OVERRIDE_THUMB = $...@['', ':thumb'][bb.data.getVar('ARM_INSTRUCTION_SET', d,
1) == 'thumb']}
+OVERRIDE_INTERWORK = $...@['',
':thumb-interwork'][bb.data.getVar('THUMB_INTERWORK', d, 1) == 'yes']}
+OVERRIDES .= ${OVERRIDE_THUMB}${OVERRIDE_INTERWORK}
+
+#Compiler and linker options for application code and kernel code. These
+#options ensure that the compiler has the correct settings for the selected
+#instruction set and interworking.
+ARM_INTERWORK_M_OPT = $...@['-mno-thumb-interwork',
'-mthumb-interwork'][bb.data.getVar('THUMB_INTERWORK', d, 1) == 'yes']}
+ARM_THUMB_M_OPT = $...@['-mno-thumb',
'-mthumb'][bb.data.getVar('ARM_INSTRUCTION_SET', d, 1) == 'thumb']}
+
+#
+TARGET_CC_ARCH += ${ARM_INTERWORK_M_OPT} ${ARM_THUMB_M_OPT}
+TARGET_CC_KERNEL_ARCH += -mno-thumb-interwork -mno-thumb
+
diff --git a/conf/distro/kaeilos-2010.conf b/conf/distro/kaeilos-2010.conf
index 4bb637c..ba37445 100644
--- a/conf/distro/kaeilos-2010.conf
+++ b/conf/distro/kaeilos-2010.conf
@@ -96,6 +96,7 @@ PREFERRED_VERSION_gcc-cross-intermediate ?=
[oe] [PATCH] sane-toolchain.inc: THUMB_INTERWORK should not be defined for armv4 and add armv4 to ARM EABI supporting architectures.
Signed-off-by: Khem Raj raj.k...@gmail.com
---
conf/distro/include/sane-toolchain.inc | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/conf/distro/include/sane-toolchain.inc
b/conf/distro/include/sane-toolchain.inc
index 6b6b170..8d9912f 100644
--- a/conf/distro/include/sane-toolchain.inc
+++ b/conf/distro/include/sane-toolchain.inc
@@ -86,7 +86,12 @@ ARM_INSTRUCTION_SET = ${PREFERRED_ARM_INSTRUCTION_SET}
#but requires more instructions (140% for 70% smaller code) so may be
#slower.
-THUMB_INTERWORK = yes
+# armv4 does not have thumb instruction set therefore no interworking
instructions
+# so if machine is based on armv4 we dont have choice.
+
+THUMB_INTERWORK_armv4 = no
+THUMB_INTERWORK ?= yes
+
# yes no
#Whether to compile with code to allow interworking between the two
#instruction sets. This allows thumb code to be executed on a primarily
@@ -145,7 +150,7 @@ def detect_arm_abi (d):
return oabi
else:
return
- if bb.data.getVar('TARGET_ARCH', d, 1) in [ 'arm', 'armeb' ]:
+ if bb.data.getVar('TARGET_ARCH', d, 1) in [ 'arm', 'armeb' ]:
if 'eabi' in bb.data.getVar('DISTRO_FEATURES',d).split():
return eabi
return oabi
@@ -154,7 +159,7 @@ def detect_arm_abi (d):
def compute_os_portion_of_target_triplet (d):
import bb
arm_eabi_supporting_arches = armv6 armv6-novfp \
- armv5te iwmmxt armv7a armv7 armv5teb armv4t
+ armv5te iwmmxt armv7a armv7 armv5teb armv4t armv4
ppc_spe_supporting_arches = ppce500v2 ppce500
gnu_suffix =
if bb.data.getVar('LIBC', d, 1) == uclibc:
--
1.7.0.4
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [Bitbake-dev] A new bitbake extension: .bbappend files
I'd be very interested to find a way so that a 'require gcc.inc' in myproject/recipes/gcc_4.4.4.bb would find oe-stable/recipes/gcc/gcc.inc. So far I failed. Try to add the relative path of the .inc to your require statement: 'require recipes/gcc/gcc.inc' (see also the arago overlays as example) my overlays are working in this way. The problem was, all require statements should be done in this way, so the building of overlays would be much easier. Wolfgang ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] Openjdk shark and cacao VMs not working
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I built openjdk completely from scratch and installed it: opkg install openjdk-6-common openjdk-6-demo openjdk-6-java openjdk-6-jdk openjdk-6-jre opkg install openjdk-6-vm-shark openjdk-6-vm-cacao That needs to be done in 2 opkg commands since -cacao and -shark edit a jvm.cfg in their postinst which isn't in their Depends: line. Trivial to fix, need to sit down and see in which package it resides. So: r...@beagleboard-c4:~# java -zero Linpack # [1] Mflops/s: 9.537 Time: 0.07 secs Norm Res: 1.43 Precision: 2.220446049250313E-16 So far, so good. Better than the 3 Mflops jamvm+classpath gets, but not as nice as the 16Mflops cacao+classpath can do. So lets try some other VMs: r...@beagleboard-c4:~# java -shark Linpack ARMCodeEmitter::emitPseudoInstruction UNREACHABLE executed at /OE/angstrom-dev/work/armv7a-angstrom-linux-gnueabi/llvm2.7-2.7-r6/llvm-2.7/lib/Target/ARM/ARMCodeEmitter.cpp:554! Stack dump: 0. Running pass 'ARM Machine Code Emitter' on function '@Linpack::daxpy' Aborted OK, Xerxes blogged about debugging such issues, but the summer intern is too busy with other stuff currently. r...@beagleboard-c4:~# java -cacao Linpack java: avl.c:348: avl_find: Assertion `tree' failed. Aborted No idea on that. Do the java mages have some idea on how to get shark and cacao working well? regards, Koen [1] http://www.netlib.org/benchmark/linpackjava/LinpackJava.zip compiled with javac on osx -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFMRBzPMkyGM64RGpERAiEJAJ4yeJVBcvuwHzVbS++Zt5iI9Rp11QCgm3aB Xqj79L9E1QpIz19c0QSxh6o= =OBoo -END PGP SIGNATURE- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] angstrom-jalimo: fix openjdk-6-jre preferred version
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Acked-by: Koen Kooi k-k...@ti.com On 18-07-10 12:54, Martin Jansa wrote: --- conf/distro/include/angstrom-jalimo.conf |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/conf/distro/include/angstrom-jalimo.conf b/conf/distro/include/angstrom-jalimo.conf index effde60..2aed63b 100644 --- a/conf/distro/include/angstrom-jalimo.conf +++ b/conf/distro/include/angstrom-jalimo.conf @@ -22,7 +22,7 @@ PREFERRED_VERSION_jamvm = 1.5.2 PREFERRED_PROVIDER_swt3.4-gtk = swt3.4-gtk PREFERRED_PROVIDER_classpath = classpath -PREFERRED_VERSION_openjdk-6-jre = 6b18 +PREFERRED_VERSION_openjdk-6-jre = 6b18-1.8 PREFERRED_VERSION_icedtea6-native = 1.7.3 # Stage JAR files not into ARCH related dirs -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFMRB1vMkyGM64RGpERAtP2AKCJr9A1Vtq2RDZcK730k1taZWfHdgCfYa9v xBLzSxAQze2M3Zf32zwlwE8= =AvQZ -END PGP SIGNATURE- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] sane-toolchain.inc: THUMB_INTERWORK should not be defined for armv4 and add armv4 to ARM EABI supporting architectures.
On Mon, 2010-07-19 at 01:24 -0700, Khem Raj wrote: -THUMB_INTERWORK = yes +# armv4 does not have thumb instruction set therefore no interworking instructions +# so if machine is based on armv4 we dont have choice. + +THUMB_INTERWORK_armv4 = no +THUMB_INTERWORK ?= yes I don't think this is necessary or desirable. If you are building for v4 then the BX instructions ought to be fixed up during final link. Is there a particular problem that you're trying to solve? p. ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH 1/2] libgpsbt_0.1: adding dbus-glib to DEPENDS
On Wed, 14 Jul 2010 21:50:11 +0200 Antonio Ospite osp...@studenti.unina.it wrote: On Tue, 13 Jul 2010 16:08:56 +0200 Nicola Ranaldo nicola.rana...@gmail.com wrote: --- recipes/maemo4/libgpsbt_0.1.bb |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Hi Nicola, would you mind telling something more about these patches? Why are they needed: are they urgent fixes for non building recipes, are they only improvements? If you are the same Nicola Ranaldo from unina.it I might consider pushing them for you in OE upon trust (if others confirm me that it is ok to do so), but that's just because I know you from fame; generally a more verbose commit message would help people in picking up patches about areas of a project they are not directly interested in. Ah, and you should increase PR when changing a recipe like you are doing. Ok, I am taking these, btw Martin told Nicola that increasing PR is not needed as the recipes were failing to build at all before these fixes, and this looks OK to me too. Regards, Antonio -- Antonio Ospite http://ao2.it PGP public key ID: 0x4553B001 A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? pgpjWlsumQXpS.pgp Description: PGP signature ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] sane-toolchain.inc: THUMB_INTERWORK should not be defined for armv4 and add armv4 to ARM EABI supporting architectures.
On Mon, Jul 19, 2010 at 7:26 AM, Phil Blundell ph...@gnu.org wrote: On Mon, 2010-07-19 at 01:24 -0700, Khem Raj wrote: -THUMB_INTERWORK = yes +# armv4 does not have thumb instruction set therefore no interworking instructions +# so if machine is based on armv4 we dont have choice. + +THUMB_INTERWORK_armv4 = no +THUMB_INTERWORK ?= yes I don't think this is necessary or desirable. If you are building for v4 then the BX instructions ought to be fixed up during final link. Yes with --fix-v4bx/--fix-v4bx-interworking its possible. Is there a particular problem that you're trying to solve? Not any particular case but some versions of compiler do not pass flags to --fix-v4bx-interworking ld. I was thinking its more apt to describe the machine with not supporting THUMB_INTERWORK hmmm but I now I see that we will need it for v4/EABI support. So better fix the compiler. p. ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] sane-toolchain.inc: THUMB_INTERWORK should not be defined for armv4 and add armv4 to ARM EABI supporting architectures.
On Mon, 2010-07-19 at 09:29 -0700, Khem Raj wrote: On Mon, Jul 19, 2010 at 7:26 AM, Phil Blundell ph...@gnu.org wrote: On Mon, 2010-07-19 at 01:24 -0700, Khem Raj wrote: -THUMB_INTERWORK = yes +# armv4 does not have thumb instruction set therefore no interworking instructions +# so if machine is based on armv4 we dont have choice. + +THUMB_INTERWORK_armv4 = no +THUMB_INTERWORK ?= yes I don't think this is necessary or desirable. If you are building for v4 then the BX instructions ought to be fixed up during final link. Yes with --fix-v4bx/--fix-v4bx-interworking its possible. Is there a particular problem that you're trying to solve? Not any particular case but some versions of compiler do not pass flags to --fix-v4bx-interworking ld. True. But this is sane-toolchain we're talking about, and the version that it selects by default (4.4.4) does get this right. So I don't think it's going to be a big deal in practice. p. ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] sane-toolchain.inc: THUMB_INTERWORK should not be defined for armv4 and add armv4 to ARM EABI supporting architectures.
On Mon, Jul 19, 2010 at 9:46 AM, Phil Blundell ph...@gnu.org wrote: On Mon, 2010-07-19 at 09:29 -0700, Khem Raj wrote: On Mon, Jul 19, 2010 at 7:26 AM, Phil Blundell ph...@gnu.org wrote: On Mon, 2010-07-19 at 01:24 -0700, Khem Raj wrote: -THUMB_INTERWORK = yes +# armv4 does not have thumb instruction set therefore no interworking instructions +# so if machine is based on armv4 we dont have choice. + +THUMB_INTERWORK_armv4 = no +THUMB_INTERWORK ?= yes I don't think this is necessary or desirable. If you are building for v4 then the BX instructions ought to be fixed up during final link. Yes with --fix-v4bx/--fix-v4bx-interworking its possible. Is there a particular problem that you're trying to solve? Not any particular case but some versions of compiler do not pass flags to --fix-v4bx-interworking ld. True. But this is sane-toolchain we're talking about, and the version that it selects by default (4.4.4) does get this right. So I don't think it's going to be a big deal in practice. yes disregard that hunk. p. ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] OE weekly changelog for 2010-07-12 to 2010-07-19
OE weekly changelog for org.openembedded.dev, 2010-07-12 to 2010-07-19
Denis 'GNUtoo' Carikli (4):
marvell-gspi and marvell-sdio: move duplicated license in separate package/r
xserver-xorg-conf: add new htcdream's xorg.conf
linux-leviathan: switched to a new branch and bump PR
keymaps: remove initscripts dependency
Denys Dmytriyenko (3):
libc-client: remove extra openssl from the include path
php: make sed avoid unaccessible .pc files left by quilt
libgles-omap3: pass rpath-link properly instead of adding more -lX libs
Dmitry Eremin-Solenikov (8):
u-boot: add a recipe for fresh release of u-boot. Also make it default for t
u-boot: switch lite5200 to current u-boot and drop u-boot 2010.03 which had
tqm8540: drop u-boot versioning, add kernel uImage parameters
linux.inc: add KERNEL_DEVICETREE_tqm8540 definition
linux-2.6.34: add tqm8540 configuration
gdb: stop conflicting with binutils
Enrico Scholz (6):
dbus: use $(LIBTOOL) to install 'dbus-daemon'
freetype: updated to 2.3.12
freetype: build with system zlib
encodings/font-util: swapped inter-DEPENDS
ipkg-utils: convert mtime to int before comparing it
freetype: fixed broken patches
Frans Meulenbroeks (7):
base.bbclass: introduce COMPATIBLE_TARGET_SYS
gcc 4.1.x: patch Makefile.in for cross compile badness
glibc: remove old/obsolete versions
glibc 2.10.1: cleaned up; patches only in local dir
glibc 2.9: cleaned up; patches only in local dir
glibc 2;5: cleaned up; patches only in local dir
glibc-2.9: added missing ld.so.conf
Graham Gower (3):
perl_5.8.8.bb: Don't use hostperl's $Config{cppflags} with cross compiler.
usermanual/chapters/recipes.xml: Executables should be executable.
lsof_4.83.bb: Make recipe buildable again.
Henning Heinold (10):
libtimedate-perl: don't depend on target packages
openjdk-6: fix download URL for jaxws and jaf
uclibc: update git version, fixes ppc32 nptl error
icedtea6-native: use zip-native, rather than hostsystem-zip which is not an
uclibc: fix arm nptl support in the git-version
uclibc: remove obsolete patches for git version
llvm-common: use do_stage for now, until there is a better solution
llvm-common: use do_install to do the stuff
icedtea6-native: use the right variable for zip and override it via make com
openjdk-6: use zip-native rather than host-zip, similiar to icedtea6-native
Khem Raj (4):
quilt-native: Remove RDEPENDS on libtimedate-perl-native
gtk+-2.20.0,gtk+-2.20.1: Fix case where /usr/bin/nm was being generated into
gcc-configure-common.inc: Disable multilib generation.
gdb-common.inc: Add -f to rm the files dont exist while building target gdb
Koen Kooi (16):
angstrom: fix another regression with DISTRO_FEATURES
opal: add 3.8.2
ekiga git: lower default pref
ekiga: add 3.2.7
ptlib: add 2.8.2
ekiga git: bump to current head
ekiga: raise defaultpref for angstrom
ekiga, opal: bump PR
angstrom-task-gnome: remove xorg-minimal-fonts
usbmodeswitch: add 1.1.3
clutter-1.0: add 1.0.10
clutter-box2d: update to 0.10.0
webkit-gtk: add 1.2.3 build (from release tarball, not svn/git)
angstrom: don't use -ggdb3 for -native and -cross
jack: add 0.118.0 (latest stable)
Lukas Gorris (3):
htc-qsd8: use xf86-video-fbdev until xf86-video-msm is fixed
linux-qsd8: bump srcrev, update defconfig and machine features
Martin Jansa (19):
linux-openmoko-2.6.34: bump SRCREV, try to disable UBI debug and reenable ba
linux(-kexecboot): bump SRCREV in git version and update defconfig
freesmartphone: bump cornucopia SRCREV, remove aplied patch from fsogsmd and
libphone-ui: bump SRCREV, remove applied patch
frameworkd: bump SRCREV, remove applied patches
xserver-common_1.33: add xinput-calibrator to SHR RDEPENDS
shr: include sane-toolchain-java.inc and angstrom-jalimo.conf, add largefile
icedtea6-native_1.7.3: backport patch for building without jar in system
icedtea6-native_1.8: don't use kenai.com for jdk6-jaf and jdk6-jaxws, add ri
llvm2.7: force arm mode for now for armv4t
xserver-xorg: move from 1.8.99.904 to 1.8.99.905
task-shr-feed: add openjdk-6
openjdk-6-release-6b18: force arm mode for now
task-shr-feed: fix openjdk-6 add
shr: bump SRCREVs to latest
cornucopia: bump SRCREV
phonefsod: bump SRCREV
linux(-kexecboot)_git: bump SRCREV, add fix for bug 16310
task-shr-feed: update openjdk entry
Michael 'Mickey' Lauer (5):
libgee: move to known-good revision
vala: 0.9.2.1 - 0.9.3.1
msmcommd: add missing dependency
dbus 1.3.1: apply patch from fdo bug 17754
vala: 0.9.3.1 - 0.9.3.2
Robert Schuster (7):
llvm-common: Fixed installation path of helper script (led to issues in Open
jamvm-initial 1.4.5: Face random crashes with a silent retry. jamvm-init
cacao 0.99.3: Fixed packaging of libjvm.so. cacao 0.99.4: Dito.
jamvm 1.4.5 - 1.5.3: Fixed packaging of libjvm.so
jamvm-initial 1.4.5,1.5.0: Fixed binary to be called in script.
jamvm-native: Add
Re: [oe] spca5xx does not build
Can anyone else help me out with this for building? I am at a loss as to whats up with this. Thanks On Sat, Jul 17, 2010 at 1:51 PM, J. L. vwyodap...@gmail.com wrote: I just tried adding EXTRA_CFLAGS in the bb file and still errors in the same way. I also cleaned it to make sure before building. Also there is an error stating an implasibly old time stamp from 1964? On Sat, Jul 17, 2010 at 2:53 AM, Holger Freyther holger...@freyther.de wrote: | make[1]: Entering directory `/home/vdubhack/overo-oe/tmp/sysroots/overo-angstrom-linux-gnueabi/kernel' | scripts/Makefile.build:49: *** CFLAGS was changed in /home/vdubhack/overo-oe/tmp/work/overo-angstrom-linux-gnueabi/spca5xx-20060501-r81/spca5xx-20060501/Makefile. Fix it to use EXTRA_CFLAGS. Stop. ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] sane-toolchain.inc: THUMB_INTERWORK should not be defined for armv4 and add armv4 to ARM EABI supporting architectures.
On Mon, 2010-07-19 at 01:24 -0700, Khem Raj wrote: import bb arm_eabi_supporting_arches = armv6 armv6-novfp \ - armv5te iwmmxt armv7a armv7 armv5teb armv4t + armv5te iwmmxt armv7a armv7 armv5teb armv4t armv4 ppc_spe_supporting_arches = ppce500v2 ppce500 I guess it would make more sense to enumerate here the ARM arches which don't support eabi. All future ones will, presumably, so it's only ARMv3 and older which don't. That way we won't have to keep adjusting this list for every new architecture variant that someone thinks up. p. ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] A new bitbake extension: .bbappend files
Richard Purdie wrote:
Whilst our layers mechanism, is great it does have a drawback which has
bugged me for a while. If you have a recipe like pointercal which has
machine specific information in it and you have your new machine code in
a layer, how do you add a pointercal file for your machine?
Answer is you copy the whole pointercal recipe and files into your
layer, then add the single file for your machine. To me this is ugly,
ugly, ugly. We hate code duplication and as soon as you create two
copies of the same information, we've failed.
So how could we do this better? Somehow we need to say that a given
directory X has some information which should be merged with the
original recipe. I've thought through several different ways of doing
this and the best solution I found was bbappend.
The idea is that if bitbake finds any X.bbappend files, when it loads
X.bb, it will also include these files after it parses the base .bb file
(but before finalise and the anonymous methods run). This means that
the .bbappend file can poke around and do whatever it might want to the
recipe to customise it.
I went ahead and tried it out as its quite simple to code this in
bitbake. I liked the result enough I've already merged this into Poky:
http://git.pokylinux.org/cgit.cgi/poky/commit/?id=63e6ba85677b8aa9f4cf9942a1fccbb8a8c72660
I'm proposing to push it to bitbake master if there are no serious
objections.
As an example use case, for the pointercal case above in another later
you could add a pointercal_0.0.bbappend file which contained something
like:
FILESPATH := ${FILESPATH}:$...@os.path.dirname(bb.data.getVar('FILE', d,
True))}
which would then cause the directory containing the bbappend file to be
searched for pointercal files.
There are of course many other uses this could be put to for creating
customised layers, its totally generic.
For the specific case of paths, I have wondered if there would be a way
to leverage help from bitbake in creating a sane set of search paths but
I'm still thinking about that. This extension is good enough in its own
right in my opinion to be worthwhile.
I must be missing something. How is this better than amend.inc where
today you would just do:
# Just to make sure PR does change, could actually be omitted for this
# example
$ echo 'PR .= .1' mymachine/recipes/pointercal/amend.inc
$ cp /tmp/mycal mymachine/recipes/pointercal/whatever_it_is_called
? Or did you just give too trivial of an example here, and as there are
indeed places where amend.inc falls down today, this does work?
--
Tom Rini
Mentor Graphics Corporation
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] A new bitbake extension: .bbappend files
On Mon, Jul 19, 2010 at 1:50 PM, Tom Rini tom_r...@mentor.com wrote:
Richard Purdie wrote:
Whilst our layers mechanism, is great it does have a drawback which has
bugged me for a while. If you have a recipe like pointercal which has
machine specific information in it and you have your new machine code in
a layer, how do you add a pointercal file for your machine?
Answer is you copy the whole pointercal recipe and files into your
layer, then add the single file for your machine. To me this is ugly,
ugly, ugly. We hate code duplication and as soon as you create two
copies of the same information, we've failed.
So how could we do this better? Somehow we need to say that a given
directory X has some information which should be merged with the
original recipe. I've thought through several different ways of doing
this and the best solution I found was bbappend.
The idea is that if bitbake finds any X.bbappend files, when it loads
X.bb, it will also include these files after it parses the base .bb file
(but before finalise and the anonymous methods run). This means that
the .bbappend file can poke around and do whatever it might want to the
recipe to customise it.
I went ahead and tried it out as its quite simple to code this in
bitbake. I liked the result enough I've already merged this into Poky:
http://git.pokylinux.org/cgit.cgi/poky/commit/?id=63e6ba85677b8aa9f4cf9942a1fccbb8a8c72660
I'm proposing to push it to bitbake master if there are no serious
objections.
As an example use case, for the pointercal case above in another later
you could add a pointercal_0.0.bbappend file which contained something
like:
FILESPATH := ${FILESPATH}:$...@os.path.dirname(bb.data.getVar('FILE', d,
True))}
which would then cause the directory containing the bbappend file to be
searched for pointercal files.
There are of course many other uses this could be put to for creating
customised layers, its totally generic.
For the specific case of paths, I have wondered if there would be a way
to leverage help from bitbake in creating a sane set of search paths but
I'm still thinking about that. This extension is good enough in its own
right in my opinion to be worthwhile.
I must be missing something. How is this better than amend.inc where today
you would just do:
# Just to make sure PR does change, could actually be omitted for this
# example
$ echo 'PR .= .1' mymachine/recipes/pointercal/amend.inc
$ cp /tmp/mycal mymachine/recipes/pointercal/whatever_it_is_called
? Or did you just give too trivial of an example here, and as there are
indeed places where amend.inc falls down today, this does work?
It's the opposite. amend.inc is a bit more flexible than bbappend, not vice
versa, but bbappend has fewer performance implications, and is supported
directly by bitbake itself (and ensures that anonymous python functions will
work fine in appended metadata). Aside: I also suspect that BBCLASSEXTEND
alterations will work correctly from a bbappend, which does not work
correctly today from an amend.inc.
You'd have to be careful to lock down your appended versions when using
bbappend, since bitbake could easily pick a newer version without the append
out from under you, which is not an issue with amend.inc. This is why I was
planning to test it out with some real world situations to see if it's
sufficiently flexible for most cases or not. I haven't yet had a chance.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] A new bitbake extension: .bbappend files
On Mon, Jul 19, 2010 at 2:22 PM, Chris Larson clar...@kergoth.com wrote:
On Mon, Jul 19, 2010 at 1:50 PM, Tom Rini tom_r...@mentor.com wrote:
Richard Purdie wrote:
Whilst our layers mechanism, is great it does have a drawback which has
bugged me for a while. If you have a recipe like pointercal which has
machine specific information in it and you have your new machine code in
a layer, how do you add a pointercal file for your machine?
Answer is you copy the whole pointercal recipe and files into your
layer, then add the single file for your machine. To me this is ugly,
ugly, ugly. We hate code duplication and as soon as you create two
copies of the same information, we've failed.
So how could we do this better? Somehow we need to say that a given
directory X has some information which should be merged with the
original recipe. I've thought through several different ways of doing
this and the best solution I found was bbappend.
The idea is that if bitbake finds any X.bbappend files, when it loads
X.bb, it will also include these files after it parses the base .bb file
(but before finalise and the anonymous methods run). This means that
the .bbappend file can poke around and do whatever it might want to the
recipe to customise it.
I went ahead and tried it out as its quite simple to code this in
bitbake. I liked the result enough I've already merged this into Poky:
http://git.pokylinux.org/cgit.cgi/poky/commit/?id=63e6ba85677b8aa9f4cf9942a1fccbb8a8c72660
I'm proposing to push it to bitbake master if there are no serious
objections.
As an example use case, for the pointercal case above in another later
you could add a pointercal_0.0.bbappend file which contained something
like:
FILESPATH := ${FILESPATH}:$...@os.path.dirname(bb.data.getVar('FILE', d,
True))}
which would then cause the directory containing the bbappend file to be
searched for pointercal files.
There are of course many other uses this could be put to for creating
customised layers, its totally generic.
For the specific case of paths, I have wondered if there would be a way
to leverage help from bitbake in creating a sane set of search paths but
I'm still thinking about that. This extension is good enough in its own
right in my opinion to be worthwhile.
I must be missing something. How is this better than amend.inc where
today you would just do:
# Just to make sure PR does change, could actually be omitted for this
# example
$ echo 'PR .= .1' mymachine/recipes/pointercal/amend.inc
$ cp /tmp/mycal mymachine/recipes/pointercal/whatever_it_is_called
? Or did you just give too trivial of an example here, and as there are
indeed places where amend.inc falls down today, this does work?
It's the opposite. amend.inc is a bit more flexible than bbappend, not
vice versa, but bbappend has fewer performance implications, and is
supported directly by bitbake itself (and ensures that anonymous python
functions will work fine in appended metadata). Aside: I also suspect that
BBCLASSEXTEND alterations will work correctly from a bbappend, which does
not work correctly today from an amend.inc.
You'd have to be careful to lock down your appended versions when using
bbappend, since bitbake could easily pick a newer version without the append
out from under you, which is not an issue with amend.inc.
Although, I suppose you could set DEFAULT_PREFERENCE in the bbappend, so
whenever you include that collection, it gets preferred.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] GPSBABLE -- fixed recipe
It had bad checksums here is the fixed file, hope this helps
SECTION = console/utils
DESCRIPTION = GPS data converter
DEPENDS = expat virtual/libusb0
HOMEPAGE = http://www.gpsbabel.org/;
LICENSE = GPL
SRC_URI = http://www.gpsbabel.org/plan9.php?dl=gpsbabel-${PV}.tar.gz \
file://autotools.patch
inherit autotools pkgconfig
SRC_URI[md5sum] = d41d8cd98f00b204e9800998ecf8427e
SRC_URI[sha256sum] =
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] sane-toolchain.inc: THUMB_INTERWORK should not be defined for armv4 and add armv4 to ARM EABI supporting architectures.
On Mon, Jul 19, 2010 at 1:20 PM, Phil Blundell ph...@gnu.org wrote: On Mon, 2010-07-19 at 01:24 -0700, Khem Raj wrote: import bb arm_eabi_supporting_arches = armv6 armv6-novfp \ - armv5te iwmmxt armv7a armv7 armv5teb armv4t + armv5te iwmmxt armv7a armv7 armv5teb armv4t armv4 ppc_spe_supporting_arches = ppce500v2 ppce500 I guess it would make more sense to enumerate here the ARM arches which don't support eabi. All future ones will, presumably, so it's only ARMv3 and older which don't. That way we won't have to keep adjusting this list for every new architecture variant that someone thinks up. yes thats good idea. p. ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [RFC][PATCH] distro: Move thumb into distro features
On Mon, Jul 19, 2010 at 1:18 AM, Khem Raj raj.k...@gmail.com wrote:
* Currenlty we define the thumb specific overrides in machine tune files
and as machine conf files are included before the distro conf files
the overrides dont get right values and set incorrectly.
* This patch moves the tune-thumb.inc from machine/include into
distro/include and lets distro decide on thumb and thumb-interworking
features based on the machine selected. If a machine which does not
support thumb like all armv4 based machines is selected then distro
makes correct decision now to disable thumb and thumb-interworking
based upon the machine seletected.
I accidentally hit push button in wrong branch and this commit got pushed
I will revert it once I get home later today if someone gets bitten before
feel free to revert it.
Signed-off-by: Khem Raj raj.k...@gmail.com
---
conf/distro/angstrom-2008.1.conf | 1 +
conf/distro/gmustix.conf | 2 +
conf/distro/include/arm-thumb.inc | 32
+++
conf/distro/kaeilos-2010.conf | 1 +
conf/distro/kaeilos.conf | 1 +
conf/distro/micro.conf | 1 +
conf/distro/minimal.conf | 3 +-
conf/distro/shr.conf | 1 +
conf/distro/slugos.conf | 2 +
conf/machine/include/ixp4xx.inc | 1 -
conf/machine/include/tune-arm1136-novfp.inc | 3 --
conf/machine/include/tune-arm1136jf-s.inc | 3 --
conf/machine/include/tune-arm1176jzf-s.inc | 3 --
conf/machine/include/tune-arm920t.inc | 4 ---
conf/machine/include/tune-arm926ejs.inc | 3 --
conf/machine/include/tune-arm9tdmi.inc | 4 ---
conf/machine/include/tune-armv7.inc | 4 ---
conf/machine/include/tune-ep9312.inc | 3 --
conf/machine/include/tune-thumb.inc | 32
---
conf/machine/include/tune-xscale.inc | 4 ---
conf/machine/palmz31.conf | 3 --
conf/machine/palmz72.conf | 3 --
22 files changed, 43 insertions(+), 71 deletions(-)
create mode 100644 conf/distro/include/arm-thumb.inc
delete mode 100644 conf/machine/include/tune-thumb.inc
diff --git a/conf/distro/angstrom-2008.1.conf
b/conf/distro/angstrom-2008.1.conf
index 7c70c84..84e8096 100644
--- a/conf/distro/angstrom-2008.1.conf
+++ b/conf/distro/angstrom-2008.1.conf
@@ -136,6 +136,7 @@ PREFERRED_VERSION_binutils-cross-sdk_avr32 = 2.17
# Toolchain virtuals:
require conf/distro/include/toolchain-${TOOLCHAIN_TYPE}.inc
+require conf/distro/include/arm-thumb.inc
PREFERRED_PROVIDER_dbus-glib = dbus-glib
PREFERRED_PROVIDER_hotplug = udev
diff --git a/conf/distro/gmustix.conf b/conf/distro/gmustix.conf
index 17f8056..5dd519d 100644
--- a/conf/distro/gmustix.conf
+++ b/conf/distro/gmustix.conf
@@ -5,6 +5,8 @@
INHERIT += package_tar package_ipk
LIBC = uclibc
require conf/distro/include/${LIBC}.inc
+require conf/distro/include/arm-thumb.inc
+
TARGET_OS = linux-uclibc
TARGET_FPU = soft
IMAGE_FSTYPES = jffs2
diff --git a/conf/distro/include/arm-thumb.inc
b/conf/distro/include/arm-thumb.inc
new file mode 100644
index 000..cd88bb4
--- /dev/null
+++ b/conf/distro/include/arm-thumb.inc
@@ -0,0 +1,32 @@
+#tune file for thumb instructions
+
+ARM_INSTRUCTION_SET ?= arm
+# arm thumb
+# The instruction set the compiler should use when generating application
+# code. The kernel is always compiled with arm code at present. arm code
+# is the original 32 bit ARM instruction set, thumb code is the 16 bit
+# encoded RISC sub-set. Thumb code is smaller (maybe 70% of the ARM size)
+# but requires more instructions (140% for 70% smaller code) so may be
+# slower.
+
+THUMB_INTERWORK ?= no
+# yes no
+# Whether to compile with code to allow interworking between the two
+# instruction sets. This allows thumb code to be executed on a primarily
+# arm system and vice versa. It is strongly recommended that DISTROs not
+# turn this off - the actual cost is very small.
+
+OVERRIDE_THUMB = $...@['', ':thumb'][bb.data.getVar('ARM_INSTRUCTION_SET',
d, 1) == 'thumb']}
+OVERRIDE_INTERWORK = $...@['',
':thumb-interwork'][bb.data.getVar('THUMB_INTERWORK', d, 1) == 'yes']}
+OVERRIDES .= ${OVERRIDE_THUMB}${OVERRIDE_INTERWORK}
+
+# Compiler and linker options for application code and kernel code. These
+# options ensure that the compiler has the correct settings for the
selected
+# instruction set and interworking.
+ARM_INTERWORK_M_OPT = $...@['-mno-thumb-interwork',
'-mthumb-interwork'][bb.data.getVar('THUMB_INTERWORK', d, 1) == 'yes']}
+ARM_THUMB_M_OPT = $...@['-mno-thumb',
'-mthumb'][bb.data.getVar('ARM_INSTRUCTION_SET', d, 1) == 'thumb']}
+
+#
+TARGET_CC_ARCH += ${ARM_INTERWORK_M_OPT}
Re: [oe] [PATCH] sane-toolchain.inc: THUMB_INTERWORK should not be defined for armv4 and add armv4 to ARM EABI supporting architectures.
On Mon, Jul 19, 2010 at 1:20 PM, Phil Blundell ph...@gnu.org wrote: On Mon, 2010-07-19 at 01:24 -0700, Khem Raj wrote: import bb arm_eabi_supporting_arches = armv6 armv6-novfp \ - armv5te iwmmxt armv7a armv7 armv5teb armv4t + armv5te iwmmxt armv7a armv7 armv5teb armv4t armv4 ppc_spe_supporting_arches = ppce500v2 ppce500 I guess it would make more sense to enumerate here the ARM arches which don't support eabi. All future ones will, presumably, so it's only ARMv3 and older which don't. That way we won't have to keep adjusting this list for every new architecture variant that someone thinks up. and I think the oldest arm architecture we support is armv4 which means we may not need this check at all anymore. p. ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH][STABLE 1/3] shadow: Disable email checking completely
On (13/07/10 20:48), Stefan Schmidt wrote: Hello. On Tue, 2010-07-06 at 13:44, Tom Rini wrote: Stefan Schmidt wrote: From: Stefan Schmidt ste...@buglabs.net This allows faster login due to not checking for new emails. Adjust PR to 14 as stable is behind .dev here. Signed-off-by: Stefan Schmidt ste...@buglabs.net Acked-by: Tom Rini tom_r...@mentor.com Acked-by: Khem Raj raj.k...@gmail.com Thanks. May I could motivate someone else to review and give an ack here. Also the other patches in this set are out for review as well. :) regards Stefan Schmidt ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] libpng: Add add 1.2.44, new version and new native version importing several security fixes.
On (19/07/10 11:25), Marc Olzheim wrote:
From: Marc Olzheim m...@iphion.nl
---
recipes/libpng/libpng-native_1.2.44.bb |6 ++
recipes/libpng/libpng_1.2.44.bb|8
2 files changed, 14 insertions(+), 0 deletions(-)
create mode 100644 recipes/libpng/libpng-native_1.2.44.bb
You coul use BBCLASSEXTEND for -native recipe.
create mode 100644 recipes/libpng/libpng_1.2.44.bb
diff --git a/recipes/libpng/libpng-native_1.2.44.bb
b/recipes/libpng/libpng-native_1.2.44.bb
new file mode 100644
index 000..3c36b52
--- /dev/null
+++ b/recipes/libpng/libpng-native_1.2.44.bb
@@ -0,0 +1,6 @@
+require libpng_${PV}.bb
+require libpng-native.inc
+
+PR = r1
+
+FILESDIR = $...@os.path.dirname(bb.data.getVar('FILE',d,1))}/libpng-${PV}
diff --git a/recipes/libpng/libpng_1.2.44.bb b/recipes/libpng/libpng_1.2.44.bb
new file mode 100644
index 000..e607f76
--- /dev/null
+++ b/recipes/libpng/libpng_1.2.44.bb
@@ -0,0 +1,8 @@
+require libpng.inc
+
+PR = ${INC_PR}.0
+
+SRC_URI += file://makefile_fix.patch
+
+SRC_URI[tarball.md5sum] = e3ac7879d62ad166a6f0c7441390d12b
+SRC_URI[tarball.sha256sum] =
b9ab20f1c2c3bf6c4448fd9bd8a4a8905b918114d5fada56c97bb758a17b7215
--
1.7.0.4
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] arm-atomic-gcc patches for oe-stable
On (19/07/10 16:58), hein...@inf.fu-berlin.de wrote: From: Henning Heinold h.hein...@tarent.de Hi, this is a backport for the arm-atomic-gcc patches. It is the first step to get openjdk into oe-stable. Acked-by: Khem Raj raj.k...@gmail.com Bye, Henning Henning Heinold (1): gcc: backport 4.3.x atomic-patches series from openembedded-dev recipes/gcc/gcc-4.3.1.inc |4 +- .../gcc-4.3.1/debian/armel-atomic-builtins.dpatch | 350 ...90519-arm-eabi-atomic-builtins-unbreak-v2.patch | 52 +++ recipes/gcc/gcc-4.3.2.inc |4 +- .../gcc-4.3.2/debian/armel-atomic-builtins.dpatch | 350 ...90519-arm-eabi-atomic-builtins-unbreak-v2.patch | 52 +++ recipes/gcc/gcc-4.3.3.inc |2 + .../gcc-4.3.3/debian/armel-atomic-builtins.dpatch | 350 ...90519-arm-eabi-atomic-builtins-unbreak-v2.patch | 52 +++ recipes/gcc/gcc-cross-sdk_4.3.1.bb |2 +- recipes/gcc/gcc-cross-sdk_4.3.2.bb |2 +- recipes/gcc/gcc-cross-sdk_4.3.3.bb |2 +- recipes/gcc/gcc-cross_4.3.1.bb |2 +- recipes/gcc/gcc-cross_4.3.2.bb |2 +- recipes/gcc/gcc-cross_4.3.3.bb |2 +- recipes/gcc/gcc_4.3.1.bb |2 +- recipes/gcc/gcc_4.3.2.bb |2 +- recipes/gcc/gcc_4.3.3.bb |2 +- 18 files changed, 1223 insertions(+), 11 deletions(-) create mode 100644 recipes/gcc/gcc-4.3.1/debian/armel-atomic-builtins.dpatch create mode 100644 recipes/gcc/gcc-4.3.1/gcc-4.4-20090519-arm-eabi-atomic-builtins-unbreak-v2.patch create mode 100644 recipes/gcc/gcc-4.3.2/debian/armel-atomic-builtins.dpatch create mode 100644 recipes/gcc/gcc-4.3.2/gcc-4.4-20090519-arm-eabi-atomic-builtins-unbreak-v2.patch create mode 100644 recipes/gcc/gcc-4.3.3/debian/armel-atomic-builtins.dpatch create mode 100644 recipes/gcc/gcc-4.3.3/gcc-4.4-20090519-arm-eabi-atomic-builtins-unbreak-v2.patch ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [RFC][PATCH] distro: Move thumb into distro features
On Mon, Jul 19, 2010 at 3:46 PM, Khem Raj raj.k...@gmail.com wrote:
On Mon, Jul 19, 2010 at 1:18 AM, Khem Raj raj.k...@gmail.com wrote:
* Currenlty we define the thumb specific overrides in machine tune files
and as machine conf files are included before the distro conf files
the overrides dont get right values and set incorrectly.
* This patch moves the tune-thumb.inc from machine/include into
distro/include and lets distro decide on thumb and thumb-interworking
features based on the machine selected. If a machine which does not
support thumb like all armv4 based machines is selected then distro
makes correct decision now to disable thumb and thumb-interworking
based upon the machine seletected.
I accidentally hit push button in wrong branch and this commit got pushed
I will revert it once I get home later today if someone gets bitten before
feel free to revert it.
Done. Meanwhile, Does this patch look ok for .dev ? I would like some ACKs
Thanks
-Khem
Signed-off-by: Khem Raj raj.k...@gmail.com
---
conf/distro/angstrom-2008.1.conf | 1 +
conf/distro/gmustix.conf | 2 +
conf/distro/include/arm-thumb.inc | 32
+++
conf/distro/kaeilos-2010.conf | 1 +
conf/distro/kaeilos.conf | 1 +
conf/distro/micro.conf | 1 +
conf/distro/minimal.conf | 3 +-
conf/distro/shr.conf | 1 +
conf/distro/slugos.conf | 2 +
conf/machine/include/ixp4xx.inc | 1 -
conf/machine/include/tune-arm1136-novfp.inc | 3 --
conf/machine/include/tune-arm1136jf-s.inc | 3 --
conf/machine/include/tune-arm1176jzf-s.inc | 3 --
conf/machine/include/tune-arm920t.inc | 4 ---
conf/machine/include/tune-arm926ejs.inc | 3 --
conf/machine/include/tune-arm9tdmi.inc | 4 ---
conf/machine/include/tune-armv7.inc | 4 ---
conf/machine/include/tune-ep9312.inc | 3 --
conf/machine/include/tune-thumb.inc | 32
---
conf/machine/include/tune-xscale.inc | 4 ---
conf/machine/palmz31.conf | 3 --
conf/machine/palmz72.conf | 3 --
22 files changed, 43 insertions(+), 71 deletions(-)
create mode 100644 conf/distro/include/arm-thumb.inc
delete mode 100644 conf/machine/include/tune-thumb.inc
diff --git a/conf/distro/angstrom-2008.1.conf
b/conf/distro/angstrom-2008.1.conf
index 7c70c84..84e8096 100644
--- a/conf/distro/angstrom-2008.1.conf
+++ b/conf/distro/angstrom-2008.1.conf
@@ -136,6 +136,7 @@ PREFERRED_VERSION_binutils-cross-sdk_avr32 = 2.17
# Toolchain virtuals:
require conf/distro/include/toolchain-${TOOLCHAIN_TYPE}.inc
+require conf/distro/include/arm-thumb.inc
PREFERRED_PROVIDER_dbus-glib = dbus-glib
PREFERRED_PROVIDER_hotplug = udev
diff --git a/conf/distro/gmustix.conf b/conf/distro/gmustix.conf
index 17f8056..5dd519d 100644
--- a/conf/distro/gmustix.conf
+++ b/conf/distro/gmustix.conf
@@ -5,6 +5,8 @@
INHERIT += package_tar package_ipk
LIBC = uclibc
require conf/distro/include/${LIBC}.inc
+require conf/distro/include/arm-thumb.inc
+
TARGET_OS = linux-uclibc
TARGET_FPU = soft
IMAGE_FSTYPES = jffs2
diff --git a/conf/distro/include/arm-thumb.inc
b/conf/distro/include/arm-thumb.inc
new file mode 100644
index 000..cd88bb4
--- /dev/null
+++ b/conf/distro/include/arm-thumb.inc
@@ -0,0 +1,32 @@
+#tune file for thumb instructions
+
+ARM_INSTRUCTION_SET ?= arm
+# arm thumb
+# The instruction set the compiler should use when generating application
+# code. The kernel is always compiled with arm code at present. arm
code
+# is the original 32 bit ARM instruction set, thumb code is the 16 bit
+# encoded RISC sub-set. Thumb code is smaller (maybe 70% of the ARM
size)
+# but requires more instructions (140% for 70% smaller code) so may be
+# slower.
+
+THUMB_INTERWORK ?= no
+# yes no
+# Whether to compile with code to allow interworking between the two
+# instruction sets. This allows thumb code to be executed on a primarily
+# arm system and vice versa. It is strongly recommended that DISTROs not
+# turn this off - the actual cost is very small.
+
+OVERRIDE_THUMB = $...@['', ':thumb'][bb.data.getVar('ARM_INSTRUCTION_SET',
d, 1) == 'thumb']}
+OVERRIDE_INTERWORK = $...@['',
':thumb-interwork'][bb.data.getVar('THUMB_INTERWORK', d, 1) == 'yes']}
+OVERRIDES .= ${OVERRIDE_THUMB}${OVERRIDE_INTERWORK}
+
+# Compiler and linker options for application code and kernel code.
These
+# options ensure that the compiler has the correct settings for the
selected
+# instruction set and interworking.
+ARM_INTERWORK_M_OPT = $...@['-mno-thumb-interwork',
'-mthumb-interwork'][bb.data.getVar('THUMB_INTERWORK', d, 1) ==
[oe] [PATCH] sane-toolchain.inc: Check for architectures which dont support EABI
* This patch reverses the check for EABI support. This would mean
that future processors will not have to be added everytime they
come out.
Signed-off-by: Khem Raj raj.k...@gmail.com
---
conf/distro/include/sane-toolchain.inc |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/conf/distro/include/sane-toolchain.inc
b/conf/distro/include/sane-toolchain.inc
index 08fc077..de73922 100644
--- a/conf/distro/include/sane-toolchain.inc
+++ b/conf/distro/include/sane-toolchain.inc
@@ -153,8 +153,7 @@ def detect_arm_abi (d):
def compute_os_portion_of_target_triplet (d):
import bb
- arm_eabi_supporting_arches = armv6 armv6-novfp \
- armv5te iwmmxt armv7a armv7 armv5teb armv4t armv4
+ arm_eabi_unsupported_arches = armv1 armv2 armv3
ppc_spe_supporting_arches = ppce500v2 ppce500
gnu_suffix =
if bb.data.getVar('LIBC', d, 1) == uclibc:
@@ -175,7 +174,7 @@ def compute_os_portion_of_target_triplet (d):
bparch is not None:
if 'eabi' in bb.data.getVar('DISTRO_FEATURES',d,1).split() and \
bb.data.getVar('TARGET_ARCH', d, 1) in [ 'arm', 'armeb' ]:
- if bparch not in arm_eabi_supporting_arches.split():
+ if bparch in arm_eabi_unsupported_arches.split():
bb.fatal(DISTRO requested EABI but selected
machine does not support EABI)
abi_suffix =
else:
--
1.7.0.4
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
