Flag status register polling is required for micron 512Mb flash
devices onwards, for performing erase/program operations.
Like polling for WIP(Write-In-Progress) bit in read status register,
spi_flash_cmd_wait_ready will poll for PEC(Program-Erase-Control)
bit in flag status register.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
There is no other call other than spi_flash_cmd_wait_ready(),
hence removed spi_flash_cmd_poll_bit and use the poll status code
spi_flash_cmd_wait_ready() itself.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Use the existing spi_flash_addr() for 3-byte addressing
cmd filling in write call.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Defined bank addr code on CONFIG_SPI_FLASH_BAR macro, to reduce the
size for existing boards which has < 16Mbytes SPI flashes.
It's upto user which has provision to use the bank addr code for
flashes which has > 16Mbytes.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This patch updated the spi_flash read func to support all
sizes of flashes using bank reg addr facility.
The same support has been added in below patch for erase/write
spi_flash functions:
"sf: Support all sizes of flashes using bank addr reg facility"
(sha1: c956f600cbb0943d0afe1004cdb503f4fcd8f415)
With these new updates on sf framework, the flashes which has < 16MB
are not effected as per as performance is concern and but the
u-boot.bin size incrased ~460 bytes.
sf update(for first 16MBytes), Changes before:
U-Boot> sf update 0x1000000 0x0 0x1000000
- N25Q256
16777216 bytes written, 0 bytes skipped in 199.72s, speed 86480 B/s
- W25Q128BV
16777216 bytes written, 0 bytes skipped in 351.739s, speed 48913 B/s
- S25FL256S_64K
16777216 bytes written, 0 bytes skipped in 65.659s, speed 262144 B/s
sf update(for first 16MBytes), Changes before:
U-Boot> sf update 0x1000000 0x0 0x1000000
- N25Q256
16777216 bytes written, 0 bytes skipped in 198.953s, speed 86480 B/s
- W25Q128BV
16777216 bytes written, 0 bytes skipped in 350.90s, speed 49200 B/s
- S25FL256S_64K
16777216 bytes written, 0 bytes skipped in 66.521s, speed 262144 B/s
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Updated the spi_flash framework to handle all sizes of flashes
using bank/extd addr reg facility
The current implementation in spi_flash supports 3-byte address mode
due to this up to 16Mbytes amount of flash is able to access for those
flashes which has an actual size of > 16MB.
As most of the flashes introduces a bank/extd address registers
for accessing the flashes in 16Mbytes of banks if the flash size
is > 16Mbytes, this new scheme will add the bank selection feature
for performing write/erase operations on all flashes.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Read the flash bank addr register to get the state of bank in
a perticular flash. and also bank write happens only when there is
a change in bank selection from user.
bank read only valid for flashes which has > 16Mbytes those are
opearted in 3-byte addr mode, each bank occupies 16Mytes.
Suppose if the flash has 64Mbytes size consists of 4 banks like
bank0, bank1, bank2 and bank3.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Bank/Extended addr commands are specific to particular
flash vendor so discover them based on the idocode0.
Assign the discovered bank commands to spi_flash members
so-that the bank read/write will use their specific operations.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
This patch provides support to program a flash bank address
register.
extended/bank address register contains an information to access
the 4th byte addressing in 3-byte address mode.
reff' the spec for more details about bank addr register
in Page-63, Table 8.16
http://www.spansion.com/Support/Datasheets/S25FL128S_256S_00.pdf
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This change slightly improves readability.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
This change slightly improves readability.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Richard Retanubun <richardretanubun@ruggedcom.com>
Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
Use the exact names for W25Q 0x40XX ID's flash parts, as the same
sizes of flashes comes with different ID's. so-that the distinguishes
becomes easy with this change.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Corrected the name of S25FL128S 64K sector part SPI flash,
S25FL128S supported has been added in below commit
"sf: spansion: Add support for S25FL128S"
(sha1: 1bfb9f156a)
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.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: Jim Lin <jilin@nvidia.com>
Tested-by: Stephen 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: Simon Glass <sjg@chromium.org>
Tested-by: Andreas Bießmann <andreas.devel@googlemail.com>
Tested-by: Lubomir Popov <lpopov@mm-sol.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>
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>
Jagannadha Sutradharudu Teki
Axel Lin
Jim Lin
Simon Glass
Tom Rini
Stephen Warren
Andrew Gabbasov
Fabio Estevam
Ruud Commandeur
Jagannadha Sutradharudu Teki
Bo Shen
Sergey Yanovich
Heiko Schocher
Kuo-Jung Su