All the other constants use lowercase 'x' in "MPC85xx", so we
duplicate that here.
Signed-off-by: NAndy Fleming <afleming@freescale.com>

Freescale documentation presents the PowerPC core names in lower case, such as
"e300", "e500", "e600", etc.

Change the upper case occurrences into lower case so that the core names
reported in U-boot can match the ones from the documentation.

While at it also fix a checkpatch error:

ERROR: space prohibited before that close parenthesis ')'
#53: FILE: arch/powerpc/cpu/mpc86xx/cpu.c:81:
+	printf("e600 Core %d", (msscr0 & 0x20) ? 1 : 0 );
Reported-by: NHeinz Wrobel <heinz.wrobel@freescale.com>
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NAndy Fleming <afleming@freescale.com>

BSC9132 has 3 IFC banks.
Signed-off-by: NYork Sun <yorksun@freescale.com>
Signed-off-by: NAndy Fleming <afleming@freescale.com>

BSC9131RDB has 1GB DDR.
Out of this, only 880MB is passed on to Linux via bootm_size.
Remaining
-16MB is reserved for PowerPC-DSP shared control area
-128MB is reserved for DSP private area.

Also 256MB, out of this 880MB is required for data communication between
PowerPC and DSP core.
For this bootargs are modified to pass parameter to create 1 hugetlb
page of 256MB via default_hugepagesz, hugepagesz and hugepages
Signed-off-by: NPriyanka Jain <Priyanka.Jain@freescale.com>
Signed-off-by: NAndy Fleming <afleming@freescale.com>

BSC9131RDB is a Freescale Reference Design Board for
BSC9131 SoC which is a integrated device that contains
one powerpc e500v2 core and one DSP starcore.

To support DSP starcore
-Creating LAW and TLB for DSP-CCSR space.
-Creating LAW for DSP-core subsystem M2 memory
Signed-off-by: NPriyanka Jain <Priyanka.Jain@freescale.com>
Signed-off-by: NPoonam Aggrwal <poonam.aggrwal@freescale.com>
Signed-off-by: NPrabhakar Kushwaha <prabhakar@freescale.com>
Signed-off-by: NAndy Fleming <afleming@freescale.com>

BSC9131RDB supports Sysclk
-66MHz if jumper J16 is close (default state)
-100MHz if jumper J16 is open

Add targets
-BSC9131RDB_NAND_SYSCLK100 : for NAND boot at Sysclk 100MHz
-BSC9131RDB_SPIFLASH_SYSCLK100: for SPI boot at Sysclk 100MHz
Signed-off-by: NRamneek Mehresh <ramneek.mehresh@freescale.com>
Signed-off-by: NPriyanka Jain <Priyanka.Jain@freescale.com>
Signed-off-by: NAndy Fleming <afleming@freescale.com>

- Add NAND boot target
   - defines constants
   - Add spl_minimal.c to initialise DDR
   - update TLB, LAW entries as per NAND boot
Signed-off-by: NPrabhakar Kushwaha <prabhakar@freescale.com>
Signed-off-by: NAndy Fleming <afleming@freescale.com>

- Add NAND boot target
   - defines constants
   - Add spl_minimal.c to initialise DDR
   - update TLB entries as per NAND boot
Signed-off-by: NPrabhakar Kushwaha <prabhakar@freescale.com>
Signed-off-by: NAndy Fleming <afleming@freescale.com>

- defines constants
  - Add spl_minimal.c to initialise DDR
  - update TLB entries as per NAND boot
  - remove nand_spl support for P1010RDB
Signed-off-by: NPrabhakar Kushwaha <prabhakar@freescale.com>
Signed-off-by: NAndy Fleming <afleming@freescale.com>

Linker script is not able find start.o binary. So add its absolute path in
u-boot-spl.lds. This change is similar to u-boot-nand.lds

common/Makefile: Avoid compiling unnecssary files

fsl_ifc_spl.c : It is is responsible for reading u-boot binary from
NAND flash and copying into DDR. It also transfer control from NAND SPL
to u-boot image present in DDR.
Signed-off-by: NPrabhakar Kushwaha <prabhakar@freescale.com>
Signed-off-by: NAndy Fleming <afleming@freescale.com>

IFC errata A003399 is valid for IFC NOR boot i.e.if no on-board NOR flash or
no NOR boot, do not compile its workaround.
Signed-off-by: NPrabhakar Kushwaha <prabhakar@freescale.com>
Signed-off-by: NAndy Fleming <afleming@freescale.com>

To avoid sign extension problem, use explicit casting to cast
the SDRAM size to type phys_size_t, or else, if the SDRAM size
is 2G(0x80000000), it will be extended to 0xffffffff80000000
when phys_size_t is type 'unsigned long long'.
Signed-off-by: NMingkai Hu <Mingkai.Hu@freescale.com>
Signed-off-by: NAndy Fleming <afleming@freescale.com>

Accidentally applied an earlier version of the patch, which set
the compatible to "fsl,qoriq-clockgen-2", lacking the final
".0".
Signed-off-by: NAndy Fleming <afleming@freescale.com>
Signed-off-by: NTang Yuantian <Yuantian.Tang@freescale.com>

If we try to boot from NET device, NetInitLoop in net.c will be invoked.
If NET device is not installed, eth_get_dev() function will return
eth_current value, which is NULL.
When NetInitLoop is called, "eth_get_dev->enetaddr" will access
restricted memory area and therefore cause hanging.
This issue is found on Tegra30 Cardhu platform after adding
CONFIG_CMD_NET and CONFIG_CMD_DHCP in config header file.
Signed-off-by: NJim Lin <jilin@nvidia.com>
Tested-by: NStephen Warren <swarren@nvidia.com>

This error may not be defined on some platforms such as MacOS so host
compilation will fail. Use one of the more common errors instead.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Tested-by: NAndreas Bießmann <andreas.devel@googlemail.com>
Tested-by: NLubomir Popov <lpopov@mm-sol.com>

Signed-off-by: NTom Rini <trini@ti.com>

Use a negative value of CONFIG_ENV_OFFSET for all NVIDIA reference boards
that store the U-Boot environment in the 2nd eMMC boot partition. This
makes U-Boot agnostic to the size of the eMMC boot partition, which can
vary depending on which eMMC device was actually stuffed into the board.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NTom Warren <twarren@nvidia.com>
Signed-off-by: NAndy Fleming <afleming@freescale.com>

A negative value of CONFIG_ENV_OFFSET is treated as a backwards offset
from the end of the eMMC device/partition, rather than a forwards offset
from the start.

This is useful when a single board may be stuffed with different eMMC
devices, each of which has a different capacity, and you always want the
environment to be stored at the very end of the device (or eMMC boot
partition for example).

One example of this case is NVIDIA's Ventana reference board.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NAndy Fleming <afleming@freescale.com>

Enhance the MMC core to calculate the size of each MMC partition, and
update mmc->capacity whenever a partition is selected. This causes:

mmc dev 0 1 ; mmcinfo

... to report the size of the currently selected partition, rather than
always reporting the size of the user partition.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NAndy Fleming <afleming@freescale.com>

Describe the meaning of CONFIG_ENV_IS_IN_MMC, and all related defines that
must or can be set when using that option.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Reviewed-by: NPeter Korsgaard <jacmet@sunsite.dk>
Acked-by: NTom Rini <trini@ti.com>
Signed-off-by: NAndy Fleming <afleming@freescale.com>

After waiting for the command completion event, the interrupt status
bits, that occured to be set by that time, are cleared by writing them
back. It is supposed, that it should be command related bits (command
complete and may be command errors).

However, in some cases the DMA already completes by that time before
the full transaction completes. The corresponding DINT bit gets set
and then cleared before even entering the loop, waiting for data part
completion. That waiting loop never gets this bit set, causing the
operation to hang. This is reported to happen, for example, for write
operation of 1 sector to upper area (block #7400000) of SanDisk Ultra II
8GB card.

The solution could be to explicitly clear only command related interrupt
status bits. However, since subsequent processing does not rely on
any command bits state, it could be easier just to remove clearing
of any bits at that point, leaving them all until all data processing
completes. After that the whole register will be cleared at once.

Also, on occasion, interrupts masking moved to before writing the command,
just for the case there should be no chance of interrupt between the first
command and interrupts masking.
Reported-by: NDirk Behme <dirk.behme@de.bosch.com>
Signed-off-by: NAndrew Gabbasov <andrew_gabbasov@mentor.com>
Acked-by: NDirk Behme <dirk.behme@de.bosch.com>
Signed-off-by: NAndy Fleming <afleming@freescale.com>

Since commit 48e0b2bd (powerpc/esdhc: Correct judgement for DATA PIO mode)
we see mx6 systems to hang after doing a 'save' command.

Revert this commit since the original 'ifdef' logic from 7b43db92
(drivers/mmc/fsl_esdhc.c: fix compiler warnings) was the correct one.
Reported-by: NTapani Utriainen <tapani@technexion.com>
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NAndy Fleming <afleming@freescale.com>

This patch fixes a bug related to mmc writes.

When doing fatwrites on an SD-Card, MMC bus problems can occur. Depending
on the size of the file, "MMC0: Bus busy timeout!" is reported, resulting
in an SD-Card that is no longer responding.
It appears to be, that set_cluster can be called with a size being zero.
That can be with a file that has a size being an exact multiple
(including 0) of the clustersize, but also for files that are smaller than
the size of one cluster.
The same problem occurs if the "mmc write" command is given with a block
count being 0.

By adding a check for the block count being zero in mmc_write_blocks
(drivers/mmc.c), this problem is solved.
Signed-off-by: NRuud Commandeur <rcommandeur@clb.nl>
Cc: Tom Rini <trini@ti.com>
Cc: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
Cc: Mats Karrman <Mats.Karrman@tritech.se>
Cc: Andy Fleming <afleming@gmail.com>
Signed-off-by: NAndy Fleming <afleming@freescale.com>

CAP register don't have any information for 8-bit buswidth support
on 2.0 sdhci spec, only from 3.0 onwards bit[18] got this information.

Due to this misassignment in sdhci, mmc is setting 8-bit buswidth using
mmc_set_bus_width even if controller doesn't support.
Below change has code information.
"mmc: Properly determine maximum supported bus width"
(sha1: 7798f6db)

Bug log: <mmc plus and emmc cards)
-------
zynq-uboot> mmcinfo
Error detected in status(0x208100)!
Device: zynq_sdhci
Manufacturer ID: fe
.....

So enable 8-bit support only for 3.0 spec using CAP and for below 3.0
assign mmc->host_caps = MMC_MODE_8BIT on respective platform driver
if host have a support.
Signed-off-by: NJagannadha Sutradharudu Teki <jaganna@xilinx.com>
Signed-off-by: NAndy Fleming <afleming@freescale.com>

The commit d196bd88 (env_mmc: add support for redundant environment)
introduce the following compile error when enable redundant
environment support with MMC
---8<---
env_mmc.c:149: error: 'env_t' has no member named 'flags'
env_mmc.c:248: error: 'env_t' has no member named 'flags'
env_mmc.c:248: error: 'env_t' has no member named 'flags'
env_mmc.c:250: error: 'env_t' has no member named 'flags'
env_mmc.c:250: error: 'env_t' has no member named 'flags'
env_mmc.c:252: error: 'env_t' has no member named 'flags'
env_mmc.c:252: error: 'env_t' has no member named 'flags'
env_mmc.c:254: error: 'env_t' has no member named 'flags'
env_mmc.c:254: error: 'env_t' has no member named 'flags'
env_mmc.c:267: error: 'env_t' has no member named 'flags'
make[1]: *** [env_mmc.o] Error 1
--->8---

Add this patch to fix it
Signed-off-by: NBo Shen <voice.shen@atmel.com>
Reviewed-by: NMichael Heimpold <mhei@heimpold.de>
Signed-off-by: NAndy Fleming <afleming@freescale.com>

Small conflict over DRA7XX updates and adding SRAM_SCRATCH_SPACE_ADDR

Conflicts:
	arch/arm/include/asm/arch-omap5/omap.h
Signed-off-by: NTom Rini <trini@ti.com>

This patch corrected the nr_blocks used for W25Q32DW SPI flash.

nr_blcoks are incorrectly assigned on below patch
"sf: winbond: add W25Q32DW"
(sha1: 772ba154)
Signed-off-by: NJagannadha Sutradharudu Teki <jaganna@xilinx.com>

Add support for Winbond W25Q80BW SPI flash.

This patch corrected the flash name, nr_blocks and
also commit message header from below patch.
"sf: winbond: add W25Q32"
(sha1: c969abc4)
Signed-off-by: NJagannadha Sutradharudu Teki <jaganna@xilinx.com>

As the per the ID tabl the flash is under Uniform 64-kB sector
architecture, hence updated with proper name.
Signed-off-by: NJagannadha Sutradharudu Teki <jaganna@xilinx.com>

It's done in spi_alloc_slave(), thus remove the redundant code.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Acked-by: NMarek Vasut <marex@denx.de>
Reviewed-by: NJagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>

Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Acked-by: NMarek Vasut <marex@denx.de>
Reviewed-by: NJagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>

Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Reviewed-by: NMarek Vasut <marex@denx.de>
Acked-by: NAjay Bhargav <ajay.bhargav@einfochips.com>
Reviewed-by: NJagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>

PXA270 CPU has turbo mode. The mode is 2.5 times faster than the
default run mode. Activating the mode early significantly speeds
up boot process.
Signed-off-by: NSergey Yanovich <ynvich@gmail.com>

LP-8x4x is a programmable automation controller by ICP DAS. It is
shipped with outdated U-Boot v1.3.0

This patch adds enough supports to boot the board:
 - 128M of 128M SDRAM
 - 32M of 48M NOR Flash memory
 - 1 of 4 Serial consoles (PXA FFUART)
 - 2 of 2 Ethernet controllers (DM9000)
Signed-off-by: NSergey Yanovich <ynvich@gmail.com>
Series-to: u-boot
Series-cc: marex

Without this, second usb_composite_register() call fails always
with -EINVAL.
Signed-off-by: NHeiko Schocher <hs@denx.de>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Marek Vasut <marex@denx.de>

Commit 8f62ca64 "usb: ehci: Support interrupt transfers via periodic list"
didn't include any cache management in the new interrupt transfer path.
It also added an extra write to or_asynclistaddr in usb_lowlevel_init(),
without having flushed out the data there.

Add the missing cache management calls, so that the code works again.

This allows the USB keyboard on Tegra's Seaboard/Springbank boards to
work.

Cc: Patrick Georgi <patrick@georgi-clan.de>
Cc: Vincent Palatin <vpalatin@chromium.org>
Cc: Julius Werner <jwerner@chromium.org>
Cc: Simon Glass <sjg@chromium.org>
Cc: Marek Vasut <marex@denx.de>
Signed-off-by: NStephen Warren <swarren@nvidia.com>

The Faraday FOTG210 is an OTG chip which could operate
as either an EHCI Host or a USB Device at a time.
Signed-off-by: NKuo-Jung Su <dantesu@faraday-tech.com>
CC: Marek Vasut <marex@denx.de>