[Buildroot] [PATCH 0/4] Fix march/mcpu conflict on ARM

[Buildroot] [PATCH 0/4] Fix march/mcpu conflict on ARM

[Thomas Petazzoni]

Hello,

Here is a set of four patches whose initial aim is to fix the numerous
reports of -mcpu/-march flag conflicts encountered by various users.

The issue is that in arch/Config.in.arm, we specify both a
BR2_GCC_TARGET_CPU value and a BR2_GCC_TARGET_ARCH value for each CPU
core we support. However, not all gcc versions agree on which -march
flag is appropriate for a given -mcpu flag, and then reports annoying
warnings at each file being compiled.

Also, gcc clearly states that passing -mcpu is enough:

  -mcpu=name

  This specifies the name of the target ARM processor. GCC uses this
  name to derive the name of the target ARM architecture (as if
  specified by -march) and the ARM processor type for which to tune
  for performance (as if specified by -mtune).

So there's actually no point in specifying both -mcpu and -march, so
this set of patches removes BR2_GCC_TARGET_ARCH to solve the issue.

Yann, I believe we could revert
2c1dc32647eb308126b0ae80a91988059d39aa7b ("toolchain/external: fix
wrapper by not passing conflicting flags") after merging this patch
series. Do you agree?

Thanks,

Thomas

Thomas Petazzoni (4):
  arch: remove BR2_arm920 reference
  arch: remove BR2_arm10t
  arch: do not distinguish revisions of ARM1136JF-S
  arch: remove BR2_GCC_TARGET_ARCH definitions on ARM

 arch/Config.in.arm | 37 ++-----------------------------------
 1 file changed, 2 insertions(+), 35 deletions(-)

-- 
2.0.0

[Buildroot] [PATCH 1/4] arch: remove BR2_arm920 reference

[Thomas Petazzoni]

The BR2_GCC_TARGET_CPU defines a value for the BR2_arm920 case, but
this option does not exist. Therefore, this commit removes one line of
dead code.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 arch/Config.in.arm | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/Config.in.arm b/arch/Config.in.arm
index e404a50..5ae2378 100644
--- a/arch/Config.in.arm
+++ b/arch/Config.in.arm
@@ -344,7 +344,6 @@ config BR2_ARCH_HAS_ATOMICS
 	default y
 
 config BR2_GCC_TARGET_CPU
-	default "arm920"	if BR2_arm920
 	default "arm920t"	if BR2_arm920t
 	default "arm922t"	if BR2_arm922t
 	default "arm926ej-s"	if BR2_arm926t
-- 
2.0.0

[Buildroot] [PATCH 1/4] arch: remove BR2_arm920 reference

[Yann E. MORIN]

Thomas, All,

On 2014-09-15 23:01 +0200, Thomas Petazzoni spake thusly:
> The BR2_GCC_TARGET_CPU defines a value for the BR2_arm920 case, but
> this option does not exist. Therefore, this commit removes one line of
> dead code.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Obviously:

Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

Regards,
Yann E. MORIN.

> ---
>  arch/Config.in.arm | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/Config.in.arm b/arch/Config.in.arm
> index e404a50..5ae2378 100644
> --- a/arch/Config.in.arm
> +++ b/arch/Config.in.arm
> @@ -344,7 +344,6 @@ config BR2_ARCH_HAS_ATOMICS
>  	default y
>  
>  config BR2_GCC_TARGET_CPU
> -	default "arm920"	if BR2_arm920
>  	default "arm920t"	if BR2_arm920t
>  	default "arm922t"	if BR2_arm922t
>  	default "arm926ej-s"	if BR2_arm926t
> -- 
> 2.0.0
> 

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 1/4] arch: remove BR2_arm920 reference

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 > The BR2_GCC_TARGET_CPU defines a value for the BR2_arm920 case, but
 > this option does not exist. Therefore, this commit removes one line of
 > dead code.

 > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Committed, thanks.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 2/4] arch: remove BR2_arm10t

[Thomas Petazzoni]

The BR2_arm10t option is not correct as it references an ARM family,
while other options indicate a specific ARM core. The ARM cores in
ARM10 family are ARM1020E, ARM1022E and ARM1026EJ-S according to
Wikipedia. However, those are clearly very rare, and Wikipedia also
indicates two Conexant ADSL-related SoC as being part of this family
of ARM cores. Therefore, this commit removes this ARM family.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 arch/Config.in.arm | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/arch/Config.in.arm b/arch/Config.in.arm
index 5ae2378..201ff1d 100644
--- a/arch/Config.in.arm
+++ b/arch/Config.in.arm
@@ -54,9 +54,6 @@ config BR2_arm926t
 	bool "arm926t"
 	select BR2_ARM_CPU_MAYBE_HAS_VFPV2
 	select BR2_ARM_CPU_HAS_THUMB
-config BR2_arm10t
-	bool "arm10t"
-	select BR2_ARM_CPU_HAS_THUMB
 config BR2_arm1136jf_s_r0
 	bool "arm1136jf_s rev0"
 	select BR2_ARM_CPU_HAS_VFPV2
@@ -367,7 +364,6 @@ config BR2_GCC_TARGET_ARCH
 	default "armv4t"	if BR2_arm920t
 	default "armv4t"	if BR2_arm922t
 	default "armv5te"	if BR2_arm926t
-	default "armv5t"	if BR2_arm10t
 	default "armv6j"	if BR2_arm1136jf_s_r0
 	default "armv6k"	if BR2_arm1136jf_s_r1
 	default "armv6zk"	if BR2_arm1176jz_s
-- 
2.0.0

[Buildroot] [PATCH 2/4] arch: remove BR2_arm10t

[Yann E. MORIN]

Thomas, All,

On 2014-09-15 23:01 +0200, Thomas Petazzoni spake thusly:
> The BR2_arm10t option is not correct as it references an ARM family,
> while other options indicate a specific ARM core. The ARM cores in
> ARM10 family are ARM1020E, ARM1022E and ARM1026EJ-S according to
> Wikipedia. However, those are clearly very rare, and Wikipedia also
> indicates two Conexant ADSL-related SoC as being part of this family
> of ARM cores. Therefore, this commit removes this ARM family.

You forgot the reference to BR2_arm10t we have in nettle.mk

Regards,
Yann E. MORIN.

> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
>  arch/Config.in.arm | 4 ----
>  1 file changed, 4 deletions(-)
> 
> diff --git a/arch/Config.in.arm b/arch/Config.in.arm
> index 5ae2378..201ff1d 100644
> --- a/arch/Config.in.arm
> +++ b/arch/Config.in.arm
> @@ -54,9 +54,6 @@ config BR2_arm926t
>  	bool "arm926t"
>  	select BR2_ARM_CPU_MAYBE_HAS_VFPV2
>  	select BR2_ARM_CPU_HAS_THUMB
> -config BR2_arm10t
> -	bool "arm10t"
> -	select BR2_ARM_CPU_HAS_THUMB
>  config BR2_arm1136jf_s_r0
>  	bool "arm1136jf_s rev0"
>  	select BR2_ARM_CPU_HAS_VFPV2
> @@ -367,7 +364,6 @@ config BR2_GCC_TARGET_ARCH
>  	default "armv4t"	if BR2_arm920t
>  	default "armv4t"	if BR2_arm922t
>  	default "armv5te"	if BR2_arm926t
> -	default "armv5t"	if BR2_arm10t
>  	default "armv6j"	if BR2_arm1136jf_s_r0
>  	default "armv6k"	if BR2_arm1136jf_s_r1
>  	default "armv6zk"	if BR2_arm1176jz_s
> -- 
> 2.0.0
> 

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 2/4] arch: remove BR2_arm10t

[Thomas Petazzoni]

Dear Yann E. MORIN,

On Mon, 15 Sep 2014 23:13:55 +0200, Yann E. MORIN wrote:
> Thomas, All,
> 
> On 2014-09-15 23:01 +0200, Thomas Petazzoni spake thusly:
> > The BR2_arm10t option is not correct as it references an ARM family,
> > while other options indicate a specific ARM core. The ARM cores in
> > ARM10 family are ARM1020E, ARM1022E and ARM1026EJ-S according to
> > Wikipedia. However, those are clearly very rare, and Wikipedia also
> > indicates two Conexant ADSL-related SoC as being part of this family
> > of ARM cores. Therefore, this commit removes this ARM family.
> 
> You forgot the reference to BR2_arm10t we have in nettle.mk

Gah, indeed, will fix and resend.

Also, in the commit log: s/Wikipedia also/Wikipedia only/.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 2/4] arch: remove BR2_arm10t

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 > The BR2_arm10t option is not correct as it references an ARM family,
 > while other options indicate a specific ARM core. The ARM cores in
 > ARM10 family are ARM1020E, ARM1022E and ARM1026EJ-S according to
 > Wikipedia. However, those are clearly very rare, and Wikipedia also
 > indicates two Conexant ADSL-related SoC as being part of this family
 > of ARM cores. Therefore, this commit removes this ARM family.

 > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Committed with the reference in nettle.mk removed / commit message
tweaked, thanks.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 3/4] arch: do not distinguish revisions of ARM1136JF-S

[Thomas Petazzoni]

In commit 88cf3bb91792c9c04586e14f293d89a6e0c13e1d
("arch/Config.in.arm: Use armv6k for arm1136jf-s rev1"), Beno?t
Th?baudeau added separate options for the revision 0 and revision 1 of
the ARM1136JF-S processor, so that different -march values could be
used (armv6j for revision 0, armv6k for revision 1).

However, this is preventing the removal of the BR2_GCC_TARGET_ARCH
option, which we need to do to give only the CPU type to gcc, and let
it decide the architecture variant that matches. This is because this
story of revision 0 vs. revision 1 is the only case where -mcpu
doesn't fully define the CPU.

Moreover, a quick test with gcc shows that -march=armv6j
-mcpu=arm1136jf-s is accepted, while -march=armv6k -mcpu=arm1136jf-s
makes gcc complain: " warning: switch -mcpu=arm1136jf-s conflicts with
-march=armv6k switch".

In addition, gcc 5 will apparently no longer allow to pass all of
--with-arch, --with-cpu and --with-tune, so we will anyway have to
rely only on one of them.

As a consequence, this commit basically reverts
88cf3bb91792c9c04586e14f293d89a6e0c13e1d and provides only one option
for ARM1136JF-S. If the two revisions are really different, then they
should be supported in upstream gcc with different -mcpu values.

Note that the removal of the two options should not break existing
full .config, since the hidden option BR2_arm1136jf_s becomes again a
visible option to select the CPU.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Beno?t Th?baudeau <benoit.thebaudeau@advansee.com>
---
 arch/Config.in.arm | 15 +++------------
 1 file changed, 3 insertions(+), 12 deletions(-)

diff --git a/arch/Config.in.arm b/arch/Config.in.arm
index 201ff1d..6e3c4e6 100644
--- a/arch/Config.in.arm
+++ b/arch/Config.in.arm
@@ -54,12 +54,8 @@ config BR2_arm926t
 	bool "arm926t"
 	select BR2_ARM_CPU_MAYBE_HAS_VFPV2
 	select BR2_ARM_CPU_HAS_THUMB
-config BR2_arm1136jf_s_r0
-	bool "arm1136jf_s rev0"
-	select BR2_ARM_CPU_HAS_VFPV2
-	select BR2_ARM_CPU_HAS_THUMB
-config BR2_arm1136jf_s_r1
-	bool "arm1136jf_s rev1"
+config BR2_arm1136jf_s
+	bool "arm1136jf-s"
 	select BR2_ARM_CPU_HAS_VFPV2
 	select BR2_ARM_CPU_HAS_THUMB
 config BR2_arm1176jz_s
@@ -113,10 +109,6 @@ config BR2_iwmmxt
 	bool "iwmmxt"
 endchoice
 
-config BR2_arm1136jf_s
-	bool
-	default BR2_arm1136jf_s_r0 || BR2_arm1136jf_s_r1
-
 choice
 	prompt "Target ABI"
 	depends on BR2_arm || BR2_armeb
@@ -364,8 +356,7 @@ config BR2_GCC_TARGET_ARCH
 	default "armv4t"	if BR2_arm920t
 	default "armv4t"	if BR2_arm922t
 	default "armv5te"	if BR2_arm926t
-	default "armv6j"	if BR2_arm1136jf_s_r0
-	default "armv6k"	if BR2_arm1136jf_s_r1
+	default "armv6j"	if BR2_arm1136jf_s
 	default "armv6zk"	if BR2_arm1176jz_s
 	default "armv6zk"	if BR2_arm1176jzf_s
 	default "armv7-a"	if BR2_cortex_a5
-- 
2.0.0

[Buildroot] [PATCH 3/4] arch: do not distinguish revisions of ARM1136JF-S

[Benoît Thébaudeau]

Hi Thomas,

On Mon, Sep 15, 2014 at 11:01 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> In commit 88cf3bb91792c9c04586e14f293d89a6e0c13e1d
> ("arch/Config.in.arm: Use armv6k for arm1136jf-s rev1"), Beno?t
> Th?baudeau added separate options for the revision 0 and revision 1 of
> the ARM1136JF-S processor, so that different -march values could be
> used (armv6j for revision 0, armv6k for revision 1).
>
> However, this is preventing the removal of the BR2_GCC_TARGET_ARCH
> option, which we need to do to give only the CPU type to gcc, and let
> it decide the architecture variant that matches. This is because this
> story of revision 0 vs. revision 1 is the only case where -mcpu
> doesn't fully define the CPU.
>
> Moreover, a quick test with gcc shows that -march=armv6j
> -mcpu=arm1136jf-s is accepted, while -march=armv6k -mcpu=arm1136jf-s
> makes gcc complain: " warning: switch -mcpu=arm1136jf-s conflicts with
> -march=armv6k switch".

Yes, because -mcpu=arm1136jf-s implies -march=armv6j. But how about
keeping -march and -mtune, and removing -mcpu, instead of the
contrary? This would give more flexibility, and full control over the
CPU optimization.

> In addition, gcc 5 will apparently no longer allow to pass all of
> --with-arch, --with-cpu and --with-tune, so we will anyway have to
> rely only on one of them.

What combinations will no longer be supported? Only -mcpu with -march
and -mtune?

[...]

Best regards,
Beno?t

[Buildroot] [PATCH 3/4] arch: do not distinguish revisions of ARM1136JF-S

[Yann E. MORIN]

On 2014-09-15 23:01 +0200, Thomas Petazzoni spake thusly:
> In commit 88cf3bb91792c9c04586e14f293d89a6e0c13e1d
> ("arch/Config.in.arm: Use armv6k for arm1136jf-s rev1"), Beno?t
> Th?baudeau added separate options for the revision 0 and revision 1 of
> the ARM1136JF-S processor, so that different -march values could be
> used (armv6j for revision 0, armv6k for revision 1).
> 
> However, this is preventing the removal of the BR2_GCC_TARGET_ARCH
> option, which we need to do to give only the CPU type to gcc, and let
> it decide the architecture variant that matches. This is because this
> story of revision 0 vs. revision 1 is the only case where -mcpu
> doesn't fully define the CPU.
> 
> Moreover, a quick test with gcc shows that -march=armv6j
> -mcpu=arm1136jf-s is accepted, while -march=armv6k -mcpu=arm1136jf-s
> makes gcc complain: " warning: switch -mcpu=arm1136jf-s conflicts with
> -march=armv6k switch".
> 
> In addition, gcc 5 will apparently no longer allow to pass all of
> --with-arch, --with-cpu and --with-tune, so we will anyway have to
> rely only on one of them.
> 
> As a consequence, this commit basically reverts
> 88cf3bb91792c9c04586e14f293d89a6e0c13e1d and provides only one option
> for ARM1136JF-S. If the two revisions are really different, then they
> should be supported in upstream gcc with different -mcpu values.
> 
> Note that the removal of the two options should not break existing
> full .config, since the hidden option BR2_arm1136jf_s becomes again a
> visible option to select the CPU.

But it would break a defconfig.

As suggested on IRC, move the BR2_arm1136jf_s_r1 to Config.legacy, and
have it select BR2_arm1136jf_s, so the user can re-use a defconfig.

Regards,
Yann E. MORIN.

> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: Beno?t Th?baudeau <benoit.thebaudeau@advansee.com>
> ---
>  arch/Config.in.arm | 15 +++------------
>  1 file changed, 3 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/Config.in.arm b/arch/Config.in.arm
> index 201ff1d..6e3c4e6 100644
> --- a/arch/Config.in.arm
> +++ b/arch/Config.in.arm
> @@ -54,12 +54,8 @@ config BR2_arm926t
>  	bool "arm926t"
>  	select BR2_ARM_CPU_MAYBE_HAS_VFPV2
>  	select BR2_ARM_CPU_HAS_THUMB
> -config BR2_arm1136jf_s_r0
> -	bool "arm1136jf_s rev0"
> -	select BR2_ARM_CPU_HAS_VFPV2
> -	select BR2_ARM_CPU_HAS_THUMB
> -config BR2_arm1136jf_s_r1
> -	bool "arm1136jf_s rev1"
> +config BR2_arm1136jf_s
> +	bool "arm1136jf-s"
>  	select BR2_ARM_CPU_HAS_VFPV2
>  	select BR2_ARM_CPU_HAS_THUMB
>  config BR2_arm1176jz_s
> @@ -113,10 +109,6 @@ config BR2_iwmmxt
>  	bool "iwmmxt"
>  endchoice
>  
> -config BR2_arm1136jf_s
> -	bool
> -	default BR2_arm1136jf_s_r0 || BR2_arm1136jf_s_r1
> -
>  choice
>  	prompt "Target ABI"
>  	depends on BR2_arm || BR2_armeb
> @@ -364,8 +356,7 @@ config BR2_GCC_TARGET_ARCH
>  	default "armv4t"	if BR2_arm920t
>  	default "armv4t"	if BR2_arm922t
>  	default "armv5te"	if BR2_arm926t
> -	default "armv6j"	if BR2_arm1136jf_s_r0
> -	default "armv6k"	if BR2_arm1136jf_s_r1
> +	default "armv6j"	if BR2_arm1136jf_s
>  	default "armv6zk"	if BR2_arm1176jz_s
>  	default "armv6zk"	if BR2_arm1176jzf_s
>  	default "armv7-a"	if BR2_cortex_a5
> -- 
> 2.0.0
> 

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 3/4] arch: do not distinguish revisions of ARM1136JF-S

[Thomas Petazzoni]

Dear Yann E. MORIN,

On Mon, 15 Sep 2014 23:33:39 +0200, Yann E. MORIN wrote:

> > Note that the removal of the two options should not break existing
> > full .config, since the hidden option BR2_arm1136jf_s becomes again a
> > visible option to select the CPU.
> 
> But it would break a defconfig.

Right. But I believe that when we change the default value of an
option, we also break a defconfig, and we don't include that as part of
the Config.in.legacy handling (but also because it's obviously more
complicated).

> As suggested on IRC, move the BR2_arm1136jf_s_r1 to Config.legacy, and
> have it select BR2_arm1136jf_s, so the user can re-use a defconfig.

Hum, why just BR2_arm1136jf_s_r1 and not BR2_arm1136jf_s_r0 ?

Thanks for the review!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 3/4] arch: do not distinguish revisions of ARM1136JF-S

[Benoît Thébaudeau]

Dear Thomas Petazzoni,

On Mon, Sep 15, 2014 at 11:39 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Yann E. MORIN,
>
> On Mon, 15 Sep 2014 23:33:39 +0200, Yann E. MORIN wrote:
>
>> > Note that the removal of the two options should not break existing
>> > full .config, since the hidden option BR2_arm1136jf_s becomes again a
>> > visible option to select the CPU.
>>
>> But it would break a defconfig.
>
> Right. But I believe that when we change the default value of an
> option, we also break a defconfig, and we don't include that as part of
> the Config.in.legacy handling (but also because it's obviously more
> complicated).
>
>> As suggested on IRC, move the BR2_arm1136jf_s_r1 to Config.legacy, and
>> have it select BR2_arm1136jf_s, so the user can re-use a defconfig.
>
> Hum, why just BR2_arm1136jf_s_r1 and not BR2_arm1136jf_s_r0 ?

This issue disappears if -march and -mtune are kept and -mcpu removed
as I suggested.

Regards,
Beno?t

[Buildroot] [PATCH 3/4] arch: do not distinguish revisions of ARM1136JF-S

[Thomas Petazzoni]

Dear Beno?t Th?baudeau,

On Mon, 15 Sep 2014 23:44:52 +0200, Beno?t Th?baudeau wrote:

> >> As suggested on IRC, move the BR2_arm1136jf_s_r1 to Config.legacy, and
> >> have it select BR2_arm1136jf_s, so the user can re-use a defconfig.
> >
> > Hum, why just BR2_arm1136jf_s_r1 and not BR2_arm1136jf_s_r0 ?
> 
> This issue disappears if -march and -mtune are kept and -mcpu removed
> as I suggested.

Do you have an example C code that doesn't generate the same assembly
code between BR2_arm1136jf_s_r0 and BR2_arm1136jf_s_r1 ? It would be
useful for my testing.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 3/4] arch: do not distinguish revisions of ARM1136JF-S

[Benoît Thébaudeau]

Dear Thomas Petazzoni,

On Mon, Sep 15, 2014 at 11:50 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Beno?t Th?baudeau,
>
> On Mon, 15 Sep 2014 23:44:52 +0200, Beno?t Th?baudeau wrote:
>
>> >> As suggested on IRC, move the BR2_arm1136jf_s_r1 to Config.legacy, and
>> >> have it select BR2_arm1136jf_s, so the user can re-use a defconfig.
>> >
>> > Hum, why just BR2_arm1136jf_s_r1 and not BR2_arm1136jf_s_r0 ?
>>
>> This issue disappears if -march and -mtune are kept and -mcpu removed
>> as I suggested.
>
> Do you have an example C code that doesn't generate the same assembly
> code between BR2_arm1136jf_s_r0 and BR2_arm1136jf_s_r1 ? It would be
> useful for my testing.

The instructions supported by armv6k but not by armv6j are:
ldrex{h|b|d}, strex{h|b|d}, clrex, nop, sev, wfe, wfi and yield. This
is especially useful for handwritten assembler implementations (in .S,
or inline in .c) of some OS functions, typically atomic operations and
context switches.

Beno?t

[Buildroot] [PATCH 3/4] arch: do not distinguish revisions of ARM1136JF-S

[Yann E. MORIN]

Beno?t, Thomas, All,

On 2014-09-15 23:44 +0200, Beno?t Th?baudeau spake thusly:
> On Mon, Sep 15, 2014 at 11:39 PM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> > Dear Yann E. MORIN,
> >
> > On Mon, 15 Sep 2014 23:33:39 +0200, Yann E. MORIN wrote:
> >
> >> > Note that the removal of the two options should not break existing
> >> > full .config, since the hidden option BR2_arm1136jf_s becomes again a
> >> > visible option to select the CPU.
> >>
> >> But it would break a defconfig.
> >
> > Right. But I believe that when we change the default value of an
> > option, we also break a defconfig, and we don't include that as part of
> > the Config.in.legacy handling (but also because it's obviously more
> > complicated).
> >
> >> As suggested on IRC, move the BR2_arm1136jf_s_r1 to Config.legacy, and
> >> have it select BR2_arm1136jf_s, so the user can re-use a defconfig.
> >
> > Hum, why just BR2_arm1136jf_s_r1 and not BR2_arm1136jf_s_r0 ?
> 
> This issue disappears if -march and -mtune are kept and -mcpu removed
> as I suggested.

So, maybe we need something like this:

    https://gist.github.com/aeruder/341565b759822b352dd9

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 3/4] arch: do not distinguish revisions of ARM1136JF-S

[Benoît Thébaudeau]

Dear Yann E. MORIN,

On Tue, Sep 16, 2014 at 12:02 AM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> Beno?t, Thomas, All,
>
> On 2014-09-15 23:44 +0200, Beno?t Th?baudeau spake thusly:
>> On Mon, Sep 15, 2014 at 11:39 PM, Thomas Petazzoni
>> <thomas.petazzoni@free-electrons.com> wrote:
>> > Dear Yann E. MORIN,
>> >
>> > On Mon, 15 Sep 2014 23:33:39 +0200, Yann E. MORIN wrote:
>> >
>> >> > Note that the removal of the two options should not break existing
>> >> > full .config, since the hidden option BR2_arm1136jf_s becomes again a
>> >> > visible option to select the CPU.
>> >>
>> >> But it would break a defconfig.
>> >
>> > Right. But I believe that when we change the default value of an
>> > option, we also break a defconfig, and we don't include that as part of
>> > the Config.in.legacy handling (but also because it's obviously more
>> > complicated).
>> >
>> >> As suggested on IRC, move the BR2_arm1136jf_s_r1 to Config.legacy, and
>> >> have it select BR2_arm1136jf_s, so the user can re-use a defconfig.
>> >
>> > Hum, why just BR2_arm1136jf_s_r1 and not BR2_arm1136jf_s_r0 ?
>>
>> This issue disappears if -march and -mtune are kept and -mcpu removed
>> as I suggested.
>
> So, maybe we need something like this:
>
>     https://gist.github.com/aeruder/341565b759822b352dd9

Exactly.

Regards,
Beno?t

[Buildroot] [PATCH 3/4] arch: do not distinguish revisions of ARM1136JF-S

[Yann E. MORIN]

Thomas, All,

On 2014-09-15 23:39 +0200, Thomas Petazzoni spake thusly:
> On Mon, 15 Sep 2014 23:33:39 +0200, Yann E. MORIN wrote:
> > > Note that the removal of the two options should not break existing
> > > full .config, since the hidden option BR2_arm1136jf_s becomes again a
> > > visible option to select the CPU.
> > 
> > But it would break a defconfig.
> 
> Right. But I believe that when we change the default value of an
> option, we also break a defconfig, and we don't include that as part of
> the Config.in.legacy handling (but also because it's obviously more
> complicated).
> 
> > As suggested on IRC, move the BR2_arm1136jf_s_r1 to Config.legacy, and
> > have it select BR2_arm1136jf_s, so the user can re-use a defconfig.
> 
> Hum, why just BR2_arm1136jf_s_r1 and not BR2_arm1136jf_s_r0 ?

Yes, of course.

I re-did my mental flow, and not having _r0 in legacy does not fly.
We need both in legacy, indeed.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 4/4] arch: remove BR2_GCC_TARGET_ARCH definitions on ARM

[Thomas Petazzoni]

On ARM, we were defining both the CPU type and the architecture
variant. However, depending on the version of gcc, a given combination
of (CPU, architecture) may not be the same. Since the architecture
variant is implied by the CPU type, given the former is not necessary,
and we can simply specify the latter.

From the gcc documentation:

  This specifies the name of the target ARM processor. GCC uses this
  name to derive the name of the target ARM architecture (as if
  specified by -march) and the ARM processor type for which to tune
  for performance (as if specified by -mtune). Where this option is
  used in conjunction with -march or -mtune, those options take
  precedence over the appropriate part of this option.

Note that we verified that for all BR2_GCC_TARGET_ARCH value that
existed, a proper BR2_GCC_TARGET_CPU value is defined.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 arch/Config.in.arm | 19 -------------------
 1 file changed, 19 deletions(-)

diff --git a/arch/Config.in.arm b/arch/Config.in.arm
index 6e3c4e6..68f6370 100644
--- a/arch/Config.in.arm
+++ b/arch/Config.in.arm
@@ -352,25 +352,6 @@ config BR2_GCC_TARGET_CPU
 	default "xscale"	if BR2_xscale
 	default "iwmmxt"	if BR2_iwmmxt
 
-config BR2_GCC_TARGET_ARCH
-	default "armv4t"	if BR2_arm920t
-	default "armv4t"	if BR2_arm922t
-	default "armv5te"	if BR2_arm926t
-	default "armv6j"	if BR2_arm1136jf_s
-	default "armv6zk"	if BR2_arm1176jz_s
-	default "armv6zk"	if BR2_arm1176jzf_s
-	default "armv7-a"	if BR2_cortex_a5
-	default "armv7-a"	if BR2_cortex_a7
-	default "armv7-a"	if BR2_cortex_a8
-	default "armv7-a"	if BR2_cortex_a9
-	default "armv7-a"	if BR2_cortex_a12
-	default "armv7-a"	if BR2_cortex_a15
-	default "armv4"		if BR2_fa526
-	default "armv7-a"	if BR2_pj4
-	default "armv4"		if BR2_strongarm
-	default "armv5te"	if BR2_xscale
-	default "iwmmxt"	if BR2_iwmmxt
-
 config BR2_GCC_TARGET_ABI
 	default "aapcs-linux"
 
-- 
2.0.0

[Buildroot] [PATCH 4/4] arch: remove BR2_GCC_TARGET_ARCH definitions on ARM

[Yann E. MORIN]

Thomas, All,

On 2014-09-15 23:01 +0200, Thomas Petazzoni spake thusly:
> On ARM, we were defining both the CPU type and the architecture
> variant. However, depending on the version of gcc, a given combination
> of (CPU, architecture) may not be the same. Since the architecture
> variant is implied by the CPU type, given the former is not necessary,
> and we can simply specify the latter.
> 
> From the gcc documentation:
> 
>   This specifies the name of the target ARM processor. GCC uses this
>   name to derive the name of the target ARM architecture (as if
>   specified by -march) and the ARM processor type for which to tune
>   for performance (as if specified by -mtune). Where this option is
>   used in conjunction with -march or -mtune, those options take
>   precedence over the appropriate part of this option.
> 
> Note that we verified that for all BR2_GCC_TARGET_ARCH value that
> existed, a proper BR2_GCC_TARGET_CPU value is defined.

I guess we'll keep this one in limbo until we have a final answer on
switching from -mcpu to -mtune for ARM.

Regards,
Yann E. MORIN.

> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
>  arch/Config.in.arm | 19 -------------------
>  1 file changed, 19 deletions(-)
> 
> diff --git a/arch/Config.in.arm b/arch/Config.in.arm
> index 6e3c4e6..68f6370 100644
> --- a/arch/Config.in.arm
> +++ b/arch/Config.in.arm
> @@ -352,25 +352,6 @@ config BR2_GCC_TARGET_CPU
>  	default "xscale"	if BR2_xscale
>  	default "iwmmxt"	if BR2_iwmmxt
>  
> -config BR2_GCC_TARGET_ARCH
> -	default "armv4t"	if BR2_arm920t
> -	default "armv4t"	if BR2_arm922t
> -	default "armv5te"	if BR2_arm926t
> -	default "armv6j"	if BR2_arm1136jf_s
> -	default "armv6zk"	if BR2_arm1176jz_s
> -	default "armv6zk"	if BR2_arm1176jzf_s
> -	default "armv7-a"	if BR2_cortex_a5
> -	default "armv7-a"	if BR2_cortex_a7
> -	default "armv7-a"	if BR2_cortex_a8
> -	default "armv7-a"	if BR2_cortex_a9
> -	default "armv7-a"	if BR2_cortex_a12
> -	default "armv7-a"	if BR2_cortex_a15
> -	default "armv4"		if BR2_fa526
> -	default "armv7-a"	if BR2_pj4
> -	default "armv4"		if BR2_strongarm
> -	default "armv5te"	if BR2_xscale
> -	default "iwmmxt"	if BR2_iwmmxt
> -
>  config BR2_GCC_TARGET_ABI
>  	default "aapcs-linux"
>  
> -- 
> 2.0.0
> 

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'