Signed-off-by: Luigi 'Comio' Mantellini <luigi.mantellini@idf-hit.com>
Signed-off-by: Ben Warren <biggerbadderben@gmail.com>

Rather than maintain/extend the current ifeq($(ARCH)) mess that exists in
the standalone Makefile, push the setting up of LOAD_ADDR out to the arch
config.mk (and rename to STANDALONE_LOAD_ADDR in the process).  This keeps
the common code clean and lets the arch do whatever crazy crap it wants in
its own area.

Signed-off-by: Mike Frysinger <vapier@gentoo.org>

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

This lays the groundwork to allow architectures to share a common
mem_malloc_init().

Note that the x86 implementation was not modified as it did not fit the
mold of all other architectures.

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

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

All in-tree boards that use this controller have CONFIG_NET_MULTI added
Also:
  - changed CONFIG_DRIVER_CS8900 to CONFIG_CS8900
  - changed CS8900_BASE to CONFIG_CS8900_BASE
  - changed CS8900_BUS?? to CONFIG_CS8900_BUS??
  - cleaned up line lengths
  - modified VCMA9 command function that accesses the device
  - removed MAC address initialization from lib_arm/board.c

Signed-off-by: Ben Warren <biggerbadderben@gmail.com>
Tested-by: Wolfgang Denk <wd@denx.de>
Acked-by: Wolfgang Denk <wd@denx.de>

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>

all arm init the IRQ stack the same way
so unify it in lib_arm/interrupts.c and then call arch specific interrupt init

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

There is exiting support for red,yellow,green but no blue.
The main LED on the zoom2 is a blue LED.

Signed-off-by: Tom Rix <Tom.Rix@windriver.com>

actually the timer init use the interrupt_init as init callback
which make the interrupt and timer implementation difficult to follow

so now rename it as int timer_init(void) and use interrupt_init for interrupt

btw also remane the corresponding file to the functionnality implemented

as ixp arch implement two timer - one based on interrupt - so all the timer
related code is moved to timer.c

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

This patch moves the malloc initialization before calling flash_init().
Upcoming changes to the NOR FLASH common CFI driver with optional
MTD infrastructure and MTD concatenation support will call malloc().
And nothing really speaks against enabling malloc just a little earlier
in the boot stage. Some architectures already enable malloc before
calling flash_init() so they don't need any changes here.

Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Scott McNutt <smcnutt@psyent.com>
Cc: Shinya Kuribayashi <shinya.kuribayashi@necel.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Cc: Daniel Hellstrom <daniel@gaisler.com>
Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: John Rigby <jcrigby@gmail.com>

Signed-off-by: Detlev Zundel <dzu@denx.de>

For a long time, the print_cpuinfo() declaration in lib_arm/board.c
had been marked as "test-only", which is plain wrong considering
current usage.  Delete this misleading comment.

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

calculate dynamically the clock rate and pllb setting for usb

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

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

unify arm cache management except for non standard cache as ARM7TDMI

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

Some systems have zlib.h installed in /usr/include/. This isn't the
desired file for u-boot code - we want the one in include/zlib.h.
This rename will avoid the conflict.

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>

The environment is the canonical storage location of the mac address, so
we're killing off the global data location and moving everything to
querying the env directly.

Also rename load_sernum_ethaddr() to misc_init_r() so we don't need to
handle this board specially in common ARM code.

Signed-off-by: Mike Frysinger <vapier@gentoo.org>
CC: Ben Warren <biggerbadderben@gmail.com>

The environment is the canonical storage location of the mac address, so
we're killing off the global data location and moving everything to
querying the env directly.

Some warts are remaining and should be killed off (by moving the func to
the appropriate board init code):
	- davinci_eth_set_mac_addr
	- cs8900_get_enetaddr
	- smc_set_mac_addr

Signed-off-by: Mike Frysinger <vapier@gentoo.org>
CC: Ben Warren <biggerbadderben@gmail.com>

Serial driver via the EmbeddedICE macrocell's DCC channel using
co-processor 14.

It does include a timeout to ensure that the system does not
totally freeze when there is nothing connected to read.

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

Signed-off-by: Rafal Czubak <rcz@semihalf.com>
Acked-by: Rafal Jaworowski <raj@semihalf.com>

The "size" variable in start_armboot() in lib_arm/board.c is only really
used in "#ifndef CONFIG_SYS_NO_FLASH" case, and even there it can be
eliminated (thanks to Jean-Christophe PLAGNIOL-VILLARD for a suggestion.)

Signed-off-by: Guennadi Liakhovetski <lg@denx.de>

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

Use the GNU 'date' command to auto-generate a new U-Boot
timestamp on every compile.

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

This patch corrects a small bug in the "if" condition:
the parameter "flag" is 0 and the "if" condition is always true.
The result is - the boom command doesn't start the kernel.
Affected targets: all arm based.

Signed-off-by: Ilko Iliev <iliev@ronetix.at>

Add the ability to break the steps of the bootm command into several
subcommands: start, loados, ramdisk, fdt, bdt, cmdline, prep, go.

This allows us to do things like manipulate device trees before
they are passed to a booting kernel or setup memory for a secondary
core in multicore situations.

Not all OS types support all subcommands (currently only start, loados,
ramdisk, fdt, and go are supported).

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

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

due to the arm implementation which supposed that U-Boot is in RAM
when we jump to start_armboot

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

we need this due to the arm implementation which supposed that U-Boot
is in RAM when we jump to start_armboot

This reverts commit f96b44ce.
in order to do it for all arm board

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

bootm.c:128: warning: label 'error' defined but not used
bootm.c:65: warning: unused variable 'ret'

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

DM644x is just one of a series of DaVinci chips that use the EMAC driver.
By replacing all the function names that start with dm644x_* to davinci_*
we make these function more portable. I have tested this change on my EVM.
DM6467 is another DaVinci SOC which uses the EMAC driver and i will
be sending patches that add DaVinci DM6467 support to the list soon.

Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>