Re: [PATCH 1/3] Add ARM tune file overhaul based largely on work from Mark Hatle

[Mark Hatle <mark.hatle@windriver.com>]

On 7/27/11 9:34 AM, Phil Blundell wrote:
> I just looked at this again and here are a few more comments:
> 
> On Tue, 2011-07-26 at 13:44 +0100, Richard Purdie wrote:
>> +PACKAGE_EXTRA_ARCHS_tune-armv4tb = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv4tb"
> 
> That should be "${PACKAGE_EXTRA_ARCHS_tune-armv4b} armv4tb", I think.
> Otherwise you will get a mixture of big and little endian in there.
> 
>> +++ b/meta/conf/machine/include/arm/arch-armv5-dsp.inc
>> @@ -0,0 +1,40 @@
>> +ARMPKGSFX_DSP = "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "dsp" ], "e", "", d)}"
>> +
>> +require conf/machine/include/arm/arch-armv5.inc
>> +
>> +# Little Endian
>> +AVAILTUNES += "armv5e armv5te"
>> +TUNE_FEATURES_tune-armv5e ?= "armv5 dsp"
>> +TUNE_FEATURES_tune-armv5te ?= "armv5 dsp thumb"
>> +PACKAGE_EXTRA_ARCHS_tune-armv5e = "${PACKAGE_EXTRA_ARCHS_tune-armv5} armv5e"
>> +PACKAGE_EXTRA_ARCHS_tune-armv5te = "${PACKAGE_EXTRA_ARCHS_tune-armv5t} armv5e armv5te"
>> +
>> diff --git a/meta/conf/machine/include/arm/arch-armv5.inc b/meta/conf/machine/include/arm/arch-armv5.inc
>> new file mode 100644
>> index 0000000..55cbe03
>> --- /dev/null
>> +++ b/meta/conf/machine/include/arm/arch-armv5.inc
>> @@ -0,0 +1,51 @@
>> +# Little Endian
>> +AVAILTUNES += "armv5 armv5t armv5e armv5te"
>> +TUNE_FEATURES_tune-armv5 ?= "armv5"
>> +TUNE_FEATURES_tune-armv5t ?= "armv5 thumb"
>> +PACKAGE_EXTRA_ARCHS_tune-armv5 = "${PACKAGE_EXTRA_ARCHS_tune-armv4} armv5"
>> +PACKAGE_EXTRA_ARCHS_tune-armv5t = "${PACKAGE_EXTRA_ARCHS_tune-armv4t} armv5 armv5t"
> 
> There seems to be some duplication of AVAILTUNES going on here.
> 
> Also, I think this v5 stuff is more complex than it needs to be because
> it seems to be trying to cater for architecture combinations that are
> possible in theory but don't actually exist in the wild.  For example, I
> can't immediately think of any ARMv5 implementations that lack Thumb or
> the E instructions.

For the tune names..  armv5 means I want classic ARM instructions, while armv5t
means I was thumb instructions.

So armv5 and armv5t are distinct in the contents of the tunings.

There were armv5's without thumb support.. but that doesn't matter much.  A
machine with thumb is compatible (run-time) with one that does not.  A machine
w/o thumb is not necessarily compatible with thumb executables.

>> +# Little Endian + VFP/DSP
>> +AVAILTUNES += "armv5-vfp armv5t-vfp armv5hf-vfp armv5thf-vfp"
> 
> The comment doesn't seem to match the code here since this is the
> section for chips without DSP.  Incidentally, the name "dsp" for this
> feature seems quite a bad one: maybe we should just call it "armv5e".

Yes, the mention of DSP should be using the 'e'.  What I'm not sure of is does
the "dsp" capabilities actually change any of the code or support generated.  If
not then we can ignore it.

For armv5 this gives us:

armv5, armv5t, armv5e, armv5te... add in their VFP variants and the hard float
EABI...

--Mark

> p.
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core