For some time there have been repeated reports about build problems
with some ARM (cross) tool chains.  Especially issues about
(in)compatibility with the tool chain provided runtime support
library libgcc.a caused to add and support a private implementation
of such runtime support code in U-Boot.  A closer look at the code
indicated that some of these issues are actually home-made.  This
patch attempts to clean up some of the most obvious problems and make
building of U-Boot with different tool chains easier:

- Even though all ARM systems basicy used the same compiler options
  to select a specific ABI from the tool chain, the code for this was
  distributed over all cpu/*/config.mk files.  We move this one level
  up into lib_arm/config.mk instead.

- So far, we only checked if "-mapcs-32" was supported by the tool
  chain; if yes, this was used, if not, "-mabi=apcs-gnu" was
  selected, no matter if the tool chain actually understood this
  option.  There was no support for EABI conformant tool chains.
  This patch implements the following logic:

  1) If the tool chain supports
	"-mabi=aapcs-linux -mno-thumb-interwork"
     we use these options (EABI conformant tool chain).
  2) Otherwise, we check first if
	"-mapcs-32"
     is supported, and then check for
	"-mabi=apcs-gnu"
     If one test succeeds, we use the first found option.
  3) In case 2), we also test if "-mno-thumb-interwork", and use
     this if the test succeeds. [For "-mabi=aapcs-linux" we set
     "-mno-thumb-interwork" mandatorily.]

  This way we use a similar logic for the compile options as the
  Linux kernel does.

- Some EABI conformant tool chains cause external references to
  utility functions like raise(); such functions are provided in the
  new file lib_arm/eabi_compat.c

  Note that lib_arm/config.mk gets parsed several times, so we must
  make sure to add eabi_compat.o only once to the linker list.

Signed-off-by: Wolfgang Denk <wd@denx.de>
Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Dirk Behme <dirk.behme@googlemail.com>
Cc: Magnus Lilja <lilja.magnus@gmail.com>
Cc: Tom Rix <Tom.Rix@windriver.com>
Cc: Prafulla Wadaskar <prafulla@marvell.com>
Acked-by: Sergey Kubushyn <ksi@koi8.net>
Tested-by: Magnus Lilja <lilja.magnus@gmail.com>
Tested-by: Andrzej Wolski <awolski@poczta.fm>
Tested-by: Gaye Abdoulaye Walsimou <walsimou@walsimou.com>
Tested-by: Tom Rix <Tom.Rix@windriver.com>
Tested-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>

The ARM EABI defines new names for GCC helper functions,
and GCC seems to need some new functions as well.

This patch is a minimal-invasive approach to fix problems with EABI
conformant tool chains (to be used with "USE_PRIVATE_LIBGCC=yes").

Signed-off-by: Wolfgang Denk <wd@denx.de>
Tested-by: Dirk Behme <dirk.behme@googlemail.com>

Signed-off-by: Heiko Schocher <hs@denx.de>

Many (especially ARM) tool chains seem to come with broken or
otherwise unusable (for the purposes of builing U-Boot) run-time
support libraries `libgcc.a'. By using the "USE_PRIVATE_LIBGCC"
setting we allow to use alternative libraries instead.

"USE_PRIVATE_LIBGCC" can either be set as an environment variable in
the shell, or as a command line argument when running "make", i. e.
	$ make USE_PRIVATE_LIBGCC=yes
or
	$ USE_PRIVATE_LIBGCC=yes
	$ export USE_PRIVATE_LIBGCC
	$ make

The value of "USE_PRIVATE_LIBGCC" is the name of the directory which
contains the alternative run-time support library `libgcc.a'. The
special value "yes" selects the directory $(OBJTREE)/lib_$(ARCH) .

Note that not all architectures provide an alternative `libgcc.a' in
their lib_$(ARCH) directories - so far, only ARM does.

Signed-off-by: Wolfgang Denk <wd@denx.de>
Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Prafulla Wadaskar <prafulla@marvell.com>
cc: Stefan Roese <sr@denx.de>

This cleans up U-Boot's toplevel directory a bit and makes the
architecture 'config.mk' file naming and location similar to board
and cpu 'config.mk' files

Signed-off-by: Peter Tyser <ptyser@xes-inc.com>

So far the console API uses the following naming convention:

	======Extract======
	typedef struct device_t;

	int	device_register (device_t * dev);
	int	devices_init (void);
	int	device_deregister(char *devname);
	struct list_head* device_get_list(void);
	device_t* device_get_by_name(char* name);
	device_t* device_clone(device_t *dev);
	=======

which is too generic and confusing.

Instead of using device_XX and device_t we change this
into stdio_XX and stdio_dev

This will also allow to add later a generic device mechanism in order
to have support for multiple devices and driver instances.

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>

Edited commit message.

Signed-off-by: Wolfgang Denk <wd@denx.de>

Signed-off-by: Ilya Yanok <yanok@emcraft.com>

and fix comment

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>

Adjusted Copyright message.

Signed-off-by: Wolfgang Denk <wd@denx.de>

This patch is required for Kirkwood support
may be used by other ARM architectures

Signed-off-by: Prafulla Wadaskar <prafulla@marvell.com>

move s3c44b0 to arch_cpu_init and as noone use cpu_init remove it

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>