The purpose of this patch is to prepare for adding the OMAP4 architecture, which is Cortex A9

Cortex A8 and A9 both belong to the armv7 architecture, hence the name change.

The two architectures are similar enough that substantial code can be shared.

Signed-off-by: Aneesh V <aneesh@ti.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>

The hush shell dynamically allocates (and re-allocates) memory for the
argument strings in the "char *argv[]" argument vector passed to
commands.  Any code that modifies these pointers will cause serious
corruption of the malloc data structures and crash U-Boot, so make
sure the compiler can check that no such modifications are being done
by changing the code into "char * const argv[]".

This modification is the result of debugging a strange crash caused
after adding a new command, which used the following argument
processing code which has been working perfectly fine in all Unix
systems since version 6 - but not so in U-Boot:

int main (int argc, char **argv)
{
	while (--argc > 0 && **++argv == '-') {
/* ====> */	while (*++*argv) {
			switch (**argv) {
			case 'd':
				debug++;
				break;
			...
			default:
				usage ();
			}
		}
	}
	...
}

The line marked "====>" will corrupt the malloc data structures and
usually cause U-Boot to crash when the next command gets executed by
the shell.  With the modification, the compiler will prevent this with
an
	error: increment of read-only location '*argv'

N.B.: The code above can be trivially rewritten like this:

	while (--argc > 0 && **++argv == '-') {
		char *arg = *argv;
		while (*++arg) {
			switch (*arg) {
			...

Signed-off-by: Wolfgang Denk <wd@denx.de>
Acked-by: Mike Frysinger <vapier@gentoo.org>

The ARM ABI requires that the stack be aligned to 8 bytes as it is noted
in Procedure Call Standard for the ARM Architecture:
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042d/index.html

Unaligned SP also causes the problem with variable-length arrays
allocation when VLA address becomes less than stack pointer during
aligning of this address, so the next 'push' in the stack overwrites
first 4 bytes of VLA.

Signed-off-by: Vitaly Kuzmichev <vkuzmichev@mvista.com>

The push / pop instructions used in this file are available only with
more recent tool chains:

cache.S: Assembler messages:
cache.S:133: Error: bad instruction `push {r0,r1,r2,lr}'
cache.S:160: Error: bad instruction `pop {r1,r2,r3,pc}'
cache.S:164: Error: bad instruction `push {r0,r1,r2,lr}'
cache.S:191: Error: bad instruction `pop {r1,r2,r3,pc}'

Change push/pop into stmfd/ldmfd instructions to support older
versions of binutils as well.

I verified that the modified source code generates exactly the same
binary code.

Signed-off-by: Wolfgang Denk <wd@denx.de>
Cc: Sandeep Paulraj <s-paulraj@ti.com>
Cc: Tom Rix <tom@bumblecow.com>

This patch adds support for the EMIF4 interface
available in the AM35x processors.

Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Sanjeev Premi <premi@ti.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>

Consolidated SDRC related functions into one file - sdrc.c

And also replaced sdrc_init with generic memory init
function (mem_init), this generalization of omap memory setup
is necessary to support the new emif4 interface introduced in AM3517.

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

initialized for CS1

From: Vaibhav Hiremath <hvaibhav@ti.com>

The patch makes sure that size for SDRC CS1 gets calculated
only when the CS1 SDRC is initialized.

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

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

Fix MX51 CPU detect message.

Original string was:
CPU:   Freescale i.MX51 family 3.0V at 800 MHz

which can be misinterpreted as  3.0 Volts instead of the silicon revision.

,change it to:
CPU:   Freescale i.MX51 family rev3.0 at 800 MHz

Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>

The lowlevel_init file contained some hard-coded values
to setup the RAM. These board related values are moved into
the board configuration file.

Signed-off-by: Stefano Babic <sbabic@denx.de>