[PATCH 0/1] ARMPKGSFX_FP ordering

[PATCH 0/1] ARMPKGSFX_FP ordering

[Matt Madison]

I was trying some multilib ARM builds and ran into an issue.  For
armv7ahf-neon-vfpv4, PACKAGE_EXTRA_ARCHS is coded as "armv7ahf-vfp-neon-vfpv4",
but the ARMPKGSFX_FPU suffix was getting constructed as "-vfp-vfpv4-neon", resulting
in 32-bit packages not getting found due to the name mismatch.

The following patch fixes this by changing ARMPKGSFX_FPU.  I'm not sure if it
would be more correct to change the PACKAGE_EXTRA_ARCHS settings, but the
'neon-vfpv4' more closely aligns to the tune names, so I took this route.

Matt Madison (1):
  feature-arm-neon.inc, feature-arm-vfp.inc: fix vfpv4 suffix ordering

 meta/conf/machine/include/arm/feature-arm-neon.inc | 2 +-
 meta/conf/machine/include/arm/feature-arm-vfp.inc  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

-- 
2.5.0

[PATCH 1/1] feature-arm-neon.inc, feature-arm-vfp.inc: fix vfpv4 suffix ordering

[Matt Madison]

Make the feature order in ARMPKGSFX_FPU match that used in
PACKAGE_EXTRA_ARCHS when both neon and vfpv4 are enabled.

Signed-off-by: Matt Madison <matt@madison.systems>
---
 meta/conf/machine/include/arm/feature-arm-neon.inc | 2 +-
 meta/conf/machine/include/arm/feature-arm-vfp.inc  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/conf/machine/include/arm/feature-arm-neon.inc b/meta/conf/machine/include/arm/feature-arm-neon.inc
index e9351f9..f671a53 100644
--- a/meta/conf/machine/include/arm/feature-arm-neon.inc
+++ b/meta/conf/machine/include/arm/feature-arm-neon.inc
@@ -1,3 +1,3 @@
 TUNEVALID[neon] = "Enable Neon SIMD accelerator unit."
 TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'neon', bb.utils.contains('TUNE_FEATURES', 'vfpv4', ' -mfpu=neon-vfpv4', ' -mfpu=neon', d), '' , d)}"
-ARMPKGSFX_FPU .= "${@bb.utils.contains('TUNE_FEATURES', 'neon', '-neon', '', d)}"
+ARMPKGSFX_FPU .= "${@bb.utils.contains('TUNE_FEATURES', 'neon', bb.utils.contains('TUNE_FEATURES', 'vfpv4', '-neon-vfpv4', '-neon', d), '', d)}"
diff --git a/meta/conf/machine/include/arm/feature-arm-vfp.inc b/meta/conf/machine/include/arm/feature-arm-vfp.inc
index e23d377..a1a2c61 100644
--- a/meta/conf/machine/include/arm/feature-arm-vfp.inc
+++ b/meta/conf/machine/include/arm/feature-arm-vfp.inc
@@ -10,7 +10,7 @@ TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'vfpv3', ' -mfpu=vfpv3', '
 ARMPKGSFX_FPU .= "${@bb.utils.contains('TUNE_FEATURES', 'vfpv3', '-vfpv3', '' ,d)}"
 
 TUNEVALID[vfpv4] = "Enable Vector Floating Point Version 4 (vfpv4) unit."
-ARMPKGSFX_FPU .= "${@bb.utils.contains('TUNE_FEATURES', 'vfpv4', '-vfpv4', '' ,d)}"
+ARMPKGSFX_FPU .= "${@bb.utils.contains('TUNE_FEATURES', 'vfpv4', bb.utils.contains('TUNE_FEATURES', 'neon', '', '-vfpv4', d), '' ,d)}"
 
 TUNEVALID[callconvention-hard] = "Enable EABI hard float call convention, requires VFP."
 TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'vfp', bb.utils.contains('TUNE_FEATURES', 'callconvention-hard', ' -mfloat-abi=hard', ' -mfloat-abi=softfp', d), '' ,d)}"
-- 
2.5.0

Re: [PATCH 0/1] ARMPKGSFX_FP ordering

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1267 bytes --]

See:

http://lists.openembedded.org/pipermail/openembedded-core/2015-November/112919.html

I think it fixes the same issue.

On Sun, Dec 6, 2015 at 6:09 PM, Matt Madison <matt@madison.systems> wrote:

> I was trying some multilib ARM builds and ran into an issue.  For
> armv7ahf-neon-vfpv4, PACKAGE_EXTRA_ARCHS is coded as
> "armv7ahf-vfp-neon-vfpv4",
> but the ARMPKGSFX_FPU suffix was getting constructed as "-vfp-vfpv4-neon",
> resulting
> in 32-bit packages not getting found due to the name mismatch.
>
> The following patch fixes this by changing ARMPKGSFX_FPU.  I'm not sure if
> it
> would be more correct to change the PACKAGE_EXTRA_ARCHS settings, but the
> 'neon-vfpv4' more closely aligns to the tune names, so I took this route.
>
> Matt Madison (1):
>   feature-arm-neon.inc, feature-arm-vfp.inc: fix vfpv4 suffix ordering
>
>  meta/conf/machine/include/arm/feature-arm-neon.inc | 2 +-
>  meta/conf/machine/include/arm/feature-arm-vfp.inc  | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> --
> 2.5.0
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

[-- Attachment #2: Type: text/html, Size: 2015 bytes --]

Re: [PATCH 0/1] ARMPKGSFX_FP ordering

[Matt Madison]

On Sun, Dec 6, 2015 at 9:47 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
> See:
>
> http://lists.openembedded.org/pipermail/openembedded-core/2015-November/112919.html
>
> I think it fixes the same issue.

Close, but not quite, I think.  It doesn't look like it addresses the
ordering mismatch that occurs due to the -vfp include being processed
before the -neon include, resulting vfpv4 preceding neon in
ARMPKGSFX_FPU when both are enabled.

Thanks,
-Matt

>
> On Sun, Dec 6, 2015 at 6:09 PM, Matt Madison <matt@madison.systems> wrote:
>>
>> I was trying some multilib ARM builds and ran into an issue.  For
>> armv7ahf-neon-vfpv4, PACKAGE_EXTRA_ARCHS is coded as
>> "armv7ahf-vfp-neon-vfpv4",
>> but the ARMPKGSFX_FPU suffix was getting constructed as "-vfp-vfpv4-neon",
>> resulting
>> in 32-bit packages not getting found due to the name mismatch.
>>
>> The following patch fixes this by changing ARMPKGSFX_FPU.  I'm not sure if
>> it
>> would be more correct to change the PACKAGE_EXTRA_ARCHS settings, but the
>> 'neon-vfpv4' more closely aligns to the tune names, so I took this route.
>>
>> Matt Madison (1):
>>   feature-arm-neon.inc, feature-arm-vfp.inc: fix vfpv4 suffix ordering
>>
>>  meta/conf/machine/include/arm/feature-arm-neon.inc | 2 +-
>>  meta/conf/machine/include/arm/feature-arm-vfp.inc  | 2 +-
>>  2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> --
>> 2.5.0
>>
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>

Re: [PATCH 0/1] ARMPKGSFX_FP ordering

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 443 bytes --]

On 6 December 2015 at 18:22, Matt Madison <matt@madison.systems> wrote:

> Close, but not quite, I think.  It doesn't look like it addresses the
> ordering mismatch that occurs due to the -vfp include being processed
> before the -neon include, resulting vfpv4 preceding neon in
> ARMPKGSFX_FPU when both are enabled.
>

Martin's patch is in my ross/mut branch so will be in master soon, can you
rebase these patches please?

Ross

[-- Attachment #2: Type: text/html, Size: 859 bytes --]

Re: [PATCH 0/1] ARMPKGSFX_FP ordering

[Mark Hatle]

On 12/7/15 8:01 AM, Burton, Ross wrote:
> 
> On 6 December 2015 at 18:22, Matt Madison <matt@madison.systems
> <mailto:matt@madison.systems>> wrote:
> 
>     Close, but not quite, I think.  It doesn't look like it addresses the
>     ordering mismatch that occurs due to the -vfp include being processed
>     before the -neon include, resulting vfpv4 preceding neon in
>     ARMPKGSFX_FPU when both are enabled.
> 
> 
> Martin's patch is in my ross/mut branch so will be in master soon, can you
> rebase these patches please?
> 
> Ross
> 
> 

I would prefer we fix the package extra arch, and leave the ARMPKGSFX_FPU alone.
 I believe that order is correct.

--Mark

Re: [PATCH 0/1] ARMPKGSFX_FP ordering

[Matt Madison]

OK, I'll rework the patch to fix PACKAGE_EXTRA_ARCHS and rebase off
Martin's changes.

-Matt

On Mon, Dec 7, 2015 at 7:17 AM, Mark Hatle <mark.hatle@windriver.com> wrote:
> On 12/7/15 8:01 AM, Burton, Ross wrote:
>>
>> On 6 December 2015 at 18:22, Matt Madison <matt@madison.systems
>> <mailto:matt@madison.systems>> wrote:
>>
>>     Close, but not quite, I think.  It doesn't look like it addresses the
>>     ordering mismatch that occurs due to the -vfp include being processed
>>     before the -neon include, resulting vfpv4 preceding neon in
>>     ARMPKGSFX_FPU when both are enabled.
>>
>>
>> Martin's patch is in my ross/mut branch so will be in master soon, can you
>> rebase these patches please?
>>
>> Ross
>>
>>
>
> I would prefer we fix the package extra arch, and leave the ARMPKGSFX_FPU alone.
>  I believe that order is correct.
>
> --Mark

Re: [PATCH 0/1] ARMPKGSFX_FP ordering

[Matt Madison]

On Mon, Dec 7, 2015 at 7:49 AM, Matt Madison <matt@madison.systems> wrote:
> OK, I'll rework the patch to fix PACKAGE_EXTRA_ARCHS and rebase off
> Martin's changes.

Martin's latest patch series resolved the problem for me with no
additional changes needed.  Thanks, Martin!

>
> -Matt
>
> On Mon, Dec 7, 2015 at 7:17 AM, Mark Hatle <mark.hatle@windriver.com> wrote:
>> On 12/7/15 8:01 AM, Burton, Ross wrote:
>>>
>>> On 6 December 2015 at 18:22, Matt Madison <matt@madison.systems
>>> <mailto:matt@madison.systems>> wrote:
>>>
>>>     Close, but not quite, I think.  It doesn't look like it addresses the
>>>     ordering mismatch that occurs due to the -vfp include being processed
>>>     before the -neon include, resulting vfpv4 preceding neon in
>>>     ARMPKGSFX_FPU when both are enabled.
>>>
>>>
>>> Martin's patch is in my ross/mut branch so will be in master soon, can you
>>> rebase these patches please?
>>>
>>> Ross
>>>
>>>
>>
>> I would prefer we fix the package extra arch, and leave the ARMPKGSFX_FPU alone.
>>  I believe that order is correct.
>>
>> --Mark