public inbox for linux-arm-kernel@lists.infradead.org 
 help / color / mirror / Atom feed
From: blogic@openwrt•org (John Crispin)
To: linux-arm-kernel@lists•infradead.org
Subject: [OpenWrt-Devel] ARMv4 (not v4t) marked obsolete in gcc-6
Date: Tue, 15 Mar 2016 18:01:26 +0100	[thread overview]
Message-ID: <56E83FE6.7040506@openwrt.org> (raw)
In-Reply-To: <16727306.4g6uRjH7LT@wuerfel>



On 15/03/2016 16:59, Arnd Bergmann wrote:
> On Friday 11 March 2016 17:56:12 Hans Ulli Kroll wrote:
>> On Fri, 11 Mar 2016, Roman Yeryomin wrote:
>>> On 2016-03-11 08:48, John Crispin wrote:
>>>> On 11/03/2016 06:44, Hans Ulli Kroll wrote:
> 
>>> As to the numbers I think that people like me (or others trying out OpenWrt)
>>> usually don't go to the forums, so number of questions there doesn't tell much
>>> (but even there latest messages are from last month, so not dead at all).
>>> Maybe number of downloads from downloads.openwrt.org can tell more but I would
>>> guess that actual users would rather compile it themselves.
>>
>> The support thread on the german board is very long, so most of the 
>> questions are answered there. The experienced don't need this, so the 
>> numbers *are* wrong.
>>
>> And I'm using two of the NAS boxes for backup and another for kernel work
>>
>>> So I vote for not killing it at least until it's supported by kernel.
>>>
>>
>> ACK !!
> 
> Thanks everyone for the input. So if OpenWRT wants to keep the support
> for the Gemini platform, I see two ways forward:
> 
> - have a separate toolchain for target/linux/gemini when the other
>   platforms upgrade to gcc-7. That means no action needed for now,
>   but possibly more work to keep it going in the long run
> 
> - make the upstream kernel work with compilers that lack -march=armv4
>   support.
> 
> I think we want the second one if at all possible, as it also addresses
> most of the other affected platforms (not rpc, which requires -march=armv3).
> 

yes please option 2 would be favorable as we try to keep the amount of
toolchains to a minimum.
	
	John

> The patch below might be enough, passing -march=armv4t whenever -march=armv4
> is not supported, and passing --fix-v4bx whenever we build for ARMv4:
> 
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index 9fb3fee0e908..3c312d37a83a 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -19,6 +19,11 @@ LDFLAGS_vmlinux	+= --be8
>  LDFLAGS_MODULE	+= --be8
>  endif
>  
> +ifeq ($(CONFIG_CPU_32v4),y)
> +LDFLAGS_vmlinux	+= $(call ld-option,--fix-v4bx)
> +LDFLAGS_MODULE	+= $(call ld-option,--fix-v4bx)
> +endif
> +
>  ifeq ($(CONFIG_ARM_MODULE_PLTS),y)
>  LDFLAGS_MODULE	+= -T $(srctree)/arch/arm/kernel/module.lds
>  endif
> @@ -75,7 +80,7 @@ arch-$(CONFIG_CPU_32v6K)	=-D__LINUX_ARM_ARCH__=6 $(call cc-option,-march=armv6k,
>  endif
>  arch-$(CONFIG_CPU_32v5)		=-D__LINUX_ARM_ARCH__=5 $(call cc-option,-march=armv5te,-march=armv4t)
>  arch-$(CONFIG_CPU_32v4T)	=-D__LINUX_ARM_ARCH__=4 -march=armv4t
> -arch-$(CONFIG_CPU_32v4)		=-D__LINUX_ARM_ARCH__=4 -march=armv4
> +arch-$(CONFIG_CPU_32v4)		=-D__LINUX_ARM_ARCH__=4 $(call cc-option,-march=armv4,-march=armv4t)
>  arch-$(CONFIG_CPU_32v3)		=-D__LINUX_ARM_ARCH__=3 -march=armv3
>  
>  # Evaluate arch cc-option calls now
> @@ -93,8 +98,8 @@ tune-$(CONFIG_CPU_ARM922T)	=-mtune=arm9tdmi
>  tune-$(CONFIG_CPU_ARM925T)	=-mtune=arm9tdmi
>  tune-$(CONFIG_CPU_ARM926T)	=-mtune=arm9tdmi
>  tune-$(CONFIG_CPU_FA526)	=-mtune=arm9tdmi
> -tune-$(CONFIG_CPU_SA110)	=-mtune=strongarm110
> -tune-$(CONFIG_CPU_SA1100)	=-mtune=strongarm1100
> +tune-$(CONFIG_CPU_SA110)	=$(call cc-option,-mtune=strongarm110)
> +tune-$(CONFIG_CPU_SA1100)	=$(call cc-option,-mtune=strongarm1100)
>  tune-$(CONFIG_CPU_XSCALE)	=$(call cc-option,-mtune=xscale,-mtune=strongarm110) -Wa,-mcpu=xscale
>  tune-$(CONFIG_CPU_XSC3)		=$(call cc-option,-mtune=xscale,-mtune=strongarm110) -Wa,-mcpu=xscale
>  tune-$(CONFIG_CPU_FEROCEON)	=$(call cc-option,-mtune=marvell-f,-mtune=xscale)
> 
> Does this look reasonable?
> 
> 	Arnd
> 

  reply	other threads:[~2016-03-15 17:01 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-10  9:13 ARMv4 (not v4t) marked obsolete in gcc-6 Arnd Bergmann
2016-03-10  9:31 ` Russell King - ARM Linux
2016-03-10 16:59   ` Arnd Bergmann
2016-03-10 17:09     ` Russell King - ARM Linux
2016-03-10 17:59       ` Arnd Bergmann
2016-03-10  9:38 ` Dmitry Eremin-Solenikov
2016-03-10 16:38   ` Arnd Bergmann
2016-03-10 21:49     ` Dmitry Eremin-Solenikov
2016-03-15 15:14       ` Arnd Bergmann
2016-03-10  9:40 ` Baruch Siach
2016-03-10 10:58   ` Robin Murphy
2016-03-10 15:40 ` Dave Martin
2016-03-11  5:44 ` Hans Ulli Kroll
2016-03-11  6:48   ` [OpenWrt-Devel] " John Crispin
2016-03-11 16:09     ` Roman Yeryomin
2016-03-11 16:56       ` Hans Ulli Kroll
2016-03-15 15:59         ` Arnd Bergmann
2016-03-15 17:01           ` John Crispin [this message]
2016-03-15 20:26           ` Ard Biesheuvel
2016-03-15 22:00             ` Arnd Bergmann
2016-03-17 16:18 ` Ramana Radhakrishnan
2016-03-17 19:34   ` Dmitry Eremin-Solenikov
2016-03-18 13:25     ` Ramana Radhakrishnan
2016-03-21 20:50       ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56E83FE6.7040506@openwrt.org \
    --to=blogic@openwrt$(echo .)org \
    --cc=linux-arm-kernel@lists$(echo .)infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox