[PATCH, RFT] ARM: use --fix-v4bx to allow building ARMv4 with future gcc

[PATCH, RFT] ARM: use --fix-v4bx to allow building ARMv4 with future gcc

[Arnd Bergmann]

gcc-6.0 and later marks support for ARMv3 and ARMv4 as 'deprecated',
meaning that this is expected to be removed at some point in the future,
with gcc-8.0 as the earliest.

When building the kernel, the difference between ARMv4 and ARMv4T
is relatively small because the kernel never runs THUMB instructions
on ARMv4T and does not need any support for interworking.

For any future compiler that does not support -march=armv4, we now
fall back to -march=armv4t as the architecture level selection,
but keep using -march=armv4 by default as long as that is supported
by the compiler.

Similarly, the -mtune=strongarm110 and -mtune=strongarm1100 options
will go away at the same time as -march=armv4, so this adds a check
to see if the compiler supports them, falling back to no -mtune
option otherwise.

Compiling with -march=armv4t leads the compiler to using 'bx reg'
instructions instead of 'mov pc,reg'. This is not supported on
ARMv4 based CPUs, but the linker can work around this by rewriting
those instructions to the ARMv4 version if we pass --fix-v4bx
to the linker. This should work with binutils-2.15 (released
May 2004) or higher, and we can probably assume that anyone using
gcc-7.x will have a much more recent binutils version as well.

However, in order to still allow users of old toolchains to link
the kernel, we only pass the option to linkers that support it,
based on a $(ld-option ...) call. I'm intentionally passing the
flag to all linker versions here regardless of whether it's needed
or not, so we can more easily spot any regressions if something
goes wrong.

For consistency, I'm passing the --fix-v4bx flag for both the
vmlinux final link and the individual loadable modules.
The module loader code already interprets the R_ARM_V4BX relocations
in loadable modules and converts bx instructions into mov even
when running on ARMv4T or ARMv5 processors. This is now redundant
when we pass --fix-v4bx to the linker for building modules, but
I see no harm in leaving the current implementation and doing both.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
Please test by making the -march=armv4t switch unconditional
and see if that results in a working kernel

 arch/arm/Makefile | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index e83f5161fdd8..33b7eb4502aa 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -19,6 +19,11 @@ LDFLAGS_vmlinux	+= --be8
 KBUILD_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)
 KBUILD_LDFLAGS_MODULE	+= -T $(srctree)/arch/arm/kernel/module.lds
 endif
@@ -76,7 +81,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
@@ -94,8 +99,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)
-- 
2.9.0

[PATCH, RFT] ARM: use --fix-v4bx to allow building ARMv4 with future gcc

[Arnd Bergmann]

gcc-6.0 and later marks support for ARMv3 and ARMv4 as 'deprecated',
meaning that this is expected to be removed at some point in the future,
with gcc-8.0 as the earliest.

When building the kernel, the difference between ARMv4 and ARMv4T
is relatively small because the kernel never runs THUMB instructions
on ARMv4T and does not need any support for interworking.

For any future compiler that does not support -march=armv4, we now
fall back to -march=armv4t as the architecture level selection,
but keep using -march=armv4 by default as long as that is supported
by the compiler.

Similarly, the -mtune=strongarm110 and -mtune=strongarm1100 options
will go away at the same time as -march=armv4, so this adds a check
to see if the compiler supports them, falling back to no -mtune
option otherwise.

Compiling with -march=armv4t leads the compiler to using 'bx reg'
instructions instead of 'mov pc,reg'. This is not supported on
ARMv4 based CPUs, but the linker can work around this by rewriting
those instructions to the ARMv4 version if we pass --fix-v4bx
to the linker. This should work with binutils-2.15 (released
May 2004) or higher, and we can probably assume that anyone using
gcc-7.x will have a much more recent binutils version as well.

However, in order to still allow users of old toolchains to link
the kernel, we only pass the option to linkers that support it,
based on a $(ld-option ...) call. I'm intentionally passing the
flag to all linker versions here regardless of whether it's needed
or not, so we can more easily spot any regressions if something
goes wrong.

For consistency, I'm passing the --fix-v4bx flag for both the
vmlinux final link and the individual loadable modules.
The module loader code already interprets the R_ARM_V4BX relocations
in loadable modules and converts bx instructions into mov even
when running on ARMv4T or ARMv5 processors. This is now redundant
when we pass --fix-v4bx to the linker for building modules, but
I see no harm in leaving the current implementation and doing both.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
Please test by making the -march=armv4t switch unconditional
and see if that results in a working kernel

 arch/arm/Makefile | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index e83f5161fdd8..33b7eb4502aa 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -19,6 +19,11 @@ LDFLAGS_vmlinux	+= --be8
 KBUILD_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)
 KBUILD_LDFLAGS_MODULE	+= -T $(srctree)/arch/arm/kernel/module.lds
 endif
@@ -76,7 +81,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
@@ -94,8 +99,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)
-- 
2.9.0

Re: [PATCH, RFT] ARM: use --fix-v4bx to allow building ARMv4 with future gcc

[Ard Biesheuvel]

Hi Arnd,

On 20 December 2017 at 13:00, Arnd Bergmann <arnd@arndb.de> wrote:
> gcc-6.0 and later marks support for ARMv3 and ARMv4 as 'deprecated',
> meaning that this is expected to be removed at some point in the future,
> with gcc-8.0 as the earliest.
>
> When building the kernel, the difference between ARMv4 and ARMv4T
> is relatively small because the kernel never runs THUMB instructions
> on ARMv4T and does not need any support for interworking.
>
> For any future compiler that does not support -march=armv4, we now
> fall back to -march=armv4t as the architecture level selection,
> but keep using -march=armv4 by default as long as that is supported
> by the compiler.
>
> Similarly, the -mtune=strongarm110 and -mtune=strongarm1100 options
> will go away at the same time as -march=armv4, so this adds a check
> to see if the compiler supports them, falling back to no -mtune
> option otherwise.
>
> Compiling with -march=armv4t leads the compiler to using 'bx reg'
> instructions instead of 'mov pc,reg'. This is not supported on
> ARMv4 based CPUs, but the linker can work around this by rewriting
> those instructions to the ARMv4 version if we pass --fix-v4bx
> to the linker. This should work with binutils-2.15 (released
> May 2004) or higher, and we can probably assume that anyone using
> gcc-7.x will have a much more recent binutils version as well.
>
> However, in order to still allow users of old toolchains to link
> the kernel, we only pass the option to linkers that support it,
> based on a $(ld-option ...) call. I'm intentionally passing the
> flag to all linker versions here regardless of whether it's needed
> or not, so we can more easily spot any regressions if something
> goes wrong.
>
> For consistency, I'm passing the --fix-v4bx flag for both the
> vmlinux final link and the individual loadable modules.
> The module loader code already interprets the R_ARM_V4BX relocations
> in loadable modules and converts bx instructions into mov even
> when running on ARMv4T or ARMv5 processors. This is now redundant
> when we pass --fix-v4bx to the linker for building modules, but
> I see no harm in leaving the current implementation and doing both.
>

Are you sure --fix-v4bx is taken into account during a partial link?

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> Please test by making the -march=armv4t switch unconditional
> and see if that results in a working kernel
>
>  arch/arm/Makefile | 11 ++++++++---
>  1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index e83f5161fdd8..33b7eb4502aa 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -19,6 +19,11 @@ LDFLAGS_vmlinux      += --be8
>  KBUILD_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)
>  KBUILD_LDFLAGS_MODULE  += -T $(srctree)/arch/arm/kernel/module.lds
>  endif
> @@ -76,7 +81,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
> @@ -94,8 +99,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

Shouldn't these two be updated as well?

>  tune-$(CONFIG_CPU_FEROCEON)    =$(call cc-option,-mtune=marvell-f,-mtune=xscale)
> --
> 2.9.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH, RFT] ARM: use --fix-v4bx to allow building ARMv4 with future gcc

[Ard Biesheuvel]

Hi Arnd,

On 20 December 2017 at 13:00, Arnd Bergmann <arnd@arndb.de> wrote:
> gcc-6.0 and later marks support for ARMv3 and ARMv4 as 'deprecated',
> meaning that this is expected to be removed at some point in the future,
> with gcc-8.0 as the earliest.
>
> When building the kernel, the difference between ARMv4 and ARMv4T
> is relatively small because the kernel never runs THUMB instructions
> on ARMv4T and does not need any support for interworking.
>
> For any future compiler that does not support -march=armv4, we now
> fall back to -march=armv4t as the architecture level selection,
> but keep using -march=armv4 by default as long as that is supported
> by the compiler.
>
> Similarly, the -mtune=strongarm110 and -mtune=strongarm1100 options
> will go away at the same time as -march=armv4, so this adds a check
> to see if the compiler supports them, falling back to no -mtune
> option otherwise.
>
> Compiling with -march=armv4t leads the compiler to using 'bx reg'
> instructions instead of 'mov pc,reg'. This is not supported on
> ARMv4 based CPUs, but the linker can work around this by rewriting
> those instructions to the ARMv4 version if we pass --fix-v4bx
> to the linker. This should work with binutils-2.15 (released
> May 2004) or higher, and we can probably assume that anyone using
> gcc-7.x will have a much more recent binutils version as well.
>
> However, in order to still allow users of old toolchains to link
> the kernel, we only pass the option to linkers that support it,
> based on a $(ld-option ...) call. I'm intentionally passing the
> flag to all linker versions here regardless of whether it's needed
> or not, so we can more easily spot any regressions if something
> goes wrong.
>
> For consistency, I'm passing the --fix-v4bx flag for both the
> vmlinux final link and the individual loadable modules.
> The module loader code already interprets the R_ARM_V4BX relocations
> in loadable modules and converts bx instructions into mov even
> when running on ARMv4T or ARMv5 processors. This is now redundant
> when we pass --fix-v4bx to the linker for building modules, but
> I see no harm in leaving the current implementation and doing both.
>

Are you sure --fix-v4bx is taken into account during a partial link?

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> Please test by making the -march=armv4t switch unconditional
> and see if that results in a working kernel
>
>  arch/arm/Makefile | 11 ++++++++---
>  1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index e83f5161fdd8..33b7eb4502aa 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -19,6 +19,11 @@ LDFLAGS_vmlinux      += --be8
>  KBUILD_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)
>  KBUILD_LDFLAGS_MODULE  += -T $(srctree)/arch/arm/kernel/module.lds
>  endif
> @@ -76,7 +81,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
> @@ -94,8 +99,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

Shouldn't these two be updated as well?

>  tune-$(CONFIG_CPU_FEROCEON)    =$(call cc-option,-mtune=marvell-f,-mtune=xscale)
> --
> 2.9.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH, RFT] ARM: use --fix-v4bx to allow building ARMv4 with future gcc

[Arnd Bergmann]

On Wed, Dec 20, 2017 at 2:46 PM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> On 20 December 2017 at 13:00, Arnd Bergmann <arnd@arndb.de> wrote:
>> For consistency, I'm passing the --fix-v4bx flag for both the
>> vmlinux final link and the individual loadable modules.
>> The module loader code already interprets the R_ARM_V4BX relocations
>> in loadable modules and converts bx instructions into mov even
>> when running on ARMv4T or ARMv5 processors. This is now redundant
>> when we pass --fix-v4bx to the linker for building modules, but
>> I see no harm in leaving the current implementation and doing both.
>>
>
> Are you sure --fix-v4bx is taken into account during a partial link?

No. I made the patch a long time ago, so I don't remember what exactly
led me to this decision, but it should be fine as long as the linker
does the transformation at least once.

>> +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
>
> Shouldn't these two be updated as well?

All compilers that drop -mtune=strongarm110 support for now still support
mtune=xscale, so I don't think we need to change them. One thing we could
consider is passing -mtune=xscale when building for StrongARM, if that
produces better code than the default -mtune=arm7tdmi, but from looking
at the gcc-8 sources, it's not clear if that's better or worse. Neither arm7tdmi
nor strongarm have a custom cost function, but xscale has. The difference
between arm7tdmi and strongarm110 tuning is just the maximum number of
conditional instructions (5 vs 3).

A much bigger impact might be to tune for arm9e when building a kernel for
ARM926, no idea why we don't already do that (we do it for arm946, which
nobody really uses). Also, gcc has optimizations for many ARMv7-A cores
that we could use if we decide to make them known in Kconfig.

      Arnd

[PATCH, RFT] ARM: use --fix-v4bx to allow building ARMv4 with future gcc

[Arnd Bergmann]

On Wed, Dec 20, 2017 at 2:46 PM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> On 20 December 2017 at 13:00, Arnd Bergmann <arnd@arndb.de> wrote:
>> For consistency, I'm passing the --fix-v4bx flag for both the
>> vmlinux final link and the individual loadable modules.
>> The module loader code already interprets the R_ARM_V4BX relocations
>> in loadable modules and converts bx instructions into mov even
>> when running on ARMv4T or ARMv5 processors. This is now redundant
>> when we pass --fix-v4bx to the linker for building modules, but
>> I see no harm in leaving the current implementation and doing both.
>>
>
> Are you sure --fix-v4bx is taken into account during a partial link?

No. I made the patch a long time ago, so I don't remember what exactly
led me to this decision, but it should be fine as long as the linker
does the transformation at least once.

>> +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
>
> Shouldn't these two be updated as well?

All compilers that drop -mtune=strongarm110 support for now still support
mtune=xscale, so I don't think we need to change them. One thing we could
consider is passing -mtune=xscale when building for StrongARM, if that
produces better code than the default -mtune=arm7tdmi, but from looking
at the gcc-8 sources, it's not clear if that's better or worse. Neither arm7tdmi
nor strongarm have a custom cost function, but xscale has. The difference
between arm7tdmi and strongarm110 tuning is just the maximum number of
conditional instructions (5 vs 3).

A much bigger impact might be to tune for arm9e when building a kernel for
ARM926, no idea why we don't already do that (we do it for arm946, which
nobody really uses). Also, gcc has optimizations for many ARMv7-A cores
that we could use if we decide to make them known in Kconfig.

      Arnd

Re: [PATCH, RFT] ARM: use --fix-v4bx to allow building ARMv4 with future gcc

[Linus Walleij]

On Wed, Dec 20, 2017 at 2:00 PM, Arnd Bergmann <arnd@arndb.de> wrote:

> gcc-6.0 and later marks support for ARMv3 and ARMv4 as 'deprecated',
> meaning that this is expected to be removed at some point in the future,
> with gcc-8.0 as the earliest.
>
> When building the kernel, the difference between ARMv4 and ARMv4T
> is relatively small because the kernel never runs THUMB instructions
> on ARMv4T and does not need any support for interworking.
>
> For any future compiler that does not support -march=armv4, we now
> fall back to -march=armv4t as the architecture level selection,
> but keep using -march=armv4 by default as long as that is supported
> by the compiler.
>
> Similarly, the -mtune=strongarm110 and -mtune=strongarm1100 options
> will go away at the same time as -march=armv4, so this adds a check
> to see if the compiler supports them, falling back to no -mtune
> option otherwise.
>
> Compiling with -march=armv4t leads the compiler to using 'bx reg'
> instructions instead of 'mov pc,reg'. This is not supported on
> ARMv4 based CPUs, but the linker can work around this by rewriting
> those instructions to the ARMv4 version if we pass --fix-v4bx
> to the linker. This should work with binutils-2.15 (released
> May 2004) or higher, and we can probably assume that anyone using
> gcc-7.x will have a much more recent binutils version as well.
>
> However, in order to still allow users of old toolchains to link
> the kernel, we only pass the option to linkers that support it,
> based on a $(ld-option ...) call. I'm intentionally passing the
> flag to all linker versions here regardless of whether it's needed
> or not, so we can more easily spot any regressions if something
> goes wrong.
>
> For consistency, I'm passing the --fix-v4bx flag for both the
> vmlinux final link and the individual loadable modules.
> The module loader code already interprets the R_ARM_V4BX relocations
> in loadable modules and converts bx instructions into mov even
> when running on ARMv4T or ARMv5 processors. This is now redundant
> when we pass --fix-v4bx to the linker for building modules, but
> I see no harm in leaving the current implementation and doing both.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> Please test by making the -march=armv4t switch unconditional
> and see if that results in a working kernel

I did this:
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 66e46aec0cd0..3944ecd6cd31 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -81,7 +81,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 $(call
cc-option,-march=armv4,-march=armv4t)
+arch-$(CONFIG_CPU_32v4)                =-D__LINUX_ARM_ARCH__=4 -march=armv4t
 arch-$(CONFIG_CPU_32v3)                =-D__LINUX_ARM_ARCH__=3 -march=armv3

Built and booted on the Gemini platform.

It crashes immediately and goes into the boot loader
on thos FA-526 based platform.

Yours,
Linus Walleij

[PATCH, RFT] ARM: use --fix-v4bx to allow building ARMv4 with future gcc

[Linus Walleij]

On Wed, Dec 20, 2017 at 2:00 PM, Arnd Bergmann <arnd@arndb.de> wrote:

> gcc-6.0 and later marks support for ARMv3 and ARMv4 as 'deprecated',
> meaning that this is expected to be removed at some point in the future,
> with gcc-8.0 as the earliest.
>
> When building the kernel, the difference between ARMv4 and ARMv4T
> is relatively small because the kernel never runs THUMB instructions
> on ARMv4T and does not need any support for interworking.
>
> For any future compiler that does not support -march=armv4, we now
> fall back to -march=armv4t as the architecture level selection,
> but keep using -march=armv4 by default as long as that is supported
> by the compiler.
>
> Similarly, the -mtune=strongarm110 and -mtune=strongarm1100 options
> will go away at the same time as -march=armv4, so this adds a check
> to see if the compiler supports them, falling back to no -mtune
> option otherwise.
>
> Compiling with -march=armv4t leads the compiler to using 'bx reg'
> instructions instead of 'mov pc,reg'. This is not supported on
> ARMv4 based CPUs, but the linker can work around this by rewriting
> those instructions to the ARMv4 version if we pass --fix-v4bx
> to the linker. This should work with binutils-2.15 (released
> May 2004) or higher, and we can probably assume that anyone using
> gcc-7.x will have a much more recent binutils version as well.
>
> However, in order to still allow users of old toolchains to link
> the kernel, we only pass the option to linkers that support it,
> based on a $(ld-option ...) call. I'm intentionally passing the
> flag to all linker versions here regardless of whether it's needed
> or not, so we can more easily spot any regressions if something
> goes wrong.
>
> For consistency, I'm passing the --fix-v4bx flag for both the
> vmlinux final link and the individual loadable modules.
> The module loader code already interprets the R_ARM_V4BX relocations
> in loadable modules and converts bx instructions into mov even
> when running on ARMv4T or ARMv5 processors. This is now redundant
> when we pass --fix-v4bx to the linker for building modules, but
> I see no harm in leaving the current implementation and doing both.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> Please test by making the -march=armv4t switch unconditional
> and see if that results in a working kernel

I did this:
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 66e46aec0cd0..3944ecd6cd31 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -81,7 +81,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 $(call
cc-option,-march=armv4,-march=armv4t)
+arch-$(CONFIG_CPU_32v4)                =-D__LINUX_ARM_ARCH__=4 -march=armv4t
 arch-$(CONFIG_CPU_32v3)                =-D__LINUX_ARM_ARCH__=3 -march=armv3

Built and booted on the Gemini platform.

It crashes immediately and goes into the boot loader
on thos FA-526 based platform.

Yours,
Linus Walleij

Re: [PATCH, RFT] ARM: use --fix-v4bx to allow building ARMv4 with future gcc

[Arnd Bergmann]

On Thu, Dec 21, 2017 at 5:57 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Wed, Dec 20, 2017 at 2:00 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
>> gcc-6.0 and later marks support for ARMv3 and ARMv4 as 'deprecated',
>> meaning that this is expected to be removed at some point in the future,
>> with gcc-8.0 as the earliest.
>>
>> When building the kernel, the difference between ARMv4 and ARMv4T
>> is relatively small because the kernel never runs THUMB instructions
>> on ARMv4T and does not need any support for interworking.
>>
>> For any future compiler that does not support -march=armv4, we now
>> fall back to -march=armv4t as the architecture level selection,
>> but keep using -march=armv4 by default as long as that is supported
>> by the compiler.
>>
>> Similarly, the -mtune=strongarm110 and -mtune=strongarm1100 options
>> will go away at the same time as -march=armv4, so this adds a check
>> to see if the compiler supports them, falling back to no -mtune
>> option otherwise.
>>
>> Compiling with -march=armv4t leads the compiler to using 'bx reg'
>> instructions instead of 'mov pc,reg'. This is not supported on
>> ARMv4 based CPUs, but the linker can work around this by rewriting
>> those instructions to the ARMv4 version if we pass --fix-v4bx
>> to the linker. This should work with binutils-2.15 (released
>> May 2004) or higher, and we can probably assume that anyone using
>> gcc-7.x will have a much more recent binutils version as well.
>>
>> However, in order to still allow users of old toolchains to link
>> the kernel, we only pass the option to linkers that support it,
>> based on a $(ld-option ...) call. I'm intentionally passing the
>> flag to all linker versions here regardless of whether it's needed
>> or not, so we can more easily spot any regressions if something
>> goes wrong.
>>
>> For consistency, I'm passing the --fix-v4bx flag for both the
>> vmlinux final link and the individual loadable modules.
>> The module loader code already interprets the R_ARM_V4BX relocations
>> in loadable modules and converts bx instructions into mov even
>> when running on ARMv4T or ARMv5 processors. This is now redundant
>> when we pass --fix-v4bx to the linker for building modules, but
>> I see no harm in leaving the current implementation and doing both.
>>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> ---
>> Please test by making the -march=armv4t switch unconditional
>> and see if that results in a working kernel
>
> I did this:
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index 66e46aec0cd0..3944ecd6cd31 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -81,7 +81,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 $(call
> cc-option,-march=armv4,-march=armv4t)
> +arch-$(CONFIG_CPU_32v4)                =-D__LINUX_ARM_ARCH__=4 -march=armv4t
>  arch-$(CONFIG_CPU_32v3)                =-D__LINUX_ARM_ARCH__=3 -march=armv3
>
> Built and booted on the Gemini platform.
>
> It crashes immediately and goes into the boot loader
> on thos FA-526 based platform.

Hmm, maybe the decompressor needs the fixup separately. Can you try
something like this completely untested patch on top?

     Arnd

diff --git a/arch/arm/boot/compressed/Makefile
b/arch/arm/boot/compressed/Makefile
index f0548b6948f1..0e141b2cae98 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -134,6 +134,11 @@ endif
 ifeq ($(CONFIG_CPU_ENDIAN_BE8),y)
 LDFLAGS_vmlinux += --be8
 endif
+
+ifdef CONFIG_CPU_32v4
+LDFLAGS_vmlinux += --fix-v4bx
+endif
+
 # ?
 LDFLAGS_vmlinux += -p
 # Report unresolved symbol references

[PATCH, RFT] ARM: use --fix-v4bx to allow building ARMv4 with future gcc

[Arnd Bergmann]

On Thu, Dec 21, 2017 at 5:57 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Wed, Dec 20, 2017 at 2:00 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
>> gcc-6.0 and later marks support for ARMv3 and ARMv4 as 'deprecated',
>> meaning that this is expected to be removed at some point in the future,
>> with gcc-8.0 as the earliest.
>>
>> When building the kernel, the difference between ARMv4 and ARMv4T
>> is relatively small because the kernel never runs THUMB instructions
>> on ARMv4T and does not need any support for interworking.
>>
>> For any future compiler that does not support -march=armv4, we now
>> fall back to -march=armv4t as the architecture level selection,
>> but keep using -march=armv4 by default as long as that is supported
>> by the compiler.
>>
>> Similarly, the -mtune=strongarm110 and -mtune=strongarm1100 options
>> will go away at the same time as -march=armv4, so this adds a check
>> to see if the compiler supports them, falling back to no -mtune
>> option otherwise.
>>
>> Compiling with -march=armv4t leads the compiler to using 'bx reg'
>> instructions instead of 'mov pc,reg'. This is not supported on
>> ARMv4 based CPUs, but the linker can work around this by rewriting
>> those instructions to the ARMv4 version if we pass --fix-v4bx
>> to the linker. This should work with binutils-2.15 (released
>> May 2004) or higher, and we can probably assume that anyone using
>> gcc-7.x will have a much more recent binutils version as well.
>>
>> However, in order to still allow users of old toolchains to link
>> the kernel, we only pass the option to linkers that support it,
>> based on a $(ld-option ...) call. I'm intentionally passing the
>> flag to all linker versions here regardless of whether it's needed
>> or not, so we can more easily spot any regressions if something
>> goes wrong.
>>
>> For consistency, I'm passing the --fix-v4bx flag for both the
>> vmlinux final link and the individual loadable modules.
>> The module loader code already interprets the R_ARM_V4BX relocations
>> in loadable modules and converts bx instructions into mov even
>> when running on ARMv4T or ARMv5 processors. This is now redundant
>> when we pass --fix-v4bx to the linker for building modules, but
>> I see no harm in leaving the current implementation and doing both.
>>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> ---
>> Please test by making the -march=armv4t switch unconditional
>> and see if that results in a working kernel
>
> I did this:
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index 66e46aec0cd0..3944ecd6cd31 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -81,7 +81,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 $(call
> cc-option,-march=armv4,-march=armv4t)
> +arch-$(CONFIG_CPU_32v4)                =-D__LINUX_ARM_ARCH__=4 -march=armv4t
>  arch-$(CONFIG_CPU_32v3)                =-D__LINUX_ARM_ARCH__=3 -march=armv3
>
> Built and booted on the Gemini platform.
>
> It crashes immediately and goes into the boot loader
> on thos FA-526 based platform.

Hmm, maybe the decompressor needs the fixup separately. Can you try
something like this completely untested patch on top?

     Arnd

diff --git a/arch/arm/boot/compressed/Makefile
b/arch/arm/boot/compressed/Makefile
index f0548b6948f1..0e141b2cae98 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -134,6 +134,11 @@ endif
 ifeq ($(CONFIG_CPU_ENDIAN_BE8),y)
 LDFLAGS_vmlinux += --be8
 endif
+
+ifdef CONFIG_CPU_32v4
+LDFLAGS_vmlinux += --fix-v4bx
+endif
+
 # ?
 LDFLAGS_vmlinux += -p
 # Report unresolved symbol references

Re: [PATCH, RFT] ARM: use --fix-v4bx to allow building ARMv4 with future gcc

[Linus Walleij]

On Thu, Dec 21, 2017 at 6:02 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thu, Dec 21, 2017 at 5:57 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>> On Wed, Dec 20, 2017 at 2:00 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>
>>> gcc-6.0 and later marks support for ARMv3 and ARMv4 as 'deprecated',
>>> meaning that this is expected to be removed at some point in the future,
>>> with gcc-8.0 as the earliest.
>>>
>>> When building the kernel, the difference between ARMv4 and ARMv4T
>>> is relatively small because the kernel never runs THUMB instructions
>>> on ARMv4T and does not need any support for interworking.
>>>
>>> For any future compiler that does not support -march=armv4, we now
>>> fall back to -march=armv4t as the architecture level selection,
>>> but keep using -march=armv4 by default as long as that is supported
>>> by the compiler.
>>>
>>> Similarly, the -mtune=strongarm110 and -mtune=strongarm1100 options
>>> will go away at the same time as -march=armv4, so this adds a check
>>> to see if the compiler supports them, falling back to no -mtune
>>> option otherwise.
>>>
>>> Compiling with -march=armv4t leads the compiler to using 'bx reg'
>>> instructions instead of 'mov pc,reg'. This is not supported on
>>> ARMv4 based CPUs, but the linker can work around this by rewriting
>>> those instructions to the ARMv4 version if we pass --fix-v4bx
>>> to the linker. This should work with binutils-2.15 (released
>>> May 2004) or higher, and we can probably assume that anyone using
>>> gcc-7.x will have a much more recent binutils version as well.
>>>
>>> However, in order to still allow users of old toolchains to link
>>> the kernel, we only pass the option to linkers that support it,
>>> based on a $(ld-option ...) call. I'm intentionally passing the
>>> flag to all linker versions here regardless of whether it's needed
>>> or not, so we can more easily spot any regressions if something
>>> goes wrong.
>>>
>>> For consistency, I'm passing the --fix-v4bx flag for both the
>>> vmlinux final link and the individual loadable modules.
>>> The module loader code already interprets the R_ARM_V4BX relocations
>>> in loadable modules and converts bx instructions into mov even
>>> when running on ARMv4T or ARMv5 processors. This is now redundant
>>> when we pass --fix-v4bx to the linker for building modules, but
>>> I see no harm in leaving the current implementation and doing both.
>>>
>>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>>> ---
>>> Please test by making the -march=armv4t switch unconditional
>>> and see if that results in a working kernel
>>
>> I did this:
>> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
>> index 66e46aec0cd0..3944ecd6cd31 100644
>> --- a/arch/arm/Makefile
>> +++ b/arch/arm/Makefile
>> @@ -81,7 +81,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 $(call
>> cc-option,-march=armv4,-march=armv4t)
>> +arch-$(CONFIG_CPU_32v4)                =-D__LINUX_ARM_ARCH__=4 -march=armv4t
>>  arch-$(CONFIG_CPU_32v3)                =-D__LINUX_ARM_ARCH__=3 -march=armv3
>>
>> Built and booted on the Gemini platform.
>>
>> It crashes immediately and goes into the boot loader
>> on thos FA-526 based platform.
>
> Hmm, maybe the decompressor needs the fixup separately. Can you try
> something like this completely untested patch on top?
>
>      Arnd
>
> diff --git a/arch/arm/boot/compressed/Makefile
> b/arch/arm/boot/compressed/Makefile
> index f0548b6948f1..0e141b2cae98 100644
> --- a/arch/arm/boot/compressed/Makefile
> +++ b/arch/arm/boot/compressed/Makefile
> @@ -134,6 +134,11 @@ endif
>  ifeq ($(CONFIG_CPU_ENDIAN_BE8),y)
>  LDFLAGS_vmlinux += --be8
>  endif
> +
> +ifdef CONFIG_CPU_32v4
> +LDFLAGS_vmlinux += --fix-v4bx
> +endif
> +

Yes this work! The kernel and userspace comes up.

With this folded in:
Tested-by: Linus Walleij <linus.walleij@linaro.org> for FA526

I will try to test it on SA110 (NetWinder) tomorrow.

Yours,
Linus Walleij

[PATCH, RFT] ARM: use --fix-v4bx to allow building ARMv4 with future gcc

[Linus Walleij]

On Thu, Dec 21, 2017 at 6:02 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thu, Dec 21, 2017 at 5:57 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>> On Wed, Dec 20, 2017 at 2:00 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>
>>> gcc-6.0 and later marks support for ARMv3 and ARMv4 as 'deprecated',
>>> meaning that this is expected to be removed at some point in the future,
>>> with gcc-8.0 as the earliest.
>>>
>>> When building the kernel, the difference between ARMv4 and ARMv4T
>>> is relatively small because the kernel never runs THUMB instructions
>>> on ARMv4T and does not need any support for interworking.
>>>
>>> For any future compiler that does not support -march=armv4, we now
>>> fall back to -march=armv4t as the architecture level selection,
>>> but keep using -march=armv4 by default as long as that is supported
>>> by the compiler.
>>>
>>> Similarly, the -mtune=strongarm110 and -mtune=strongarm1100 options
>>> will go away at the same time as -march=armv4, so this adds a check
>>> to see if the compiler supports them, falling back to no -mtune
>>> option otherwise.
>>>
>>> Compiling with -march=armv4t leads the compiler to using 'bx reg'
>>> instructions instead of 'mov pc,reg'. This is not supported on
>>> ARMv4 based CPUs, but the linker can work around this by rewriting
>>> those instructions to the ARMv4 version if we pass --fix-v4bx
>>> to the linker. This should work with binutils-2.15 (released
>>> May 2004) or higher, and we can probably assume that anyone using
>>> gcc-7.x will have a much more recent binutils version as well.
>>>
>>> However, in order to still allow users of old toolchains to link
>>> the kernel, we only pass the option to linkers that support it,
>>> based on a $(ld-option ...) call. I'm intentionally passing the
>>> flag to all linker versions here regardless of whether it's needed
>>> or not, so we can more easily spot any regressions if something
>>> goes wrong.
>>>
>>> For consistency, I'm passing the --fix-v4bx flag for both the
>>> vmlinux final link and the individual loadable modules.
>>> The module loader code already interprets the R_ARM_V4BX relocations
>>> in loadable modules and converts bx instructions into mov even
>>> when running on ARMv4T or ARMv5 processors. This is now redundant
>>> when we pass --fix-v4bx to the linker for building modules, but
>>> I see no harm in leaving the current implementation and doing both.
>>>
>>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>>> ---
>>> Please test by making the -march=armv4t switch unconditional
>>> and see if that results in a working kernel
>>
>> I did this:
>> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
>> index 66e46aec0cd0..3944ecd6cd31 100644
>> --- a/arch/arm/Makefile
>> +++ b/arch/arm/Makefile
>> @@ -81,7 +81,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 $(call
>> cc-option,-march=armv4,-march=armv4t)
>> +arch-$(CONFIG_CPU_32v4)                =-D__LINUX_ARM_ARCH__=4 -march=armv4t
>>  arch-$(CONFIG_CPU_32v3)                =-D__LINUX_ARM_ARCH__=3 -march=armv3
>>
>> Built and booted on the Gemini platform.
>>
>> It crashes immediately and goes into the boot loader
>> on thos FA-526 based platform.
>
> Hmm, maybe the decompressor needs the fixup separately. Can you try
> something like this completely untested patch on top?
>
>      Arnd
>
> diff --git a/arch/arm/boot/compressed/Makefile
> b/arch/arm/boot/compressed/Makefile
> index f0548b6948f1..0e141b2cae98 100644
> --- a/arch/arm/boot/compressed/Makefile
> +++ b/arch/arm/boot/compressed/Makefile
> @@ -134,6 +134,11 @@ endif
>  ifeq ($(CONFIG_CPU_ENDIAN_BE8),y)
>  LDFLAGS_vmlinux += --be8
>  endif
> +
> +ifdef CONFIG_CPU_32v4
> +LDFLAGS_vmlinux += --fix-v4bx
> +endif
> +

Yes this work! The kernel and userspace comes up.

With this folded in:
Tested-by: Linus Walleij <linus.walleij@linaro.org> for FA526

I will try to test it on SA110 (NetWinder) tomorrow.

Yours,
Linus Walleij