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

[Khem Raj]

On 07/28/2011 11:08 PM, Khem Raj wrote:
> 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.

oh well how did I forget strongARM so yes dropping armv4 may not be so easy