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

This patch re-formats the code in cpu/arm920t and cpu/arm920t/23c24x0 in
preparation for changes to add support for the Embest SBC2440-II Board.

The changes are as follows:
- re-indent the code using Lindent
- make sure register layouts are defined using a C struct
- replace the upper-case typedef'ed C struct names with lower case
  non-typedef'ed ones
- make sure registers are accessed using the proper accessor functions
- run checkpatch.pl and fix any error reports

It assumes the following patch has been applied first:
- [U-Boot][PATCH-ARM] CONFIG_SYS_HZ fix for ARM902T S3C24X0 Boards, 05/09/2009

Tested on an Embest SBC2440-II Board with local u-boot patches as I don't have
any s3c2400 or s3c2410 boards but need this patch applying before I can submit
patches for the SBC2440-II Board. Also, ran MAKEALL for all ARM9 targets and no
new warnings or errors were found.

Signed-off-by: Kevin Morfitt <kevin.morfitt@fearnside-systems.co.uk>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>

This sets CONFIG_SYS_HZ to 1000 for all boards that use the s3c2400 and
s3c2410 cpu's which fixes various problems such as the timeouts in tftp being
too short.

Tested on an Embest SBC2440-II Board with local u-boot patches as I don't
have any s3c2400 or s3c2410 boards but need this patch applying before I can
submit patches for the SBC2440-II Board. Also, ran MAKEALL for all ARM9 targets
and no new warnings or errors were found.

It was originally submitted on 21/06/2009 but didn't get into the 2009.08
release, and Jean-Pierre made one comment on the original patch (see
http://lists.denx.de/pipermail/u-boot/2009-July/055470.html). I've made two
changes to the original patch:
- it's been re-based to the current release
- I've re-named get_timer_raw() to get_ticks() in response to Jean-Pierre's comment

This affects the sbc2410, smdk2400, smdk2410 and trab boards. I've copied it
directly to the maintainers of all except the sbc2410 which doesn't have an
entry in MAINTAINERS.

Signed-off-by: Kevin Morfitt <kmorfitt@aselaptop-1.localdomain>
Tested-by: Wolfgang Denk <wd@denx.de>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>

CPUAT91 is built around Atmel's AT91RM9200 and has up to 16MB of NOR
flash, up to 128MB of SDRAM, and includes a Micrel KS8721 PHY in RMII
mode.

Signed-off-by: Eric Benard <eric@eukrea.com>
Signed-off-by: Tom Rix <Tom.Rix@windriver.com>

-fno-strict-aliasing is hidding warnings.

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

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>

For some reason the AT91rm9200 lowlevel init writes to a bunch of
reserved or read-only addresses.  All the boards seem to define the
value-to-be-written values as zero ... but they shouldn't actually
be writing *anything* there.

No documented erratum justifies these accesses.  It looks like maybe
some pre-release BDI-2000 setup code has been carried along by cargo
cult programming since at least late 2004 (per GIT history).

Here's a patch disabling what seems to be bogosity.  Tested on a
csb337; there were no behavioral changes.

Signed-off-by: David Brownell <david-b@pacbell.net>

on RM9200ek
Tested-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>

Commit fcd3c87e made include/common.h usable by assembler code but
failed to update cpu/arm920t/start.S

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

CSB337 boards originally shipped with MicroMonitor, not U-Boot;
and with a version using a different convention for recording
Ethernet addresses than anyone else.  To avoid breaking Linux
when it uses U-Boot, have it use the same convention on that
hardware.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Ben Warren <biggerbadderben@gmail.com>

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