[OE-core] [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle

[Khem Raj]

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.