On 07/27/2011 07:49 AM, Mark Hatle wrote:
On 7/27/11 9:33 AM, Koen Kooi wrote:
Op 27 jul. 2011, om 16:27 heeft Mark Hatle het volgende geschreven:
On 7/27/11 8:33 AM, Richard Purdie wrote:
On Wed, 2011-07-27 at 13:17 +0100, Phil Blundell wrote:
On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
+TARGET_FPU = "${@d.getVar('ARMPKGSFX_FPU', True).strip('-') or 'soft'}"
This seems a bit backwards. Shouldn't TARGET_FPU be the primary
variable and then the package suffix be computed from that, rather than
vice versa?
It's been "fun" to use the rather limited constructs we have in these
variables to construct the end result. I suspect this way around, it was
the easiest way to get the right variables in the right places.
+ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv4", "thumb" ], "t",
"", d)}"
+ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "thumb" ], "t",
"", d)}"
+ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv6", "thumb" ], "t2",
"", d)}"
+ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv7", "thumb" ], "t2",
"", d)}"
This is wrong: ARMv6 doesn't imply Thumb-2.
Ah, yes. I'll fix this.
Are you sure? I thought ARMv6 -was- the first to support Thumb-2. And armv5/4
were thumb(1). Note, not all ARMv6 processors contain thumb support.
As I understand it:
arm1136 doesn't have t2
arm1176 does have t2
both are armv6 :)
They also don't have "thumb" support either. So armv6& thumb == t2.
+# 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.
+TUNEVALID[no-thumb-interwork] = "Disable mixing of thumb and ARM functions"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork",
"-mno-thumb-interwork", "-mthumb-interwork", d)}"
+OVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", ":thumb-interwork",
"", d)}"
This is only relevant for v4t, I guess. Interworking is basically
always on for v5 and later and (CeSI aside) it's impossible on v4, so
hardly anybody is going to be flipping this switch. I'm not sure it
really merits an OVERRIDE.
I'd be happy to remove this option if there are no objections. It was
left for compatibility with the existing tune-thumb file but as you say,
it likely doesn't make much sense.
--- a/meta/conf/machine/include/tune-xscale.inc
+++ b/meta/conf/machine/include/tune-xscale.inc
@@ -1,11 +1,17 @@
-require conf/machine/include/arm/arch-arm.inc
+DEFAULTTUNE ?= "xscale"
-INHERIT += "siteinfo"
+require conf/machine/include/arm/arch-armv5-dsp.inc
-TUNE_CCARGS = "-march=armv5te -mtune=xscale"
-TARGET_CC_KERNEL_ARCH = "-march=armv5te -mtune=xscale"
-TUNE_PKGARCH = "${@['armv5teb', 'armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d,
1) == 'le']}"
-PACKAGE_EXTRA_ARCHS = "${@['armeb armv4b armv4tb armv5teb', 'arm armv4 armv4t
armv5te'][bb.data.getVar('SITEINFO_ENDIANESS', d, 1) == 'le']}"
+TUNEVALID[xscale] = "Enable PXA255/PXA26x Xscale specific processor
optimizations"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale",
"", d)}"
+
+AVAILTUNES += "xscale"
+TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5te} xscale"
+PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5te}"
+
+AVAILTUNES += "xscale-be"
+TUNE_FEATURES_tune-xscale = "${TUNE_FEATURES_tune-armv5teb} xscale"
+PACKAGE_EXTRA_ARCHS_tune-xscale = "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}"
I guess that should be "_tune-xscale-be".
Yes, I'll fix, well spotted.
In the original work I did it was just tune-xscale (no be). AFAIK there is no
little endian version of xscale. (there was an iwmmxt that was similar to
xscale, but was slightly different.)
pxa25x are LE xscales (e.g. Palm Treo)
pxa26x are LE xscales with some NAND builtin
pxa27x are LE xscales with iwmmxt as an extra
All thought all of those were considered to me iwmmxt cores. The whole PXA
series naming is very confusing to say the least.
arm cores support both endians equally well. Its the usecases we have on
OE are little endian.
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
