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>

This patch adds support to both Faraday FUSBH200 and FOTG210,
the differences between Faraday EHCI and standard EHCI are
listed bellow:

1. The PORTSC starts at 0x30 instead of 0x44.
2. The CONFIGFLAG(0x40) is not only un-implemented, and
   also has its address space removed.
3. Faraday EHCI is a TDI design, but it doesn't
   compatible with the general TDI implementation
   found at both U-Boot and Linux.
4. The ISOC descriptors differ from standard EHCI in
   several ways. But since U-boot doesn't support ISOC,
   we don't have to worry about that.
Signed-off-by: NKuo-Jung Su <dantesu@faraday-tech.com>
CC: Marek Vasut <marex@denx.de>

This patch makes the minimum power-on delay for USB HUB
become configurable. The original design waits at least
100 msec here, but some EHCI controlers(e.g. Faraday EHCI)
are known to require much longer delay interval.
Signed-off-by: NKuo-Jung Su <dantesu@faraday-tech.com>
CC: Marek Vasut <marex@denx.de>

There is at least one non-EHCI compliant controller (i.e. Faraday EHCI)
not only leave RESERVED and CONFIGFLAG registers un-implemented
but also has their address spaces removed.

As an result, the PORTSC register of Faraday EHCI always
starts from 0x30 instead of 0x44 in standard EHCI.

So that we'll need a weak-aliased function for abstraction.
Signed-off-by: NKuo-Jung Su <dantesu@faraday-tech.com>
CC: Marek Vasut <marex@denx.de>

1. The 'index' of ehci_submit_root() is not always > 0.

   e.g.
   While it gets invoked from usb_get_descriptor(),
   the 'index' is always a '0'. (See ch.9 of USB2.0)

2. The PORTSC register is not always required, and thus it
   should only report a port error when necessary.
   It would cause a port scan failure if the ehci_submit_root()
   always gets terminated by a port error.
Signed-off-by: NKuo-Jung Su <dantesu@faraday-tech.com>
CC: Marek Vasut <marex@denx.de>

Use get_unaligned() while fetching wMaxPacketSize to avoid
voilating any alignment rules.
Signed-off-by: NVivek Gautam <gautam.vivek@samsung.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Piotr Wilczek <p.wilczek@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Lukasz Dalek <luk0104@gmail.com>
Cc: Marek Vasut <marex@denx.de>

Use unaligned access to fetch wMaxPacketSize in usb_endpoint_maxp()
api.
In its absence we see following data abort message:
==============================================================
data abort

    MAYBE you should read doc/README.arm-unaligned-accesses

pc : [<bf794e24>]          lr : [<bf794e1c>]
sp : bf37c7b0  ip : 0000002f     fp : 00000000
r10: 00000000  r9 : 00000002     r8 : bf37fecc
r7 : 00000001  r6 : bf7d8931     r5 : bf7d891c  r4 : bf7d8800
r3 : bf7d65b0  r2 : 00000002     r1 : bf7d65b4  r0 : 00000027
Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...

resetting ...
==============================================================
Signed-off-by: NVivek Gautam <gautam.vivek@samsung.com>
Cc: Ilya Yanok <ilya.yanok@cogentembedded.com>
Cc: Marek Vasut <marex@denx.de>

The ASIX driver calls a basic_init() function during get_info(), so that
not all initialization tasks need to be redone on every init().
Unfortunately, the most important one is still triggered too often: the
driver does a full port and MII reset on every asix_init(), requiring up
to several seconds to reestablish the link.

This patch confines that software reset into the asix_basic_init()
function so that it will only be executed once. This saves about a
second of boot time on systems using BOOTP.

Note: this patch was previously submitted many moons ago as:

   usb: usbeth: asix: Do a fast init if link already established

That patch seens to have been lost or forgotten, so this is a rebased
version. It is tested on snow with a Asix USB dongle (Cisco).
Signed-off-by: NJulius Werner <jwerner@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NVadim Bendebury <vbendeb@chromium.org>

This commit broke USB2 on link (Chromebook Pixel):

  020bbcb7 usb: hub: Power-cycle on root-hub ports

However the root cause seems to be a missing mask and missing 'break'
in ehci-hcd.c. This patch fixes both.

On link, 'usb start' with a USB keyboard and memory stick inserted now
finds both. The keyboard works as expected. Also ext2ls shows a directory
listing from the memory stick.
Signed-off-by: NSimon Glass <sjg@chromium.org>

If the USB keyboard is not answering properly the first request on its
interrupt endpoint, just skip it and try the next one.

This workarounds an issue with a wireless mouse dongle which presents
itself both as a keyboard and a mouse but has a non-functional keyboard
interface.
Signed-off-by: NVincent Palatin <vpalatin@chromium.org>
(cherry picked from commit 012bbf0ce0301be2482857e3f03b481dd15c2340)
Rebased to upstream/master:
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NStefan Reinauer <reinauer@chromium.org>
Tested-by: NVincent Palatin <vpalatin@chromium.org>

Allow to reconfigure properly the USB keyboard driver when we enumerate
several times the USB devices and its position in the device tree has
changes.
Signed-off-by: NVincent Palatin <vpalatin@chromium.org>
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NStefan Reinauer <reinauer@chromium.org>
Tested-by: NVincent Palatin <vpalatin@chromium.org>

The flash_info_t->start[] field is limited in size by CONFIG_SYS_MAX_FLASH_SECT
macro, which is set to 19 for this board in the board config file. If we inspect
the board/ppmc7xx/flash.c closely, especially the flash_get_size() function, we
can notice the "switch ((long)flashtest)" at around line 80 having a few results
which will set flash_info_t->sector_count to value higher than 19, for example
"case AMD_ID_LV640U" will set it to 128. Notice that right underneath, iteration
over flash_info_t->start[] happens and the upper bound for the interation is
flash_info_t->sector_count. Now if the sector_count is 128 as it is for the
AMD_ID_LV640U case, but the CONFIG_SYS_MAX_FLASH_SECT limiting the start[] is
only 19, an access past the start[] array much happen. Moreover, during this
iteration, the field is written to, so memory corruption is inevitable.
Signed-off-by: NMarek Vasut <marex@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Tom Rini <trini@ti.com>
Cc: Richard Danter <richard.danter@windriver.com>

C99's strict aliasing rules are insane to use in low-level code such as a
bootloader, but as Wolfgang has rejected -fno-strict-aliasing in the
past, add a union so that 16-bit accesses can be performed.

Compile-tested only.
Signed-off-by: NScott Wood <scottwood@freescale.com>
Acked-by: NWolfgang Denk <wd@denx.de>