On 07/27/2011 06: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.
+# 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.
I know SHR uses armv4t but I dont know of armv4 usecases. May be we
could may armv4t as oldest supported arm arch and leave armv4 out.
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
