We set the L1 dache register with a bogus register value.  Need to be
using 'r3' instead of 'r0'.

Reported-by: John Traill <john.traill@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

Add spaces to cause the informational prints to line up with
the ones from init_func_ram() in board.c.  Output now looks like
this:

....
DRAM:  Detected 4096 MB of memory
       This U-Boot only supports < 4G of DDR
       You could rebuild it with CONFIG_PHYS_64BIT
       DDR: 2 GiB (DDR2, 64-bit, CL=5, ECC off)
....

The prints from lbc_sdram_init() have also been modified to line
line up and changed to start with "LBC SDRAM" instead of the
confusing "SDRAM".

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

This config option is for an erratum workaround; rename it to be more
clear.  Also, drop it from config files don't need it and were
undefining it.

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

sdram_init() is used to initialize sdram on the lbc.  Rename it
accordingly.

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

Correct initdram to use phys_size_t to represent the size of
dram; instead of changing this all over the place, and correcting
all the other random errors I've noticed, create a
common initdram that is used by all non-corenet 85xx parts.  Most
of the initdram() functions were identical, with 2 common differences:

1) DDR tlbs for the fixed_sdram case were set up in initdram() on
some boards, and were part of the tlb_table on others.  I have
changed them all over to the initdram() method - we shouldn't
be accessing dram before this point so they don't need to be
done sooner, and this seems cleaner.

2) Parts that require the DDR11 erratum workaround had different
implementations - I have adopted the version from the Freescale
errata document.  It also looks like some of the versions were
buggy, and, depending on timing, could have resulted in the
DDR controller being disabled.  This seems bad.

The xpedite boards had a common/fsl_8xxx_ddr.c; with this
change only the 517 board uses this so I have moved the ddr code
into that board's directory in xpedite517x.c

Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org>
Tested-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

Some platforms might want to override the default wimge=0 for
DDR.  Add CONFIG_SYS_PPC_DDR_WIMGE for those platforms to use.
This will initially only be used by TQM85xx, but could be
useful for other boards or testing going forward.  Note that
the name of this define is not 85xx-specific.  WIMGE is a
fairly universal concept, so any ppc platforms that require
different WIMGE settings for DDR can use the same #define.

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

Also, change this code to use phys_size_t instead of long int.
Using common naming for this function will enable us to use the common
initdram() for 85xx going forward.  Other than the type change,
this is just a code rearrange.

Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org>
Acked-by: Stefan Roese <sr@denx.de>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

Use new is_serdes_configured to determine if TSECs are in SGMII mode and
report that on the various boards that use or can be configured in SGMII
mode in board_eth_init() instead of in the PCI init code.

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

Now that we have serdes support for all 85xx/86xx/Pxxx chips we can
replace the is_fsl_pci_cfg() code with the is_serdes_configured().

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

Some new platform's esdhc pins don't share with other function.
The eSDHC shouldn't be disabled, even if "esdhc" isn't defined
in hwconfig env variable.

Use CONFIG_FSL_ESDHC_PIN_MUX to fix this problem.

Signed-off-by: Chenhui Zhao <b26998@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

Signed-off-by: Piergiorgio Beruto <piergiorgio.beruto@gmail.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

Add the ability to determine if a given IP block connected on SERDES is
configured.  This is useful for things like PCIe and SRIO since they are
only ever connected on SERDES.

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

Add the ability to determine if a given IP block connected on SERDES is
configured.  This is useful for things like PCIe and SRIO since they are
only ever connected on SERDES.

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

Add the ability to determine if a given IP block connected on SERDES is
configured.  This is useful for things like PCIe and SRIO since they are
only ever connected on SERDES.

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

Add the ability to determine if a given IP block connected on SERDES is
configured.  This is useful for things like PCIe and SRIO since they are
only ever connected on SERDES.

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

Add the ability to determine if a given IP block connected on SERDES is
configured.  This is useful for things like PCIe and SRIO since they are
only ever connected on SERDES.

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

Add the ability to determine if a given IP block connected on SERDES is
configured.  This is useful for things like PCIe and SRIO since they are
only ever connected on SERDES.

Signed-off-by: Chenhui Zhao <b26998@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

Add the ability to determine if a given IP block connected on SERDES is
configured.  This is useful for things like PCIe and SRIO since they are
only ever connected on SERDES.

Signed-off-by: Li Yang <leoli@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

Add the ability to determine if a given IP block connected on SERDES is
configured.  This is useful for things like PCIe and SRIO since they are
only ever connected on SERDES.  This mimics the code we have in place
for the 85xx platforms.

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

Created a section in the Makefile for SoC specific SERDES code.  Also
added P1013 SERDES (use P1022 SERDES code).

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

Instead of a #define use a null weak function for fsl_serdes_init

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

Mimic support that exists on MPC8536DS on the MPC8572DS to allow booting
from NAND.

Signed-off-by: Jin Qing <b24347@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

Neither of these parts should have the erratum this is meant to
work around.  Delete it.

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

This isn't used - delete it.

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

This will help us go to a fixed initdram() for all 85xx boards going
forward.  sdram_setup() had an argument that it didn't need, since the
value was #defined.

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

I've probably got the best chance of getting access to these
boards in order to test things, and since Joe's e-mail is
bouncing, update the MAINTAINERS entry to reflect this.

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

The PM854/PM856 boards are no longer maintained and thus we are removing
support for them.

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Acked-by: Wolfgang Denk <wd@denx.de>

The MPC8540EVAL board is no longer maintained and thus we are removing
support for it.

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

The ATUM8548 board is no longer maintained and thus we are removing
support for it.

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

This reverts commit 5a442c0a.

This commit changed the behaviour of getenv_yesno() (both the default
behaviour and the documented behaviour for abbreviated arguments)
which resulted in problems in several areas.

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

Fix compiler warning

In file included from ubifs.h:2137:0,
                 from ubifs.c:26:
misc.h: In function 'ubifs_idx_key':
misc.h:263:26: warning: dereferencing type-punned pointer will break strict-aliasing rules

seen with gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50).

No functional change.

CC: Stefan Roese <sr@denx.de>
Signed-off-by: Dirk Behme <dirk.behme@googlemail.com>
Signed-off-by: Stefan Roese <sr@denx.de>

config.mk only mkdirs $(obj), but we have objects shared with other
boards located on other dirs.

This patch mkdirs the needed dirs for the xlnx-generic boards.

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

Signed-off-by: David Mueller <d.mueller@elsoft.ch>
Signed-off-by: Stefan Roese <sr@denx.de>

Patch 8ef583a0 [miiphy: convert to linux/mii.h] introduced a small
problem in the ppc4xx miiphy.c version. This patch fixes this problem.

Signed-off-by: Stefan Roese <sr@denx.de>
Acked-by: Mike Frysinger <vapier@gentoo.org>

The eth_device.name field length is limited by NAMESIZE,
which is 16 defined in include/net.h. Unfortunately, two
of the names in lan91c96.c are beyond that.

Signed-off-by: YanJun Yang <yangyj.ee@gmail.com>