[U-Boot] [RFC] ARM: Toolchain configuration for Cortex A8 based OMAP3?

[Dirk Behme <dirk.behme@googlemail.com>]

Dirk Behme wrote:
> 
> While preparing U-Boot patches for ARM Cortex A8 based OMAP3 [1], we 
> found that we use CodeSourcery ARM toolchain [2], and the way we locally 
> modified main Makefile to use this toolchain is most probably 
> incompatible with mainline.
> 
> Please find below some diffs what we did locally.
> 
> We now like to discuss/ask what's the best way to align this with 
> mainline to be able to submit OMAP3 patches?
> 
> Any hints or proposals?
> 
> Many thanks,
> 
> Dirk
> 
> [1] 
> http://www.sakoman.net/cgi-bin/gitweb.cgi?p=u-boot-omap3.git;a=summary 
> ('common' branch)
> 
> [2] http://www.codesourcery.com/gnu_toolchains/arm/portal/release313
> 
> Relevant parts of OMAP3 patch we talk about here (most probably 
> reformated cause of copy & paste to mailtool, so just for discussion. 
> Final patches will be sent by git-send-mail). Note the -lgcc_eh which 
> seems to be CodeSourcery specific, and the -march=armv7a in config.mk.
> 
> diff -uprN uboot_clean/Makefile uboot_beagle/Makefile
> --- uboot_clean/Makefile    2008-08-22 19:57:05.000000000 +0200
> +++ uboot_beagle/Makefile    2008-08-22 19:53:52.000000000 +0200
> @@ -141,7 +141,7 @@ ifeq ($(ARCH),ppc)
>  CROSS_COMPILE = ppc_8xx-
>  endif
>  ifeq ($(ARCH),arm)
> -CROSS_COMPILE = arm-linux-
> +CROSS_COMPILE = arm-none-linux-gnueabi-
>  endif
>  ifeq ($(ARCH),i386)
>  CROSS_COMPILE = i386-linux-
> @@ -253,7 +253,7 @@ LIBBOARD = board/$(BOARDDIR)/lib$(BOARD)
>  LIBBOARD := $(addprefix $(obj),$(LIBBOARD))
> 
>  # Add GCC lib
> -PLATFORM_LIBS += -L $(shell dirname `$(CC) $(CFLAGS) 
> -print-libgcc-file-name`) -lgcc
> +PLATFORM_LIBS += -L $(shell dirname `$(CC) $(CFLAGS) 
> -print-libgcc-file-name`) -lgcc -lgcc_eh

Thanks to the proposals here we fixed this. Just removing -lgcc_eh is 
the solution :)

> #########################################################################
> +## ARM CORTEX Systems
> +#########################################################################
> +omap3_beagle_config :    unconfig
> +    @$(MKCONFIG) $(@:_config=) arm omap3 beagle omap3
> +
> +omap3_overo_config :    unconfig
> +    @$(MKCONFIG) $(@:_config=) arm omap3 overo omap3
> +
> +omap3_evm_config :    unconfig
> +    @$(MKCONFIG) $(@:_config=) arm omap3 evm omap3
> +
> +#########################################################################
>  ## XScale Systems
> 
> #########################################################################
> 
> diff -uprN uboot_clean/cpu/omap3/config.mk uboot_beagle/cpu/omap3/config.mk
> --- uboot_clean/cpu/omap3/config.mk    1970-01-01 01:00:00.000000000 +0100
> +++ uboot_beagle/cpu/omap3/config.mk    2008-08-22 19:52:20.000000000 +0200
> @@ -0,0 +1,34 @@
> +#
> +# (C) Copyright 2002
> +# Gary Jennejohn, DENX Software Engineering, <gj@denx.de>
> +#
> <cut GPL>
> +#
> +PLATFORM_RELFLAGS += -fno-strict-aliasing  -fno-common -ffixed-r8 \
> +    -msoft-float
> +
> +PLATFORM_CPPFLAGS += -march=armv7a

Now, the remaining question is what to do with

+CROSS_COMPILE = arm-none-linux-gnueabi-

+PLATFORM_CPPFLAGS += -march=armv7a

we still have above.

Checking our code, it seems we need -march=armv7a. Else one file 
wouldn't compile any more. E.g. replacing armv7a with armv4 results in

- a lot of warnings "warning: target CPU does not support interworking"

- start.S compilation in our patch fails:

start.S: Assembler messages:
start.S:466: Error: selected processor does not support `isb'
start.S:475: Error: selected processor does not support `clz r5,r4'
start.S:500: Error: selected processor does not support `isb'

Possible solutions:

a) Post patch without modifying CROSS_COMPILE, resulting in usage of 
arm-linux-. With this, we would locally overwrite CROSS_COMPILE at 
command line with toolchain we like. I'm not sure if the standard 
arm-linux- toolchain used for "make all" supports -march=armv7a, though.

b) Introduce something like new

ifeq ($(ARCH),cortex-arm)
CROSS_COMPILE = arm-none-linux-gnueabi-
endif

I don't know if this would be accepted and how to do it cleanly, though.

c) More?

Any hints and proposals are welcome!

Thanks,

Dirk