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

[Dirk Behme]

Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 08:39 Sat 23 Aug     , 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-
> 
> 
> please do not change it
> 
> you specify it at runtime

Yes, as recommended by Wolfgang and ksi, too, we will do this. Thanks 
to all proposing this!

> btw: you can use arm-elf- toolchains and others to compile u-boot so why do
> you want to modify the default one?

The original source code from TI we used to start for OMAP3 patch just 
used it (most probably to have armv7a support). We will change this.

>>  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
>>
> 
> please do it in a fix commit

Yes, we already fixed this in the OMAP3 preparation git.

>>  # The "tools" are needed early, so put this first
>>  # Don't include stuff already done in $(LIBS)
>>@@ -2641,6 +2641,18 @@ SMN42_config	:	unconfig
>>  	@$(MKCONFIG) $(@:_config=) arm arm720t SMN42 siemens lpc2292
>>
>> 
>>#########################################################################
>>+## ARM CORTEX Systems
>>+#########################################################################
>>+omap3_beagle_config :	unconfig
>>+	@$(MKCONFIG) $(@:_config=) arm omap3 beagle omap3
>>+
> 
> add it when you add each board (1 board => 1 patch)

Yes, okay.

>>+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 at denx.de>
>>+#
>><cut GPL>
>>+#
>>+PLATFORM_RELFLAGS += -fno-strict-aliasing  -fno-common -ffixed-r8 \
>>+	-msoft-float
>>+
>>+PLATFORM_CPPFLAGS += -march=armv7a
> 
> 
> Do you really need armv7a march?

We have to rewrite at least start,S, but yes, we will to this. So we 
don't really need this.

> Could you explain why?

The U-Boot code we got from TI for OMAP3 uses arm-none-linux-gnueabi- 
  -march=armv7a. While cleaning this code for upstream submission, we 
found this and now get the answer from you, Wolfgang and ksi how to 
handle this properly.

Many thanks for your help

Dirk