Current DWMMC driver used to give FIFO underrun/overrun error every 3rd time
for mmc rescan command.
In current code FIFO_DEPTH is getting calculated after reading the default FIFOTH
register and extracting the RX_WMARK bits from it i.e (RX_WMARK = FIFO_DEPTH/2 -1).
Instead of storing the correct value, we were recalculating the FIFO_DEPT each
time which is not correct.
Based on "[PATCH V9 3/9] DWMMC: Initialise dwmci and resolve EMMC read write issues"
http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/160247
Signed-off-by: Hatim Ali <hatim.rv@samsung.com>
Signed-off-by: Rajeshwari Shinde <rajeshwari.s@samsung.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Acked-by: Andy Fleming <afleming@freescale.com>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.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: Stephen Warren <swarren@nvidia.com>
Acked-by: Tom Warren <twarren@nvidia.com>
Signed-off-by: Andy 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: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Andy 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: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Andy 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: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Peter Korsgaard <jacmet@sunsite.dk>
Acked-by: Tom Rini <trini@ti.com>
Signed-off-by: Andy 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: Dirk Behme <dirk.behme@de.bosch.com>
Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
Signed-off-by: Andy 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: Tapani Utriainen <tapani@technexion.com>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Andy 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: Ruud 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: Andy 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: 7798f6dbd5)
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: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Signed-off-by: Andy Fleming <afleming@freescale.com>
The commit d196bd8 (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: Bo Shen <voice.shen@atmel.com>
Reviewed-by: Michael Heimpold <mhei@heimpold.de>
Signed-off-by: Andy 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: Tom 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: 772ba15474)
Signed-off-by: Jagannadha 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: c969abc470)
Signed-off-by: Jagannadha 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: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
It's done in spi_alloc_slave(), thus remove the redundant code.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Marek Vasut <marex@denx.de>
Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Marek Vasut <marex@denx.de>
Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Acked-by: Ajay Bhargav <ajay.bhargav@einfochips.com>
Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
This patch implements the mux_addr bit fields defined in tmu_control
register (used for debugging purpose)
Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
Reviewed-by: Vadim Bendebury <vbendeb@google.com>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
This patch does the folowing
1. change the data types for unsigned int variable to unsigned
2. change the tmu_base type to struct exynos5_tmu_reg *
3. Add timer functionality for get_cur_temp()
4. error handling in the get_tmu_fdt_values()
5. Add check for curr_temp reading
6. some cosmotic changes.
Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
Reviewed-by: Vadim Bendebury <vbendeb@google.com>
Acked-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
This patch adds commands to access(open/close) and resize boot partitions on EMMC.
Signed-off-by: Amar <amarendra.xt@samsung.com>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
This patch adds APIs to access(open / close) and to resize boot partiton of EMMC.
Signed-off-by: Amar <amarendra.xt@samsung.com>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
This patch enables and initialises DWMMC for SMDK5250.
Supports both FDT and non-FDT. This patch creates a new file
'exynos5-dt.c' meant for FDT support.
exynos5-dt.c: This file shall contain all code which supports FDT.
Any addition of FDT support for any module needs to be
added in this file.
smdk5250.c: This file shall contain the code which supports non-FDT.
version. Any addition of non-FDT support for any module
needs to be added in this file.
May be, the file smdk5250.c can be removed in near future
when non-FDT is not required.
The Makefile is updated to compile only one of the files
exynos5-dt.c / smdk5250.c based on FDT configuration.
NOTE:
Please note that all additions corresponding to FDT need to be added into the
file exynos5-dt.c.
At same time if non-FDT support is required then add the corresponding
updations into smdk5250.c.
Signed-off-by: Amar <amarendra.xt@samsung.com>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
This patch initialises the local variable 'shift' to zero.
The uninitialised local variable 'shift' had garbage value and was
resulting in unwnated results in the functions exynos5_get_mmc_clk()
and exynos4_get_mmc_clk().
Signed-off-by: Amar <amarendra.xt@samsung.com>
Acked-by: Simon Glass <sjg@chromium.org>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
This patch adds FDT support for DWMMC, by reading the DWMMC node data
from the device tree and initialising DWMMC channels as per data
obtained from the node.
Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
Signed-off-by: Amar <amarendra.xt@samsung.com>
Acked-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
This patch enumerates dwmci and set auto stop command during
dwmci initialisation.
EMMC read/write is not happening in current implementation
due to improper fifo size computation. Hence modified the fifo size
computation to resolve EMMC read write issues.
Signed-off-by: Amar <amarendra.xt@samsung.com>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
This patch adds DWMMC device node data for exynos5.
This patch also adds binding file for DWMMC device node.
Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
Signed-off-by: Amar <amarendra.xt@samsung.com>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Acked-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.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: Sergey 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: Sergey 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: Heiko 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 8f62ca6 "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: Stephen 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: Kuo-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: Kuo-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: Kuo-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: Kuo-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: Kuo-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: Vivek 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>
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: Julius Werner <jwerner@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This commit broke USB2 on link (Chromebook Pixel):
020bbcb 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: Simon 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: Vincent Palatin <vpalatin@chromium.org>
(cherry picked from commit 012bbf0ce0301be2482857e3f03b481dd15c2340)
Rebased to upstream/master:
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Vincent 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: Vincent Palatin <vpalatin@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Vincent 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: Marek Vasut <marex@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Tom Rini <trini@ti.com>
Cc: Richard Danter <richard.danter@windriver.com>
