Age | Commit message (Collapse) | Author |
|
MMC0 is the only one limited to 4-bit on OMAP3.
Change-Id: I31e922d39e4b23c3cc41f77f50d1ee572cc33364
Signed-off-by: Mike J. Chen <mjchen@google.com>
|
|
I originally put the command to read the SMART information out of
Samsung e-MMCs in the generic code because I thought I needed to
use private MMC interfaces to accomplish it. I now know better
and am moving the command out to its own separate file.
Change-Id: I9b71a2da342dbff0122910c38bde48274d07452c
Signed-off-by: Scott Anderson <saa@android.com>
|
|
The code was returning a -1 from a function that returns an
unsigned long. The correct error return is 0.
Change-Id: Ie549d7f0c3305c5db258660486d07431a442d137
Signed-off-by: Scott Anderson <saa@android.com>
|
|
In the past, MMC erase used a combination of Secure Erase for
erasing multiples of the erase group size and writing ones to
"erase" the write blocks that were not a multiple of the erase
group size. The following changes were made to this:
1) Secure Trim will be used for all erases as it can be used
on write-block sized chunks instead of only on erase-group
sized chunks.
2) Large erases will be split into multiple Secure Trims
keeping the amount to be erased to no more than
CONFIG_SYS_MMC_MAX_ERASE_COUNT erase groups. The default for
CONFIG_SYS_MMC_MAX_ERASE_COUNT is 8192. Assuming an erase
group size of 1024 write blocks, and a write block size of
512, the default maximum amount to be erased at one time is
4GB. This is to keep the timeouts from becoming ridiculously
large and so we can keep the user informed of the progress.
3) Improved error reporting to understand more detail than
"mmc erase failed".
4) Made the erase block functions consistent with the other
block functions now that they didn't need to handle writing
ones versus erasing.
Change-Id: Iea5efe75892480f885b1ba49d93c79f891380faf
Signed-off-by: Scott Anderson <saa@android.com>
|
|
We have occasionally seen erase timeout errors. Sometimes erases
of 1M blocks will take around 6 seconds instead of the typical
less than 1 second. I believe this is due to the MMC doing
housekeeping. To try to prevent this from happening, the
following changes have been made:
1) The base timeout for an erase used to be 5X the retry
time. This change increases that to 10X.
2) Only a warning is printed when the timeout is first hit.
The timeout is then doubled and if it is hit again, TIMEOUT
will be returned and an error printed.
In addition, several other minor changes were made:
1) The code used to add 1 ms per 1000 blocks to the timeout.
This was changed to 1 ms to 1024 blocks to allow the compiler
to optimize it to a shift instead of a divide. In addition,
the comment was cleaned up (mainly to remove the inaccurate
"1000 ms per 1 million blocks").
2) Removed the "erasing %lu blocks" printf. Higher levels
can print out advisory information if wanted. This matches
the other hardware dependent MMC drivers I looked at.
Change-Id: I9a03b93dc4adf3b6a4df34a1a2b592f6cad53a87
Signed-off-by: Scott Anderson <saa@android.com>
|
|
When ERASE_GROUP_DEF (ext_csd[175]) is enabled, HC_ERASE_GRP_SIZE
(ext_csd[224]) defines the erase group size in terms of 512KByte
chunks, but erase_grp_size is in terms of number of write blocks.
Change-Id: Id1d291fccf8a5920346045c84d71062ad7878533
Signed-off-by: Scott Anderson <saa@android.com>
|
|
This commit enabled u-boot to do DMA writes to the MMC-based on the
CONFIG_OMAP_MMC_DMA_WRITE option. This is done using the
sDMA module of the OMAP, since that is the least common denominator between
OMAP3 and OMAP4, thus allowing OMAP3 to benefint from this commit too. Included
are: (1) include for SDMA addressed, structures, etc; (2) mini sDMA driver
(embedded in ompa_hsmmc.c for now); and (3) sDMA intergration for MMC writes.
Some code is present to demonstrate how to integrate read capability too, but
read functionality is *untested*
Change-Id: I74ce902fc4b88e783f2620188cff3ff27a7c1a4d
|
|
The MMC Device Identification register (CID) is used to populate
the block device's product, vendor and revision strings. The old
code did not match the standard in how the fields were
interpreted. In addition, not all of the fields were used. In
this change, I fixed the interpretation of the fields, got all
the fields (other than the CRC) output, and in an attempt to make
the code clearer I separated the unpacking of the fields from the
formatting.
This information can be printed using the "blk dev" command and
is useful in getting detailed information about MMCs.
Change-Id: Ied89b7570ecd440ba586249c0aa178a7325e283b
Signed-off-by: Scott Anderson <saa@google.com>
|
|
SPL can't handle commands, so ensure samsung_smart is not built.
Change-Id: Id902304e9e3348d8abe3bfdc75c4b32d4e21b22b
Signed-off-by: Scott Anderson <saa@google.com>
|
|
I mistakenly submitted a slightly out of date version of the code
initially. Clean up the error handling and fix compile problems.
Change-Id: I3728e028c40ea7e30e0105718588983c9dc0c344
Signed-off-by: Scott Anderson <saa@google.com>
|
|
Samsung MMCs implement a Smart Report that gives details on the
underlying NAND memory. This new command reports those values to
determine the status of the Samsung MMC.
Signed-off-by: Scott Anderson <saa@google.com>
Change-Id: Id589b4775b437160be058b70b61be1bf88a874eb
|
|
Depending on the system, VMMC may end up being 3 or 1.8v. It is
important that the PBIAS cell be configured to match the supply.
Fortunately, the PBIAS cell contains a handy detector which can
determine what the supply is set to after PWRDNZ has been released.
Use this detector to make sure that the cell is properly configured
and does not damage itself.
Change-Id: I96d8aff3d19f5ea783ae7eb646a7e3fa920a64be
Signed-off-by: John Grossman <johngro@google.com>
|
|
The margin was too close on devices (typically only 1-2 seconds).
Increase the margin to 5 seconds.
Change-Id: Ibbb54dc1aa6875cc587cb5616390ebc132c73aff
Signed-off-by: Mike J. Chen <mjchen@google.com>
|
|
gcc was whining about a format string not matching the type of
the argument. While fixing that, I noticed and fixed a typo in a
nearby comment.
Change-Id: I1998b0aa7718c5aed698ad830ef6085a767f4b18
Signed-off-by: Scott Anderson <saa@google.com>
|
|
It's a lot faster when erasing many contiguous blocks to issue
one command instead of doing it one erase group at a time because
the MMC part can often do it in parallel.
The issue it wasn't done earlier is timeouts. Specific to omap_hsmmc,
make the erase code check for completion status after the erase
command has been sent, and adjust the timeout used in that case
to be relative to the number of blocks being erased. Other
mmc drivers might need adjusting too to match this behavior and
the ratio of timeout to number of blocks being erased is really
device specific and not driver specific but for now we use a
fixed ration of 1 second per 1000 blocks.
Change-Id: I5e25c64d475ad8b5508926347e480ddcb7e5bb05
Signed-off-by: Mike J. Chen <mjchen@google.com>
|
|
MMC defines the erase block size in terms of a number of blocks.
Formerly berase() rounded what would be erased and printed a
warning message. This change enhances it to write ones to any
blocks that would not be a part of an entire erase block.
Signed-off-by: Scott Anderson <saa@google.com>
Change-Id: I4903f7db3078d4e27a3c1746b5a12a306d5d71df
|
|
In case other code set the current i2c bus to a different one.
Change-Id: I9a377bf90ca643e083d4b9dd0304f9db35793f74
Signed-off-by: Mike J. Chen <mjchen@google.com>
|
|
Conflicts:
MAKEALL
arch/arm/cpu/armv7/omap-common/Makefile
arch/arm/cpu/armv7/start.S
arch/arm/include/asm/arch-omap4/cpu.h
arch/arm/include/asm/arch-omap4/sys_proto.h
arch/arm/lib/board.c
common/cmd_led.c
common/serial.c
drivers/i2c/omap24xx_i2c.c
include/configs/omap3_beagle.h
include/configs/omap4_panda.h
include/serial.h
Change-Id: Ib6573909994b707670aac7353e915f6d33f2481a
|
|
Change-Id: I8a7e543bde4bc2a134264025c18c4d2a8b6ccdc9
Signed-off-by: Mike J. Chen <mjchen@google.com>
|
|
Change-Id: I96694f69612afe1f166c19879f5af2aeff5dfe80
|
|
Change-Id: If82e3645e38c4451d8b4af046307204249aa7c4a
Signed-off-by: Mike J. Chen <mjchen@google.com>
|
|
The code was checking 4-bit support first and setting that. Now favor
setting 8-bit first if the card says it is 8-bit capable.
Fix OCR_VOLTAGE_MASK. It was missing highest bit.
Change-Id: I134f0bb94f57c730c0a580985800a13968a1bff8
Signed-off-by: Mike J. Chen <mjchen@google.com>
|
|
Faraday FTSDC010 controller is a SD/MMC controller for SoC chip.
Signed-off-by: Macpaul Lin <macpaul@andestech.com>
|
|
The mmc_send_status() function sets cmd.arg = 0. That's incorrect, so fix it.
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Acked-by: Andy Fleming <afleming@freescale.com>
Tested-by: Lei Wen <adrian.wenl@gmail.com>
|
|
Now that all platforms have been migrated to the new MMC driver, remove
the old one.
Signed-off-by: Tom Rini <trini@ti.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
|
|
Currently if a DMA buffer straddles a buffer alignment boundary
(512KiB) then the DMA engine will pause and generate a DMA
interrupt. Since the DMA interrupt is not enabled it will hang
the MMC driver.
This patch adds support for restarting the DMA transfer. The
SYSTEM_ADDRESS register contains the next address that would have
been read/written when a boundary is hit. So we can read that
and write it back. The write triggers the resumption of the
transfer.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Tested-by : Jaehoon Chung <jh80.chung@samsung.com>
Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
|
|
Change-Id: I21ab43494ef15a2eeb582daaeb4de5bcb3461671
Signed-off-by: Mike J. Chen <mjchen@google.com>
|
|
This reverts commit c310fc840472a36e4b9d2505830e9dc8d458d63c.
The Atmel custodian had apparently rejected this patch's approach in
another thread, so this patch reverts it for now.
Signed-off-by: Andy Fleming <afleming@freescale.com>
|
|
If we don't want to build support for any partition types we can now
add #undef CONFIG_PARTITIONS in a board config file to keep this from
being compiled in. Otherwise boards assume this is compiled in by
default
Signed-off-by: Matthew McClintock <msm@freescale.com>
|
|
According to datasheet,set block count before multiple read/write.
Signed-off-by: elen.song <elen.song@atmel.com>
Acked-by: Andy Fleming <afleming@freescale.com>
|
|
This patch provides handling of the two way handshake when SEND_OP_COND
(CMD1) is send to mmc card. It is necessary to inform eMMC card if the
host can work with high capacity cards (Jedec JESD84-A441, point 7.4.3).
The extra flag MMC_MODE_HC (high capacity) is added to indicate if the
host is capable of handling the high capacity eMMC cards.
Since this change is added to the generic mmc framework, then it requires
other boards to indicate if their mmc controllers can handle high capacity
cards. As it is now - the old behaviour of the framework is preserved.
Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Andy Fleming <afleming@freescale.com>
|
|
Some Renesas SuperH have MMCIF module. This driver supports it.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Acked-by: Andy Fleming <afleming@freescale.com>
|
|
Fix the problem that if we use the chip of MMC version 4 and
the capacity is smaller than 2GB or equal, the mmc->capacity is
invalid. According to the JEDEC Standard, the value of ext_csd's
capacity is valid if the value is more than 2GB.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Acked-by: Andy Fleming <afleming@freescale.com>
|
|
This could support both armada100 and pantheon serial in the mainline,
while this driver also be tested to support upcoming mg, mmp2 and mmp3
hardware.
Signed-off-by: Lei Wen <leiwen@marvell.com>
Acked-by: Andy Fleming <afleming@freescale.com>
|
|
Nowdays, there are plenty of mmc driver in uboot adopt the sd standard
host design, aka as sdhci. It is better to centralize the common logic
together to better maintenance.
Signed-off-by: Lei Wen <leiwen@marvell.com>
Acked-by: Andy Fleming <afleming@freescale.com>
|
|
Erase is a very basic function since the begin of sd specification is
announced. Although we could write a bulk of full 0xff memory to the
range to take place of erase, it is more convenient and safe to
implement the erase function itself.
Signed-off-by: Lei Wen <leiwen@marvell.com>
Signed-off-by: Andy Fleming <afleming@freescale.com>
Acked-by: Mike Frysinger <vapier@gentoo.org>
|
|
Signed-off-by: Tom Warren <twarren@nvidia.com>
Acked-by: Andy Fleming <afleming@freescale.com>
|
|
This patch added set_mmc_clk for external clock control.
c210 didn't support host clock control.
So We need external_clock_control function for c210.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
|
|
Fix typo resulting in the compilation error
s5p_mmc.c: In function 's5p_mmc_initialize':
s5p_mmc.c:469: error: 'struct mmc' has no member named 'm_bmax'
introduced by commit "MMC: make b_max unconditional"
(8feafcc49c0b7a9c541904f95a43dbef2fecc38b)
Signed-off-by: Dirk Behme <dirk.behme@googlemail.com>
CC: John Rigby <john.rigby@linaro.org>
CC: Andy Fleming <afleming@freescale.com>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
|
|
Signed-off-by: Wolfgang Denk <wd@denx.de>
|
|
Add missing header file to fix compilation warning
omap_hsmmc.c: In function 'omap_mmc_init':
omap_hsmmc.c:474: warning: implicit declaration of function 'get_cpu_family'
omap_hsmmc.c:474: warning: implicit declaration of function 'get_cpu_rev'
introduced by commit "MMC: omap_hsmmc.c: disable
multiblock rw on old rev omap34xx silicon"
(4ca9244d74f146a0605f5bee28a66e39aae88d3e)
Signed-off-by: Dirk Behme <dirk.behme@googlemail.com>
CC: Andy Fleming <afleming@freescale.com>
CC: John Rigby <john.rigby@linaro.org>
|
|
commit 262951(MMC: make b_max unconditional) missed to update fsl_esdhc.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Stefano Babic <sbabic@denx.de>
|
|
For emmc, it may have up to 7 partitions: two boot partitions, one
user partition, one RPMB partition and four general purpose partitions.
(Refer to JESD84-A44.pdf/page 154)
As bootloader may need to read out or reflashing images on those
different partitions, it is better to enable the partition switch with
console command support.
Also for partition would be restore to user partition(part 0) when CMD0
is used, so change mmc_init routine to perform normal initialization
only once for each slot, unless use the rescan command to force init
again.
Signed-off-by: Lei Wen <leiwen@marvell.com>
Acked-by: Andy Fleming <afleming@freescale.com>
|
|
mmc command applied device, like ide and usb...
Signed-off-by: Lei Wen <leiwen@marvell.com>
Acked-by: Andy Fleming <afleming@freescale.com>
|
|
A "send status" command is added with the commit "mmc: checking
status after commands with R1b response". But the status register
returned from send status command of SPI protocol is different from
that of MMC/SD protocol. We do a simple test and generate a response
in stead of full bit-by-bit translation.
Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
|
|
Signed-off-by: Reinhard Meyer <u-boot@emk-elektronik.de>
|
|
Signed-off-by: Andreas Bießmann <biessmann@corscience.de>
|
|
Signed-off-by: Andreas Bießmann <biessmann@corscience.de>
|
|
For freescale i.MX53 eSDHCv2, when using CMD12, cmdtype need
to be set to ABORT, otherwise, next read command will hang.
This is a software Software Restrictions in i.MX53 reference manual:
29.7.8 Multi-block Read
For pre-defined multi-block read operation, that is,the number of blocks
to read has been defined by previous CMD23 for MMC, or pre-defined number
of blocks in CMD53 for SDIO/SDCombo,or whatever multi-block read without
abort command at card side, an abort command, either automatic or manual
CMD12/CMD52, is still required by ESDHC after the pre-defined number of
blocks are done, to drive the internal state machine to idle mode. In this
case, the card may not respond to this extra abort command and ESDHC will
get Response Timeout. It is recommended to manually send an abort command
with RSPTYP[1:0] both bits cleared.
Signed-off-by: Jason Liu <jason.hui@linaro.org>
|
|
Signed-off-by: John Rigby <john.rigby@linaro.org>
|