[PATCH 2/2] ARM: handle missing thumb suffix

[PATCH 2/2] ARM: handle missing thumb suffix

[Jens Rehsack]

When enabling tune for arm926ejs, poky optionally appends suffixes for
thumb and dsp support. Since sometimes arm926ejse (ARM code) and sometime
arm926ejste (thumb code) is used in PACKAGE_ARCH, allow both.

Signed-off-by: Jens Rehsack <sno@netbsd.org>
---
 meta/conf/machine/include/tune-arm926ejs.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/machine/include/tune-arm926ejs.inc b/meta/conf/machine/include/tune-arm926ejs.inc
index 335e4e0..a310c9d 100644
--- a/meta/conf/machine/include/tune-arm926ejs.inc
+++ b/meta/conf/machine/include/tune-arm926ejs.inc
@@ -8,4 +8,4 @@ TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", " -mtune=arm9
 AVAILTUNES += "arm926ejs"
 ARMPKGARCH_tune-arm926ejs = "arm926ejs"
 TUNE_FEATURES_tune-arm926ejs = "${TUNE_FEATURES_tune-armv5te} arm926ejs"
-PACKAGE_EXTRA_ARCHS_tune-arm926ejs = "${PACKAGE_EXTRA_ARCHS_tune-armv5te} arm926ejste"
+PACKAGE_EXTRA_ARCHS_tune-arm926ejs = "${PACKAGE_EXTRA_ARCHS_tune-armv5te} arm926ejste arm926ejse"
-- 
1.9.1

-- 
Jens Rehsack - rehsack@gmail.com

Re: [PATCH 2/2] ARM: handle missing thumb suffix

[Martin Jansa]

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

On Tue, Oct 13, 2015 at 10:37:47PM +0200, Jens Rehsack wrote:
> 
> When enabling tune for arm926ejs, poky optionally appends suffixes for
> thumb and dsp support. Since sometimes arm926ejse (ARM code) and sometime
> arm926ejste (thumb code) is used in PACKAGE_ARCH, allow both.

LGTM

> 
> Signed-off-by: Jens Rehsack <sno@netbsd.org>
> ---
>  meta/conf/machine/include/tune-arm926ejs.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/conf/machine/include/tune-arm926ejs.inc b/meta/conf/machine/include/tune-arm926ejs.inc
> index 335e4e0..a310c9d 100644
> --- a/meta/conf/machine/include/tune-arm926ejs.inc
> +++ b/meta/conf/machine/include/tune-arm926ejs.inc
> @@ -8,4 +8,4 @@ TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", " -mtune=arm9
>  AVAILTUNES += "arm926ejs"
>  ARMPKGARCH_tune-arm926ejs = "arm926ejs"
>  TUNE_FEATURES_tune-arm926ejs = "${TUNE_FEATURES_tune-armv5te} arm926ejs"
> -PACKAGE_EXTRA_ARCHS_tune-arm926ejs = "${PACKAGE_EXTRA_ARCHS_tune-armv5te} arm926ejste"
> +PACKAGE_EXTRA_ARCHS_tune-arm926ejs = "${PACKAGE_EXTRA_ARCHS_tune-armv5te} arm926ejste arm926ejse"
> -- 
> 1.9.1
> 
> -- 
> Jens Rehsack - rehsack@gmail.com
> 
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

Re: [PATCH 2/2] ARM: handle missing thumb suffix

[Phil Blundell]

On Tue, 2015-10-13 at 22:37 +0200, Jens Rehsack wrote:
> When enabling tune for arm926ejs, poky optionally appends suffixes 
> for thumb and dsp support. Since sometimes arm926ejse (ARM code) and 
> sometime arm926ejste (thumb code) is used in PACKAGE_ARCH, allow 
> both.

It seems like it is a bug for "arm926ejste" ever to be showing up in
PACKAGE_ARCH, and it would be better to fix the packaging code to not
do that.  ARM926EJ-S is a CPU not an architecture.

p.

Re: [PATCH 2/2] ARM: handle missing thumb suffix

[Jens Rehsack]

> Am 15.10.2015 um 12:49 schrieb Phil Blundell <pb@pbcl.net>:
> 
> On Tue, 2015-10-13 at 22:37 +0200, Jens Rehsack wrote:
>> When enabling tune for arm926ejs, poky optionally appends suffixes 
>> for thumb and dsp support. Since sometimes arm926ejse (ARM code) and 
>> sometime arm926ejste (thumb code) is used in PACKAGE_ARCH, allow 
>> both.
> 
> It seems like it is a bug for "arm926ejste" ever to be showing up in
> PACKAGE_ARCH, and it would be better to fix the packaging code to not
> do that.  ARM926EJ-S is a CPU not an architecture.

The CPU is Kirkwood 6281, arm926ej-s is a design, like cortex-a9.

Just to avoid some confusion ;)

Cheers
-- 
Jens Rehsack - rehsack@gmail.com

Re: [PATCH 2/2] ARM: handle missing thumb suffix

[Martin Jansa]

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

On Thu, Oct 15, 2015 at 11:49:52AM +0100, Phil Blundell wrote:
> On Tue, 2015-10-13 at 22:37 +0200, Jens Rehsack wrote:
> > When enabling tune for arm926ejs, poky optionally appends suffixes 
> > for thumb and dsp support. Since sometimes arm926ejse (ARM code) and 
> > sometime arm926ejste (thumb code) is used in PACKAGE_ARCH, allow 
> > both.
> 
> It seems like it is a bug for "arm926ejste" ever to be showing up in
> PACKAGE_ARCH, and it would be better to fix the packaging code to not
> do that.  ARM926EJ-S is a CPU not an architecture.

It's package architecture for binary feeds with -mtune=arm926ejs and it
can be built with or without -mthumb, that's why packages can be built
in arm926ejse or arm926ejste package feed.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

Re: [PATCH 2/2] ARM: handle missing thumb suffix

[Phil Blundell]

On Thu, 2015-10-15 at 13:31 +0200, Martin Jansa wrote:

> It's package architecture for binary feeds with -mtune=arm926ejs and
> it
> can be built with or without -mthumb, that's why packages can be
> built
> in arm926ejse or arm926ejste package feed.

Yes, I understand that.  But the point is that there doesn't seem to be
any good reason to distinguish those two cases by PACKAGE_ARCH, any
more than we use separate PACKAGE_ARCH values for binaries built with 
-O2, or -fpie, or any number of other options.

ARM926EJ-S, by definition, can execute both ARM and Thumb code so there
is no meaningful situation where arm926ejse binaries might be usable
yet arm926ejste ones are not.  

p.

Re: [PATCH 2/2] ARM: handle missing thumb suffix

[Martin Jansa]

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

On Thu, Oct 15, 2015 at 12:51:29PM +0100, Phil Blundell wrote:
> On Thu, 2015-10-15 at 13:31 +0200, Martin Jansa wrote:
> 
> > It's package architecture for binary feeds with -mtune=arm926ejs and
> > it
> > can be built with or without -mthumb, that's why packages can be
> > built
> > in arm926ejse or arm926ejste package feed.
> 
> Yes, I understand that.  But the point is that there doesn't seem to be
> any good reason to distinguish those two cases by PACKAGE_ARCH, any
> more than we use separate PACKAGE_ARCH values for binaries built with 
> -O2, or -fpie, or any number of other options.
> 
> ARM926EJ-S, by definition, can execute both ARM and Thumb code so there
> is no meaningful situation where arm926ejse binaries might be usable
> yet arm926ejste ones are not.  

What about consistency with less specific PACKAGE_ARCHs which use "t" to
show if it was built with or without thumb?

Or more strange case when some DISTRO without PR service enables thumb
and package manager can in theory migrate/upgrade packages from arm926ejse feed
to arm926ejste ones even when the version is the same (doesn't work with
opkg)

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

Re: [PATCH 2/2] ARM: handle missing thumb suffix

[Phil Blundell]

On Thu, 2015-10-15 at 14:09 +0200, Martin Jansa wrote:
> What about consistency with less specific PACKAGE_ARCHs which use "t" 
> to show if it was built with or without thumb?

For the generic architectures, the trailing "t" does serve a useful
purpose.  There exist ARMv5 CPUs that can't run Thumb code (I think
Marvell had some for example) which means it is useful to be able to
draw a distinction between binaries which require Thumb instructions
(armv5t) and those which require only the ARM base instruction set
(armv5).  There are a few places where the support for this in OE is a
bit rough around the edges (it doesn't get armv4 vs armv4t exactly
right) but in general it is close enough and does the right thing in
all the cases that matter.

To turn your question round, what about consistency with more specific
PACKAGE_ARCHs?  We don't use "qemuarmt" or "om-gta01t" for binaries
that happen to be built with Thumb enabled.

p.