[Buildroot] [git commit] arch: pass cpu option instead of tune option on ARM

[Buildroot] [git commit] arch: pass cpu option instead of tune option on ARM

[Thomas Petazzoni]

commit: http://git.buildroot.net/buildroot/commit/?id=d3539dd53bf9e37538fd4d8b89783a11fded119f
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master

Currently, the ARM Config.in logic specifies values for
--with-arch/-march and --with-tune/-mtune, but not for
--with-cpu/-mcpu. However, this causes problems on ARMv4, because
specifying --with-arch=armv4t isn't enough to make gcc generate ARMv4
code: one should also pass --with-cpu=<some ARMv4 CPU>.

Moreover, since Buildroot is generally designed to generate code
specifically for the configured target, it makes sense to give our own
--with-cpu/-mcpu value instead of relying on the default value used by
gcc, and only do small optimizations with -mtune.

Reported-by: Adam Hussein <kryme76@yahoo.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
---
 arch/Config.in.arm |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/Config.in.arm b/arch/Config.in.arm
index c0fabb7..dd58744 100644
--- a/arch/Config.in.arm
+++ b/arch/Config.in.arm
@@ -341,7 +341,7 @@ config BR2_ENDIAN
 	default "LITTLE" if BR2_arm
 	default "BIG"	 if BR2_armeb
 
-config BR2_GCC_TARGET_TUNE
+config BR2_GCC_TARGET_CPU
 	default "arm7tdmi"	if BR2_arm7tdmi
 	default "arm7tdmi"	if BR2_arm720t
 	default "arm7tdmi"	if BR2_arm740t

[Buildroot] [git commit] arch: pass cpu option instead of tune option on ARM

[Jonas Jensen]

Moving from snapshot 20131213 to 20140123 I noticed a warning that
wasn't there before:

"warning: switch -mcpu=fa526 conflicts with -march=armv4 switch
[enabled by default]"

That's where I started digging and found this commit.

In cases where -mcpu is set, buildroot doesn't actually need to set
-march, correct?

I can live with the warning I'm just letting you know. Thanks for
buildroot it's a great tool :)

Best regards,
Jonas

[Buildroot] [git commit] arch: pass cpu option instead of tune option on ARM

[Yann E. MORIN]

Jonas, All,

On 2014-01-23 16:31 +0100, Jonas Jensen spake thusly:
> Moving from snapshot 20131213 to 20140123 I noticed a warning that
> wasn't there before:
> 
> "warning: switch -mcpu=fa526 conflicts with -march=armv4 switch
> [enabled by default]"
> 
> That's where I started digging and found this commit.
> 
> In cases where -mcpu is set, buildroot doesn't actually need to set
> -march, correct?

Can you check you have this commit in your tree:
    2c1dc32: toolchain/external: fix wrapper by not passing conflicting flags

http://git.buildroot.org/buildroot/commit/toolchain/toolchain-external/ext-toolchain-wrapper.c?id=2c1dc32647eb308126b0ae80a91988059d39aa7b

This one should solve your issue.

If not, can you share your .config, so we can try to reproduce?

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] [git commit] arch: pass cpu option instead of tune option on ARM

[Thomas De Schampheleire]

Hi Yann, all,

On Thu, Jan 23, 2014 at 7:15 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> Jonas, All,
>
> On 2014-01-23 16:31 +0100, Jonas Jensen spake thusly:
>> Moving from snapshot 20131213 to 20140123 I noticed a warning that
>> wasn't there before:
>>
>> "warning: switch -mcpu=fa526 conflicts with -march=armv4 switch
>> [enabled by default]"
>>
>> That's where I started digging and found this commit.
>>
>> In cases where -mcpu is set, buildroot doesn't actually need to set
>> -march, correct?
>
> Can you check you have this commit in your tree:
>     2c1dc32: toolchain/external: fix wrapper by not passing conflicting flags
>
> http://git.buildroot.org/buildroot/commit/toolchain/toolchain-external/ext-toolchain-wrapper.c?id=2c1dc32647eb308126b0ae80a91988059d39aa7b
>
> This one should solve your issue.
>

Sorry for bringing up this old issue, but at least some cases are not
yet solved.

The specified commit fixes the issue of the wrapper-specified
mcpu/mtune/march flags vs. the flags specified on the compiler
command-line.
However, the wrapper itself may specify a combination of -mcpu and
-march which also causes warnings such as:
"warning: switch -mcpu=arm1176jz-s conflicts with -march= switch
This is not visible with the ARM big-endian Musl toolchain available
in buildroot, but I can reproduce it with a crosstool-ng toolchain:

echo "int main(void) {}" | BR2_DEBUG_WRAPPER=1
./output/host/usr/bin/armeb-linux-gcc -x c -o /dev/null -
Toolchain wrapper executing:
'/home/tdescham/repo/contrib/buildroot-bugs/output/host/opt/ext-toolchain/bin/armeb-linux-gcc'
'--sysroot' '/home/tdescham/repo/contrib/buildroot-bugs/output/host/usr/armeb-buildroot-linux-gnueabi/sysroot'
'-mabi=aapcs-linux' '-msoft-float' '-marm' '-pipe' '-mfloat-abi=soft'
'-march=armv6zk' '-mcpu=arm1176jz-s' '-x' 'c' '-o' '/dev/null' '-'
<stdin>:1: warning: switch -mcpu=arm1176jz-s conflicts with -march= switch

This crosstool-ng toolchain is a pretty standard gcc-4.4.3-based
toolchain for arm1176jz-6 big-endian.

Another patch was sent to fix this issue:
http://patchwork.ozlabs.org/patch/348364/
by only passing march/mtune if no mcpu is given. I verified that this
patch removes the warning.

However, I don't know if it has undesired side-effects. Any input on
this is very welcome.

Thanks,
Thomas

[Buildroot] support/download/wrapper expects file output in temp directory but support/wrapper/git produces output.gz

[Graham Newton]

Running support/download/wrapper git fails because the final instruction 
of support/download/git gzips the output file creating output.gz which 
wrapper isn't expecting.

Example:

gnewton at ey-debx64-vm01 ~/Working/LinuxBuild $ support/download/wrapper 
git /home/gnewton/Working/LinuxBuild/dl/linux-ti816x_graham_dev.tar.gz 
gitolite at ey-ubsx64-svr02:LinuxKernel ti816x_graham_dev 
linux-ti816x_graham_dev
Doing shallow clone
Cloning into bare repository 'linux-ti816x_graham_dev'...
remote: Counting objects: 48600, done.
remote: Compressing objects: 100% (46466/46466), done.
Receiving objects: 100% (48600/48600), 143.16 MiB | 13.99 MiB/s, done.
remote: Total 48600 (delta 3863), reused 25085 (delta 1546)
Resolving deltas: 100% (3863/3863), done.
Checking connectivity... done.
cat: 
/home/gnewton/Working/LinuxBuild/output/build/.linux-ti816x_graham_dev.tar.gz.MX7pH9/output: 
No such file or directory

Build root pulled from git://git.busybox.net/buildroot master today 
(06/08/2014)

I assume the fix would be to either
i) in wrapper cat output.gz in the case of git
ii) copy output.gz to output after the gzip in support/download/git

[Buildroot] support/download/wrapper expects file output in temp directory but support/wrapper/git produces output.gz

[Yann E. MORIN]

Graham, All,

On 2014-08-06 16:29 +0100, Graham Newton spake thusly:
> Running support/download/wrapper git fails because the final instruction of
> support/download/git gzips the output file creating output.gz which wrapper
> isn't expecting.

Doh... I wonder how I could let this slip through... :-(

> Example:
> 
> gnewton at ey-debx64-vm01 ~/Working/LinuxBuild $ support/download/wrapper git
> /home/gnewton/Working/LinuxBuild/dl/linux-ti816x_graham_dev.tar.gz
> gitolite at ey-ubsx64-svr02:LinuxKernel ti816x_graham_dev
> linux-ti816x_graham_dev
> Doing shallow clone
> Cloning into bare repository 'linux-ti816x_graham_dev'...
> remote: Counting objects: 48600, done.
> remote: Compressing objects: 100% (46466/46466), done.
> Receiving objects: 100% (48600/48600), 143.16 MiB | 13.99 MiB/s, done.
> remote: Total 48600 (delta 3863), reused 25085 (delta 1546)
> Resolving deltas: 100% (3863/3863), done.
> Checking connectivity... done.
> cat: /home/gnewton/Working/LinuxBuild/output/build/.linux-ti816x_graham_dev.tar.gz.MX7pH9/output:
> No such file or directory
> 
> Build root pulled from git://git.busybox.net/buildroot master today
> (06/08/2014)
> 
> I assume the fix would be to either
> i) in wrapper cat output.gz in the case of git
> ii) copy output.gz to output after the gzip in support/download/git

iii)
    git archive >output.tmp
    gzip -c -9 <output.tmp >output

That's what I'm gonna implement.

Thanks for the report!

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] support/download/wrapper expects file output in temp directory but support/wrapper/git produces output.gz

[Thomas De Schampheleire]

On Wed, Aug 6, 2014 at 6:29 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> Graham, All,
>
> On 2014-08-06 16:29 +0100, Graham Newton spake thusly:
>> Running support/download/wrapper git fails because the final instruction of
>> support/download/git gzips the output file creating output.gz which wrapper
>> isn't expecting.
>
> Doh... I wonder how I could let this slip through... :-(

I also should have caught this in my testing. I now understand why
this happened: sources.buildroot.net also contains the tar file of the
package I tried in my testing, and I did not actually verify the build
output. Since the package was downloaded and the contents looked ok, I
assumed the git download wrapper was fine.
Very bad testing on my part, my apologies!

Best regards,
Thomas