Modify all existing *.c files to use the new register names
as seen in the AMCC manuals.

Signed-off-by: Niklaus Giger <niklaus.giger@member.fsf.org>
Signed-off-by: Stefan Roese <sr@denx.de>

Add #ifdefs where necessary to not perform relocation fixups.  This
allows boards/architectures which support relocation to trim a decent
chunk of code.

Note that this patch doesn't add #ifdefs to architecture-specific code
which does not support relocation.

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

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

This patch cleans up multiple issues of the 4xx register (mostly
DCR, SDR, CPR, etc) definitions:

- Change lower case defines to upper case (plb4_acr -> PLB4_ACR)
- Change the defines to better match the names from the
  user's manuals (e.g. cprpllc -> CPR0_PLLC)
- Removal of some unused defines

Please test this patch intensive on your PPC4xx platform. Even though
I tried not to break anything and tested successfully on multiple
4xx AMCC platforms, testing on custom platforms is recommended.

Signed-off-by: Stefan Roese <sr@denx.de>

Signed-off-by: Matthias Fuchs <matthias.fuchs@esd.eu>
Signed-off-by: Stefan Roese <sr@denx.de>

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>

Also minor coding style cleanup.

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

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.

The cpus that get converted here:
	at91rm9200
	mpc512x
	mpc5xxx
	mpc8260
	mpc8xx
	ppc4xx

Signed-off-by: Mike Frysinger <vapier@gentoo.org>
CC: Ben Warren <biggerbadderben@gmail.com>
CC: John Rigby <jrigby@freescale.com>
CC: Stefan Roese <sr@denx.de>

When compile u-boot with the 2.18 binutils the following
warning messages for each object file in post/lib_ppc/fpu/ is
produced at the linking stage:

post/libpost.a(acc1.o) uses hard float, u-boot uses soft-float
...

This is because of the fact that, in general, the soft-float and
hard-float ABIs are incompatible; the 2.18 binutils do checking
of the Tag_GNU_Power_ABI_FP attribute of the files to be linked, and
produce the worning like above if these are not compatible.

The incompatibility of ABIs is concerned only the float values:
e.g. the soft-float ABI assumes the float argument passing in the
pair of rX registers, and the hard-float ABI assumes passing of
the float argument in the fX register. When we don't pass the float
arguments between the functions compiled with different floatness,
then such an application will work correctly.
This is the case for the FPU POST: u-boot (compiled with soft-float)
doesn't pass to (and doesn't get from) the FPU POST functions any
floats; there are no functions exported from the post/lib_ppc/fpu/
objects which would work with float parameters/returns too. So, we
can reassure the linker not to worry about the difference in ABI
attributes of linking files just by setting the 'soft-float'
attribute for the objects in post/lib_ppc/fpu. And this patch does
this.

Also, to avoid passing both soft- and hard-float options in CFLAGS
when compiling the files from post/lib_ppc/fpu (which is OK, but
looks rather dirty) this patch removes the soft-float string from
CFLAGS in post/lib_ppc/fpu/Makefile.

Signed-off-by: Yuri Tikhonov <yur@emcraft.com>